2

ワークユニットをクライアントに配布するためにデータベースを管理する Java アプリケーションが必要です。事実上、これはグリッド アプリケーションです。データベースにはクライアントの入力パラメータが入力され、そのすべてのタプルを要求したクライアントに配布する必要があります。クライアントが結果を送信した後、サーバーはそれに応じてデータベースを変更します (たとえば、タプルを計算済みとしてマークするなど)。
ここで、タプルで満たされたデータベース (SQLite または MySQL) があり、クライアントが入力タプルのグループを要求したとします。ワークユニットのグループを一意のクライアントに排他的に送信したいので、それらをマークする必要があります。 「すでに別のクライアントからリクエストされています」。最初の (たとえば 5 つの) クエリのデータベースをクエリし、その間に別のクライアントが同じ要求を行う場合 (マルチスレッド サーバー アーキテクチャで、同期なしで) 両方のクライアントが同じ作業単位を受け取る可能性があると思います.

解決策は次のようになると想像しました:
1)シングルスレッドサーバーアーキテクチャを作成します( ServerSocket.accept() は、以前のクライアントリクエストが処理された後にのみ再度呼び出されるため、サーバーは一度にクライアントのみによって効果的にアクセスされます)
2 )マルチスレッドアーキテクチャでは、クエリとタプルロック操作を同期させて、一種の原子性を取得します(データベース上で操作を効果的にシリアル化します)
3)データベースサーバー(またはファイル、 SQLite の場合)、しかし、この場合、実際にどうなるかわからないため、助けが必要です...

ただし、私の問題を理解していただければ幸いです。ワークユニットを分散する seti@home と非常に似ていますが、多数のクライアントへのすべての分散ユニットの交差は (理論的には) null です。私の非機能的なニーズは、言語が Java であり、そのデータベースが SQLite または MySQL であることです。

4

2 に答える 2

1

DBが同期ジョブを実行する方法を確認するために、このような記事を読むことをお勧めします。

于 2011-04-01T13:26:26.783 に答える
1

考えられる解決策のそれぞれについてのフィードバック...

1) シングルスレッドのサーバー アーキテクチャを作成します ( ServerSocket.accept() は、前のクライアント要求が処理された後にのみ再度呼び出されるため、一度にクライアントのみがサーバーに効果的にアクセスできます)

ServerSocket.accept()ではそれができません。1 つのスレッドのみが の状況になるようにするには、他のタイプの同期が必要になる場合がありますgetting tuples。これは基本的にソリューションにつながります(2)。

2)マルチスレッドアーキテクチャでは、クエリとタプルロック操作を同期させて、一種の原子性を取得します(データベース上で操作を効果的にシリアル化します)

実行可能で、実装が簡単で、問題に取り組むための一般的な方法。唯一の問題は、パフォーマンス、レイテンシ、およびスループットをどれだけ気にするかです。これらのクライアントが多数あり、作業単位の期間が非常に短い場合、クライアントは「トークン」を取得するために待機中に 90% の時間ロックされる可能性があるためです。

その問題の可能な解決策。ワークユニットにはハッシュベースのディストリビューションを使用してください。50 のクライアント間で共有する 500 の作業単位があるとします。どのクライアントが特定の作業単位を取得するかという方法で、作業単位に ID を与えます。最後に、単純なモジュール操作でノードを割り当てることができます。

assigned_node_id = work_unit_id % number_of_working_nodes

と呼ばれるこの手法は、pre-allocationすべての種類の問題で機能するわけではないため、アプリケーションによって異なります。実行時間の短いプロセスが多数ある場合は、この方法を使用してください。

3)データベースサーバー(またはSQLiteの場合はファイル)に対してアトミッククエリ操作を使用しますが、この場合、実際にどうなるかわからないため、助けが必要です...

本質的には (2) と同じですが、これを実行できる場合 (SQL だけで実行できるとは思えません)、RDBMS の特定の機能に縛られることになります。ほとんどの場合、このソリューションを実現するには、非標準の SQL プロシージャが必要になるでしょう。また、ソリューション 2 で見つかった問題は修正されません。

Summary

ソリューション 2 は、90% のケースで機能する可能性が高く、タスクが長いほど、このソリューションに適しています。タスクの時間が非常に短い場合は、間違いなくpre-allocationベースのアルゴリズムを使用してください。

解決策 3 では、移植性と柔軟性が失われます。

DRY: try some other Open Source systems ...

この種の問題にすでに対処しているオープン ソースの Java プロジェクトはほとんどありません。

http://www.gridgain.com/

http://www.jppf.org/

于 2011-04-02T12:44:18.437 に答える