AKKAアクターとデータベース操作
アクターシステムを使用しながらデータベース操作を最適に処理する方法を見つけようとしています。実際、AKKAでブロックしないようにしようとしている間、データベース操作はブロックされています。
私はメインドキュメントで、それを処理する1つの方法は、データベースアクセスを処理する、ルーターの背後に、場合によっては分離されたexecutionContext上にアクターのプールを作成することでした。
したがって、私は次の質問があります：
1-databaseActorsは接続を常に開いたままにしますか？
2-多くのデータベースで提供されている接続プーリングとどのように連携しますか？
3-両方を組み合わせて、DatabaseActorsが要求されるたびにプールから新しい接続を要求するようにします。そうでない場合は、接続を常に開いたままにしておくのは悪いことではありませんか？
4-スレッドの枯渇を回避するアプローチにする微妙なことを誰かが私に説明できますか？たとえば、Playまたはsprayを使用する場合、リクエストの処理は非同期タスクですが、そのタスクがデータベースアクセスを必要とし、DatabaseActorに質問を送信した場合、データベースActorのブロック（発生した場合）は誘導しません。非同期タスクのブロックで、スレッドが不足する可能性がありますか？
5-DB ACIDプロパティが複数の読み取りと書き込みの安全性を保証し、したがって関係の前に発生することは100％確実ですか。
6-トリプルストアとも呼ばれるセマンティックデータベースを使用しており、リクエスト中にセマンティック推論機能を多用しています。また、プーリングとアクター番号のパラメーターの調整、または専用の実行コンテキストに関して、多くの書き込みアクセス、アドバイスを実行しますか？
ベスト、
M
1-databaseActorsは接続を常に開いたままにしますか？
Akkaアクターはステートフルです。つまり、安全にアクター内に状態（この場合はDB接続）を保存できます。独自の接続管理ロジックを作成することも、データベースドライバーによって提供されるロジックを使用することもできます。
2-多くのデータベースで提供されている接続プーリングとどのように連携しますか？
3-両方を組み合わせて、DatabaseActorsに、要求されるたびにプールからの新しい接続を要求させますか。そうでない場合は、接続を常に開いたままにしておくのは悪いことではありませんか？
両方を組み合わせることができます。プール内の接続ごとにアクターを配置します。なぜ接続を維持するのは悪いことだと思いますか？接続プールを持つことの全体的なポイントは、リソース（接続）を再利用することであり、毎回それらを作成/破棄する代償を払わないことです。
4-スレッドの枯渇を回避するアプローチにする微妙なことを誰かが私に説明できますか？たとえば、Playまたはsprayを使用する場合、リクエストの処理は非同期タスクですが、そのタスクがデータベースアクセスを必要とし、DatabaseActorに質問を送信した場合、データベースActorのブロック（発生した場合）は誘導しません。非同期タスクのブロックで、スレッドが不足する可能性がありますか？
データベースドライバがブロックしている場合は、最終的にもブロックする必要があります。推奨される方法は、このブロッキングコードを別の実行コンテキスト/スレッドプールで実行することです。または、オプションがある場合は、完全に非同期で非ブロッキングのリアクティブデータベースドライバー（ReactiveMongo for MongoDBなど）を備えたデータストアを選択します。
5-DB ACIDプロパティが複数の読み取りと書き込みの安全性を保証し、したがって関係の前に発生することは100％確実ですか。
これが何を意味するのかわかりません。
6-トリプルストアとも呼ばれるセマンティックデータベースを使用しており、リクエスト中にセマンティック推論機能を多用しています。また、プーリングとアクター番号のパラメーターの調整、または専用の実行コンテキストに関して、多くの書き込みアクセス、アドバイスを実行しますか？
間違いなく別の実行コンテキストを使用する必要があります。パラメータの変更は、実際にはハードウェア構成とソフトウェアの他の詳細（データベースのタイプ、リモートデータベースと組み込みデータベース、要求/秒など）によって異なります。
Akkaのディスパッチャーに関しては、1つのサイズですべてに対応できるとは思いません。それは芸術のようなものです。私の唯一の推奨事項は、ブロッキングコードのどこにもあなたのでないことを確認することです。
このブログ投稿 DB接続ごとにActorを使用しない理由にはいくつかの本当に良い点があります。
特に、ネイティブ接続プールに並行性レベルを処理させるのではなく、並行性レベルを管理する必要があることを意味します。また、実際にはコードがシリアルに実行されているのに、コードが並列に実行されていると誤解する可能性もあります。