Solr filterCache、firstSearcher、newSearcherはどのように設定すればよいですか？

Question

質問1：私は自分のsolrconfig.xmlでサーチャーを最適化しようとしていますが、暖かくなる可能性のある2人のサーチャーがいます。私の理解では、firstSearcherはサーバーの起動時にのみ起動します。新しいサーチャーが必要なときは常にnewSearcherが作成されます。私は同じfqsとファセットをそれぞれに指定したいと思う。あなたは彼らが違うようにしたいときはいつですか？

質問2：fqやファセットを追加する際のサーチャーの起動時間に与える影響を調べる方法はありますか？ fqs/facetsを指定して検索するユーザーの起動時間を測定することはできませんが、それほど細かくはありません。個々のfq /ファセットのコスト/便益があると仮定して、それを測定できるようにしたいので、温暖化の価値があるものとそうでないものを決めることができます。

質問3：filterCacheの効果的なサイズ設定を行うにはどうすればよいですか？私は特定のセットのfqを持っていることを知っています。そのうち約500個があるので、私は500に設定したようです。しかし、Solrは、面倒を見なければならないクエリ結果に対してfilterCacheを使用しているようです。私のクエリの90％はファセットであるため、キャッシュサイズの基準として予想されるクエリの数を使用する必要があるようです。それは正しいと思いますか？

Answer 1

1. ご理解の方が正しいです。しかし、newSearcherは最後のものから自動ワームすることができるので、違いがあります。もう1つは、newSearcherがコミットごとに発生するため、コミットを頻繁に行っている場合は、寒いから始めるよりもかなり少ない作業しかしたくないということです。

2. 私は素晴らしい方法を知らない。クエリは連続して実行され、少なくともfirstSearcherを使ってアクセスログに表示されるので、文字通りどのくらいの時間がかかるかを知ることができます。与えられたクエリセットの結果が「十分に暖かい」ものであるかどうかは、かなりの試行錯誤です。

3. FilterCacheのサイズについて覚えておくべき最も重要な点は、1つのエントリが周囲（インデックス内のドキュメントの数）/ 8バイトであることです。したがって、サイズを500に設定すると、インデックスに100Mのドキュメントがある場合は、保持するためにヒープを6.25G必要になります。一般的には、ヒープのサイズをできるだけ小さくして、ディスクキャッシュのメモリを増やすことをお勧めしますが、これは例外です。あなたのキャッシュに追いつき圧力をかけているファセットクエリが出てくる限り、私は同じ問題を抱えています。私は何の解決策も知らないのです。 https://issues.apache.org/jira/browse/SOLR-8171を参照してください。