0

検索操作を実行するためにデータを取得する最も効率的な方法です。

以下は、アプリケーションが既知の変数 (検索キーワード) の検索のような機能を必要とする要件です。

NB:: 現在、アプリケーションには、アプリケーション レベルで維持されるオブジェクトの形式でデータ キャッシュに格納され、検索以外の目的で使用されるキーに格納された検索キーワードが既にあります。

現在、検索を可能にする 2 つの可能性があります (1) java.util.regex.Pattern を使用してパターン マッチングを実行し、識別された結果行をキャッシュからフェッチするか、(2) データベースに一致を実行して一致を取得するように依頼します。行?

どちらがより効率的かを知る必要があります。

それに関する入力や、同様の操作で実行されたシミュレーターのデータをいただければ幸いです。

4

2 に答える 2

2

オプション 1 は、ネットワーク I/O を含まないため、推奨されます。

ローカル キャッシュでのパターン マッチングとルックアップにはおそらくナノ秒または数ミリ秒かかりますが、要求をネットワーク経由でデータベースに送信し、応答を待つには数十 (または数百) ミリ秒かかります。データベースが実際のデータ検索を独自のコードよりも少し速く実装する可能性があることは関係ありません。

于 2013-05-27T11:41:07.283 に答える
1

これは大きすぎてコメントに入れられませんでした:

あなたの質問に簡単に答えるには: オプション 1 は、ローカル キャッシュやネットワーク経由でアクセスできるデータベースなど、あなたが説明したものに適しています。

「ローカル」キャッシュを強調したいと思います。分散キャッシュについて話している場合、ネットワーク ペナルティが発生し、答えは「もっと情報が必要です」になります。考慮すべき要因は、行の平均サイズ、ネットワーク レイテンシの中央値、読み書きの確率などです。これに答えるのは本当に苦痛です。

そのような決定に直面したとき、私は通常、次の手順に従って何を使用するかを決定します。ここでの主な指標は単純さです。つまり、レスポンシブなサイトを維持しながら時間節約できる最も単純なソリューションを探しています。

  1. 起動時はキャッシュなしで試しています。
  2. それでも十分ではなく、アプリ サーバーが 1 つしかない場合は、ローカル キャッシュを実装します。
  3. アプリ サーバーを (ロード バランサーの背後に) 追加してスケールアウトする必要がある場合は、キャッシュなしでもう一度試します (DB キャッシュに依存します)。
  4. パフォーマンスの限界に達した場合にのみ、必要に応じて redis または memcache インスタンスをアタッチして分散キャッシュ システムを実装します (おそらく、個々のアプリ サーバーに小さなキャッシュを保持します)。
于 2013-05-27T12:42:34.233 に答える