私たちは永続性のためにPostgresqlを、キャッシュとしてehcacheを使用しています。私たちは最近、（ファジー検索と正確な検索のための）高速検索を可能にするためにSolrを導入しました。Solrをキャッシュの代わりに使用できますか？
私の質問です：Solrはehcacheを置き換えることができるように調整できますか？
ちょうど質問には、いくつかのコンテキストを追加するために（そう、クラウド・モードで動作しているかによって言う）：我々は連絡先情報を格納するテーブルの束を持っています。 Ehcacheは現在、特定のIDに対してこれらの連絡先を取得するために使用されています。 Solrは、検索関連の操作に幅広く使用されます。 Solrは既に検索を行っているので、Ehcacheを置き換えないでください（何らかの方法で、特定のIDで検索するなど）、パフォーマンスが損なわれていないことが条件です。
その他の理由に加えて、なぜいいえは、また、変更の粒度です。 Lucene（基礎となるライブラリ）は、データを読み取り専用形式で保存します。 Solrは更新可能なドキュメントをその上に追加しますが、可視化することは依然として重い作業です。 Solrの最近のバージョンでは、ソフトコミットにより簡単かつ迅速に変更できましたが、変更を表示するための価格は依然として重要ではありません。
したがって、実際には単一の値を更新/キャッシュするために最適化されていません。データ構造は、複数のドキュメントの更新のために最適化され、その一時的な読み取り専用状態をキャッシュして高速検索します。
私はショットを取るだろうが、誰もそのようなあいまいな質問に対する決定的な答えを持つことはありそうもない。 https://lucidworks.com/blog/2012/07/23/sizing-hardware-in-the-abstract-why-we-dont-have-a-definitive-answer/は現在4歳ですが、まだ関連性があります。答えはあなたが何をする必要があるかに完全に依存します。だから、
、いくつかの一般的な文：
まず、説明に感謝します。私はいくつかの文脈を提供するために質問を編集しました。あなたの意見を教えてください。 – iwekesi
Okだから、Solrは、ファジィ検索特性と関連性ベースの2つの目的に特に役立ちます。 SolrのIDルックアップは非常に高速ですが、他の答えで指摘されているように、ソルバーインデックス全体がメモリにキャッシュされていても、インメモリキャッシュを破るのは難しいでしょう。 Solrを使用して一致する注文IDのリストを取得し、それを使用してpostgresのような永続的なストアから実際のドキュメントの内容を取得するのはかなり一般的なパターンです。速度の目的で既にポストグルの前にキャッシュを持っているのであれば、それを変更する理由はあまりありません。 – randomstatistic
簡単な答えは次のとおりです。ませ
理由：
cacheはメモリ内にありませんが、Solrのインデックスは、（キャッシュされて一部を除く）ディスク上にあります。
読み取りメモリは、ディスク読み取りよりも何千倍も速くなっています。
ので、Solrがより良い選択だろうその場合ehcacheまたはmemcachedまたはredisで、一般目的キャッシュとして使用することはできません。
キャッシュの検索能力は、analyzer & tokenizer & filterですが、キャッシュではありません。
Solrをドキュメントストアとして使用することは嫌いです（検索インデックスと比較して）が、ユースケースが「IDによるドキュメントの最新のベリファイ」である場合、Realtime Getは次のようになります。https ：//cwiki.apache.org/confluence/display/solr/RealTime+Get – randomstatistic
確かに、リアルタイム取得はアクセス速度を向上させますが、検索機能が失われてもまだ最適化されていません。したがって可能ですが、そのような操作のために特別に設計されたものからの切り替えにはお勧めできません。 –