SolrでのDistributed IDF（逆文書頻度）の使用におけるExactStatsCacheの問題
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/s1bm9kxf07ngpglxy1vt2tmx8tcsy1zn into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
私はSolrを分散環境で使用しており、コレクションを複数のパートに分けて、それぞれ異なるノードで動作させています。各パートを作成するときには、numShardsとreplicationFactorを1に設定しています。クエリの速度が最も重要であり、システムの負荷については心配していません。
コレクション全体でDistributed IDFを使用したいので、solrconfig.xmlに以下の行を追加しました：
<statsCache class="org.apache.solr.search.stats.ExactStatsCache" />
これで約90％の確率で正常に動作するようですが、同じリクエストを何度も実行すると、時々コレクションの一部のローカルIDFのみを使用したスコアが得られます。以下はリクエストの例です：
/solr/collection1,collection2/query?q=fulltext:shark&rows=500&fl=id,url,title,score&sort=score+desc
このリクエストで、collection1とcollection2の両方からドキュメントは取得できますが、時々、collection1のみをクエリしたときと同じスコアが得られます。その場合、用語のドキュメント頻度として、collection1のものだけが使用されていると思われます。
別の設定を使用すべきでしょうか？同じクエリを実行するたびにIDFが常に分散され、同じであることを確認したいです。これを確実にするための技術があれば教えてください。
ありがとうございます、
Cameron VandenBerg
こんにちは、
私は5つのシャードと2つのレプリカを持つSolrCloudを使用しています。
LocalStatsCache、ExactStatsCache、ExactSharedStatsCacheを何度も試しました。
LocalStatsCacheとExact系のものの間で若干の利点が見られました。
しかし、実際には、1ページに10件の検索結果を表示している間は良好ですが、
2ページ目（11〜20件目）に移動してページを数回リロードすると、
ページ内の結果が変わりました。例えば、ヒット番号14として表示されていた結果が次回にはヒット番号16としてリストされました。これが繰り返され、信頼性に欠けました。
最初のページだけが見た目は良好でした。
スコアを調べると、ExactStatsCacheおよびExactSharedStatsCacheを使用してもリロードごとに若干の変動がありました。
さらにレプリカを確認すると、完全に同期していることはありませんでした。
つまり、ドキュメント数とセグメント数は同期しているが、それ以外は異なっていました。
coll1_shard1_replica1:
Num Docs: 53576786
Max Doc: 57506559
Deleted Docs: 3929773
Version: 135351
Master (Searching) 1616078264682 22756
Master (Replicable) 1616402397518 22844
coll1_shard1_replica2:
Num Docs: 53576786
Max Doc: 57494890
Deleted Docs: 3918104
Version: 135326
Master (Searching) 1616078264683 22755
Master (Replicable) 1616402397521 22843
Num Docsだけが同じで（そのため常に同じ数のヒットと同じヒットが得られる）、他のすべては異なっています。
これがExactStatsCacheやExactSharedStatsCacheを使用しても、常に同じ結果の順序が得られない理由だと思います。CloudSolrjを使用してロードしています。
一度テストを行い、インデックスを最適化しました。
まずexpungeDeletes trueでコミットし、その後maxSegments 1で最適化しました。
その後、すべてが正常に機能し、結果の順序が維持されました。
しかし、数週間後にはセグメント数が再びずれて、問題が再発しました。
これは正しく機能しないと思います。
レプリカが完全に同期している場合のみ、正しく動作する可能性があります。
コードのデバッグを行わずに得られた私の見解です。
よろしく、
Bernd
Cameron、
あなたのクラスタ構成はどのようになっていますか？つまり、ノードの数、各ノードあたりのレプリカの数、各コレクション内のレプリカの数などです。同じ「エントリーノード」（つまり、クラスタ全体で負荷分散しないノード）を通じて常にクエリをルートさせた場合、同じクエリに対して一貫した動作を観察できますか？
Michael
こんにちは Michael、
私の環境では、8つのシャード（8つの異なるノード上）にレプリカなしで約5億件のドキュメントがあります。さらに、レプリカなしでシャードが2つだけのコレクション（ドキュメント数はかなり少ない）もあり、同じ動作が見られます。同じ「エントリーノード」を通じてクエリをルートさせた場合でも、この動作が観察されます。この動作を見るには、同じクエリでリフレッシュを数回実行するだけで十分です。ほとんどの場合、スコアは分散IDFを反映しますが、時々、シャードの1つだけのIDFを反映するスコアが表示されることがあります（両方のシャードからドキュメントが返されるにもかかわらず）。
ありがとうございます！
Cameron VandenBerg
私もあなたと同じ現象を確認しています。問題を再確認するために（おそらくあなたが既に確認済みの内容を多く含むでしょうが）、要点をまとめてみます：
この問題は特に複数コレクションのリクエストに関連しているようです（単一のコレクションに対するリクエストではこの問題を確認していません）。スコアの「explain」をチェックすると（`debug=true`）、複数コレクションのリクエストでは、idf計算のために分散`docCount`を取得する際に、一方のコレクションが選ばれるようです（おそらく非決定的に？）。これは明らかに望ましくないようです。特に、クエリされた2つのコレクションのサイズが非常に異なる場合、分散idfが同時に必要かつ役に立たないことが明らかです（現在の実装では）。
私が何か見落としている場合には誰かに反論してほしいですが、現時点では内部で何が起こっているのか正確にはわかりません。しかし（あなたが言ったように）単一コレクションのidfが単純な複数コレクションのリクエストに対して使用されていることは確信しており、それが望ましいケースは思い浮かびません（statsCacheの設定を通じて分散idfを優先するという前提で）。
考えられる問題の一つは、statsCacheがコレクションごとに設定されているため、異なるstatsCachesを持つ2つのコレクションが共同でクエリされた場合、どの設定が優先されるのかを決定する方法があるのかということです。... そしておそらく関連するフォローアップの質問も出てくるでしょう。大きな問題ではないかもしれませんが、それでもやはり...
この問題を提起するために何かできることはありますか？これをJiraに登録してもよいですか、それとも最初に他のチャネルに行く必要がありますか？
ありがとうございます、
Cameron VandenBerg
トピックへ返信するには、ログインが必要です。