4

長いスピーチの短い: 1 つまたはいくつかの永続的なセッションを介して、同時に実行されている何百ものプロセスがデータベースと通信するようにするにはどうすればよいですか?

全体的な話:
私はかつて、膨大な量の大きなデータ ファイルを処理する数値演算エンジンを構築しました。このエンジンは、子プロセスを次々と分岐させて、それぞれに少数のファイルを処理させました。ファイルのロック、進行状況の監視、および結果の伝播は、DBI をカプセル化するアプリケーション固有のモジュールを使用して、すべての (サブ) プロセスがさまざまな時点でアクセスする Oracle データベースで発生します。

これは最初はうまく機能していましたが、入力データの量が増えているため、データベース セッションの数 (子ごとに 1 つ、存続期間が非常に短い可能性があります) が絶えず開いたり閉じたりすることが問題になりつつあります。すべての (サブ) プロセスのすべてのデータベース アクセスを処理する固定データベース セッションが 1 つまたは少数になるように、データベース アクセスを集中化したいと考えています。データベース抽象化モジュールの存在により、ワーカー インスタンスでの関数呼び出しが同じままで済むため、変更が容易になります。私の問題は、すべてのプロセスとデータベースコネクタ間の通信を確立するために、上記のモジュールを拡張する適切な方法を考えられないことです。

メッセージ キューイングを考えましたが、大量のリクエスタを 1 つまたは少数のデータベース コネクタに接続して、双方向通信が可能になる方法 (クエリ結果を収集するため) を思いつきませんでした。
ここでは、すべてのリクエストが同じキューに書き込まれ、リクエストを処理するデータベース コネクタが「コールバック」して結果を送信する非同期アプローチが役立ちます。しかし、私の心は、コードにペイントできるほど明確なイメージを生成することができません。
フォークの代わりにスレッド化したほうが簡単に始められたかもしれませんが、これにはコード ベースに大規模な変更が必要になり、実際のシステムに対して行う準備ができていません。

考えれば考えるほど、基本的なアイデアは、Web ページではなくデータベース クエリを提供するという点だけで、事前にフォークされた Web サーバーのように見えます。何をどこで掘り下げるかについてのアイデアはありますか? 私にインスピレーションを与えるサンプル（疑似）コード、おそらく関連する記事へのリンク、CPANの既製のソリューションでしょうか？

4

5 に答える 5

3

階層を追加することを考えるべきだと思います。POEは中間層を処理できると思います。

于 2009-05-06T15:46:46.720 に答える
1

Oracle>=10で実装するのが非常に簡単な「共有サーバー」についてDBAに相談することをお勧めします。これはサーバー側の接続プールのように考えることができます。したがって、接続を要求するときに、必ずしも新しい専用サーバープロセスを作成し、接続時にそれを破棄する必要はありません。

あなたの側で接続プールを行うこともできます。

于 2010-04-21T21:31:59.637 に答える
1

DBD::Goferを見てください。これは、データベース接続をプールして管理する別のプロセスになるように設計されています。

于 2009-05-06T15:43:47.383 に答える
0

SQLRELAYを見るとよいでしょう。これには、プロキシ側にも他のいくつかの利点があります。

http://sqlrelay.sourceforge.net/sqlrelay/

于 2009-05-07T11:01:03.203 に答える
0

特定のシナリオでは、メッセージ キューを使用するのが最適な場合があります。

  • 作業単位のロックの場合: ロック/ロック解除シングルトンへのリクエストをキューに入れます。ロックを取得できなかった場合は、作業単位を後で再スケジュールします。
  • 進行状況の監視の場合: すべての進行状況の更新をキューに入れ、ロガー/ステータス アップデーターなどによって処理されます。
  • 結果の送信では、結果セットをキューに入れ、専用の結果ライターによって挿入されます。キュー エントリは非常に大きくなる可能性がありますが、適切なメッセージ キューであればこれを処理できるはずです。ピンチでは、ペイロードをファイルにプロキシし、ファイル名と場所のみをキューに入れることができます。
  • 構成データは、ワーカー プロセスがフォークされる前の起動時にデータベースから読み取ることができるため、ワーカー プロセスはフォーク中に完全な構成を継承し、独自のデータベース接続を必要としません。

その間に、ワークユニットをキューから取得する短命のフォークの代わりに、多くの長期のワーカーデーモンを使用するように設計全体をリファクタリングすることができます。これにより、すべてのフォークのオーバーヘッドが節約されます。

当時は、企業のソフトウェアのインストール制限に制約されていたため、このアプローチは不可能でしたが、今では同様のものをゼロから構築する場合、これが私の方法です。

于 2012-09-11T08:22:10.223 に答える