3

私のシナリオは次のとおりです。100 万行のタプル (たとえば、名)を持つデータ テーブルと、名または姓がクエリ文字列で始まる行の小さなサブセットを取得する必要があるクライアントがあります。これをキャッシュすることは、キャッチ 22 のように思えます。

  • 一方では、リクエストごとにデータセット全体を保存および取得することはできません (ネットワークを圧倒します)。
  • 一方、各行を個別に保存することはできません。クエリを実行する方法がないからです。
  • ローカルの「インデックス」またはディレクトリを使用して、値の範囲をキャッシュに保存することは機能します... ただし、基本的に各インデックスのデータを複製する必要があり、分散キャッシュを使用する目的さえ無効になります。

この種のことにはどのようなアプローチが望ましいですか?分散キャッシュを使用する利点を得ることができますか?それとも、この種のシナリオには適していませんか?

4

1 に答える 1

0

分散キャッシングは、クエリ可能なデータ セットに適しています。

ただし、このシナリオでは、はるかに高速な結果が得られるネイティブ関数またはプロシージャが必要です。セッションやアプリケーションのように異なるスコープが不可能な場合、各リクエストのデータを取得するためにサーバー側で多くの反復が必要になります。

データベースのサーバー側でインデックスを作成することは、決して良い考えではありません。

それでもネットワークの問題がある場合。ドキュメント指向または列指向の NoSQL DB に進むことができます。可能であれば。

于 2012-08-22T07:22:22.493 に答える