Solr の自動ウォーミングとさまざまなキャッシュ メカニズムはどのように機能しますか?

Solr の自動ウォーミングとさまざまなキャッシュ メカニズムはどのように機能しますか?

キャッシュと温暖化について読んでいたのですが、たくさんの疑問が残りました。

Google でここにたどり着きました:https://solr.apache.org/guide/7_3/query-settings-in-solrconfig.html

最新バージョンはここにあるようです:参考:

このドキュメントを読んで、いくつか質問が浮かんだので、ここにリストします。ただし、主な質問は自動ウォーミングに関するものです。

1/ 「インデックス サーチャー」について言及されていますが、これには有効期間を持つインスタンスがあり、これらのインスタンスにはキャッシュがあります。

新しいインスタンスを構築し、古いインスタンスを無効にするプロセスでは、「インスタンス」とは、新しいインスタンスが構築されている間に、古いデータを提供する古いインスタンスがまだ存在する可能性があることを意味すると理解してよいのでしょうか。また、コアに対して複数のインデックス検索が同時に存在するわけではないのでしょうか。

2/ キャッシュ無効化の観点で、これはどのように機能しますか? キャッシュは基本的に検索者であり、1 つのキャッシュが無効化された場合、検索者を他のすべてのキャッシュとともに再作成する必要がありますか?

3/ オートウォーミングは基本的に、古い Index Searcher インスタンスから一連のエントリを取得し、新しいインスタンスに追加すると読んでいます。コピーされたこれらのエントリがまだ有効であるという保証はありますか? つまり、特定のドキュメントやクエリ結果の変更を含むコミットが原因でキャッシュが有効でなくなった場合、古い資料に基づくドキュメント/結果を含む古いエントリのコピーを回避するメカニズムはありますか?

4/ 512 エントリなどの数値を使用するキャッシュの例を見ます。これは低いように思えます。ここで考慮すべきことは何ですか? 新しいインデックス サーチャーを構築する必要があるため、キャッシュは非常に頻繁に再構築されるため、大きなオブジェクトを常に作成して、頻繁に破棄して再構築するのは無駄ですか? それとも、他の何かですか?

5/ アプリケーションが生成したユーザー ID に基づいてドキュメントを作成し、クエリを実行するアプリケーションがあるとします。コア/コレクション「user_documents」が 1 つあり、すべてがそこに格納され、「ユーザー ID」がフィールドになります。このシナリオでは、1 人のユーザーのアクションによってすべてのユーザーのキャッシュが無効になる可能性があるようです。これを回避するにはどうすればよいですか?

6/ フィルターキャッシュに関して、LRU キャッシュの最も古いエントリが新しいエントリに置き換えられると読みました。フィルターキャッシュはクエリの各「fq」のエントリをキャッシュするので、長いクエリがキャッシュから押し出されても、その fq の一部だけが押し出され、他の fq は押し出されないという状況が発生することがありますか? これは悪いことでしょうか?

7/ ドキュメント キャッシュについては、次の行が表示されます。

documentCacheのサイズは常にmax_resultsより大きくする必要があります

Solr がリクエスト中にドキュメントを再取得する必要がないように、max_concurrent_queries の倍数を指定します。

それはどのような意味を持つのでしょうか? 設定の名前としての max_results と max_concurrent_queries に関するドキュメントが見つかりません。

これに時間を割いてくださった皆様に感謝します。

関連情報