1

1つのテーブルに多数のツールが保存されており、各ツールに関連付けられたトランザクションがその子テーブルに保存されています。トランザクションテーブルエントリのパフォーマンスに基づいて購入するツールを決定するアルゴリズムがあります。アルゴリズムの私の出力は、ツールの購入を推奨する場合があり、そのパフォーマンスに基づいていない場合があります。

私の最終目標は、アルゴリズムによって購入することが推奨されているツールのリストをページごとに（サーバー側のページ付けを使用して）表示することだけです。ここでの私の質問は、最初の10個のツールとそのトランザクションをフェッチし、アルゴリズムへの入力として与える場合、私のアルゴリズムはすべてのツールを購入することを推奨する場合としない場合があります。そのような場合、表示できるツールでは不十分です。現在のページ。もう一度データベースに戻って、結果が現在のページを表示するのに十分になるまで（dbの反復が多すぎる）、さらにいくつかをフェッチする必要があります。

現在、すべてをフェッチして、サーバー側で結果コレクションをキャッシュし（Ehcacheを使用）、コレクションにサーバー側のページ付けを適用しています。ただし、このページにアクセスする同時ユーザーが多すぎると、サーバーがメモリ不足になります。

この種の問題の最善の解決策は何ですか..!!？

4

1 に答える 1

0

銀の弾丸の解決策は残念ながらありませんが、ここで私の考えを共有したいと思います

通常、ページネーションの正確な結果が必要な場合は、理想的にはすべての反復を同じトランザクションで実行する必要があります。そうしないと、永続ストレージに対して並列更新を実行できるため、データの一貫性が失われます。しかし、あなたの投稿からそれが可能かどうかはわかりません。

したがって、次のことを考慮してください。

  • 現在のようにすべてをメモリに保存しないでください。代わりに、いくつかの共有オブジェクト プールをメモリに保持すると、並列の顧客はオブジェクト全体ではなく、オブジェクトへのポインタのみを保存します。

  • 結果のある種のシリアル化を使用します。些細なシリアライゼーションに加えて、「オフヒープメモリ」に興味があるかもしれません.ehcacheで動作します：http: //ehcache.org/documentation/user-guide/bigmemory

  • 反復全体でツールIDのみを保存し、アルゴリズムが決定を下すために必要な最小限のデータを保存することを検討してください。次に、結果を表示する準備ができたら、追加のリクエストを作成し、一連の ID を入力として提供して、結果を表示するために必要なものを永続化レイヤーから取得します。まだすべてのデータを必要としない可能性があり、これによりメモリが節約されます

  • ヒープを増やします。些細な:-)

お役に立てれば

于 2012-09-12T23:51:14.217 に答える