ユーザーが約 200 のポータルのコンテンツを検索できるようにする検索エンジン Web アプリケーションを開発しています。
私たちのビジネス パートナーは、データのインデックス作成という主力の仕事をしている solr/lucene インスタンスの維持と供給を担当しています。
私たちのアプリケーションは solr にクエリを実行し、人間にわかりやすい方法で結果を表示します。ただし、おそらく何らかの形式のキャッシングを使用して、クエリの量を制限する方法を考えています。結果は数時間キャッシュされる可能性があります。
私たちが疑問に思っているのは、クエリ結果をキャッシュするための優れた戦略は何でしょうか? 明らかに、メソッドの呼び出しはさまざまであると予想されます... キャッシングを行うことはまったく意味がありますか?
このユースケースに特に適したキャッシュシステムはありますか? 開発にはSpring 3を使用しています。
結果またはレンダリングされたコンテンツを Lucene の外部でキャッシュするのが最も効果的であることがわかりました。Lucene インデックスからの結果でキャッシュ層を指す API 検索サービスを用意する。
キャッシング層を分離すると、分散キャッシング (Redis、Azure AppFabric、その他のクラウド キャッシングなど) など、必要なキャッシングをプラグインできます。また、Web ページの部分的なレンダリング (つまり、ASP.NET の出力キャッシュ) をキャッシュしたり、RESTful 規則を使用して API 呼び出し自体をキャッシュしたりすることもできます。キャッシュ ウォーミングやプロアクティブ キャッシング (使用状況に基づく) などは、サービスで簡単に実行できます。
アプリケーション/インデックス キャッシュは、インデックス レベルでキャッシュするだけでなく、アプリのより多くの層で「再利用」できます。これはすべて、インデックス作成の更新がリアルタイムであるかどうか、クエリが各クライアント/ユーザー ID に対して日付レベルで安全であるかどうかなどに依存します。上記のように、Solr は既にこの作業の「一部」を行っています。
最も簡単な解決策は、Solr に到達する前にクエリを修正することです。
QueryBuilderSolr にアクセスする前にクエリ文字列を渡す独自のメソッドを作成しました。
これが行うことは、すべての引数を展開し、定義済みのグループ セットに並べ替えるだけです。
たとえば、キャッシュできるようにクエリを正規化するには、各キーでアルファベット順に並べ替え、クエリ文字列を再形成し、これを使用して Solr にクエリを実行します。(実際のクエリ結果は変更されません)。
実際にクエリを実行する前に、Solr クエリ文字列のハッシュを作成し、保存されたすべてのキーのメモリ内ハッシュを確認できます。数百万のクエリ キーに近づいている可能性が非常に高い場合は、BloomFilterを使用してキースペースを削減し、キャッシュ ヒットの精度をある程度維持することを検討することをお勧めします。
または、Solr との間にリバース プロキシ キャッシュを配置することを検討することもできます。たとえば、Solr のようにクエリを実行する場合Spring -> Varnish -> Solr、Varnishを使用してキャッシュすることができ、クエリ文字列をハッシュとして使用します。その後、結果を自動的にフラッシュ/クリア/無効にするために、2 時間の有効期限を設定できます。
うまくいけば、これが役に立ちます。