web-dev-qa-db-ja.com

順序付け/プロパティが変更される可能性があるページ分割された結果をキャッシュするためのベストプラクティスは何ですか?

順序付け/プロパティを変更できるページ付けされた検索結果をキャッシュするためのベストプラクティスは何ですか?

たとえば、私のアプリケーションで、誰かが最後の20件のディスカッションスレッド(10,000件中)を確認したいとします。 servlet経由でデータベースにリクエストが送信され、最初の20レコードがディスカッションスレッドテーブルからXML/JSONとしてフェッチされます。次に次の20を確認したい場合は、結果の次のページに移動し、次のロットを取得するための別のリクエストを発行します(制限とオフセット= 20など)。

サーバーの負荷とクライアントの待機を減らすために、結果の前のページをキャッシュしたいと思います。ただし、2つの質問があります。

  1. 結果が表示されるテーブルは、複数の属性(つまり、thread-creation-date、thread-author、last-post-date)で並べ替えることができます。これは、「最初の20件の結果」のようなステートメントは、コンテキストなしで意味をなさないことを意味します(つまり、何を注文するか)。次に、フロントエンドはどのようにして、バックエンドにすでにロードされているものと通信しますか?私の最初の考えは、各結果にIDを使用することでしたが、後続のリクエストでIDをサーバーに送り返す(および結果に基づいて結果をフィルタリングする)と、すべてを盲目的に送り返すのと同じくらい時間がかかります。これどうやってするの?
  2. 以前に返された結果(つまり、most-recent-post-date)の属性が変更された場合はどうなりますか?次に、各結果をチェックして、ページインされてからサーバー側で変更されたかどうかを確認する方法が必要です。これを行うにはどうすればよいですか?
11
goodsquishy

必要なのは、ページを定義するすべてのパラメーターのラッパー(たとえば、pageNumberpageSizesortTypetotalCountなど)のラッパーです。このDataRequestオブジェクトをキャッシュメカニズムのキーとして使用します。この時点から、キャッシュを処理するためのいくつかのオプションがあります。

  • キャッシュをリフレッシュするために、ある種のタイムアウトメカニズムを実装します(データが変更される頻度に基づく)。
  • 上記のパラメーターに基づいてデータベースの変更をチェックし、キャッシュを更新するリスナーを用意します。
  • 変更が同じプロセスで行われる場合は、常にすべての変更でキャッシュを古いものとしてマークし、ページがリクエストされたときにこのフラグを確認できます。

最初の2つは、ある間隔で、またはイベントに基づいてトリガーするスケジューラメカニズムを含む場合があります。データアクセスポイントが1つしかない場合、最後の方が簡単な場合があります。

最後に、@ DanPichelmanが述べたように、それはすぐに過度に複雑なアルゴリズムになり、メリットを上回る可能性があるため、パフォーマンスの向上がアルゴリズムの複雑さを正当化することを確認してください。

7
rae1

私はおそらくこれを次のように処理します:

  1. 異なる順序をすべて異なるシーケンスとして扱います。各クライアントが持っているものを追跡する(または何度も送り返す)には、余分な簿記の価値はありません。
  2. ユーザーページが表示されるたびに、キャッシュからすぐに表示すると同時に、ハッシュまたは最終アクセス時間のいずれかを含むGETをサーバーに送信します。サーバーは、何かが変更された場合にのみページ全体を送り返します。
  3. サーバーから一度に複数のUIページを取得します。たとえば、UIに20エントリが表示されている場合、クエリ60を実行します。これをテストする必要がありますが、最も効率的な戻りサイズは通常、1ページに表示されるデータの平均量よりも大きくなると予想しています。これにより、一部のページめくりに対してUIが非常に応答しやすくなります。
  4. 境界に近づいているときの先読み結果。これにより、キャッシュからの高速ロード時間を維持できます。
3
Chris Pitman

ちょっと考えてください-サーバーの呼び出しで、通常のパラメーターと、現在キャッシュされている以前に表示されたデータのページを表すMD5ハッシュの配列を渡します。

Return呼び出しには、新しい現在のページのすべての通常のデータと、以前に表示された古いページの更新が含まれます。古いハッシュをキーとして使用できます。

最初に多くのパフォーマンスとタイミングテストをお勧めします。クライアント側のコードは、データの各ページでサーバーにアクセスするだけの場合よりもはるかに複雑になります。余分な複雑さが、意味のある改善をもたらすことを確認してください。

2
Dan Pichelman