Solr Cloud v8.10の最適なシャーディング戦略について
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/bncwfpfcsdlgjkf503cdjny5570w2g3j into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、みなさん。
Solr Cloud（v8.10、8ノード）の応答時間を短縮しようとしています。これを達成するために、Solr Cloudのシャード数を増やして、各シャードのデータサイズを減らし、それにより応答時間を短縮することを試みました。
以下のシャーディング戦略に関していくつかの質問があります。
理想的なシャード数を決めるにはどうすればよいですか？ 使用すべきシャードの最小または最大数はありますか？
シャードのサイズをどこまで減らすと、応答時間に効果がなくなるのでしょうか（データ集約などの他の要因による時間がそれを補うようになる場合）？
シャードに保持すべきデータのサイズに何らかの上限がありますか？
現在、各シャードに約25GBのデータ（1500万～1600万のドキュメント）が存在する8つのシャードが各ノードにあります。シャード数とシャードサイズを決定するための標準的なアプローチを教えてください。どうぞよろしくお願いします。
私の意見を少し述べます：
1) シャードはメモリに収まるくらい小さくして、インデックス全体がキャッシュされるようにするのが理想です。ディスクアクセスが少ないほど速度が上がります。そのため、シャード数はノードに利用可能なメモリ量に依存します。さらに読み取りスループットが必要な場合は、複製数を増やしてください。
2) シャードの数が増えると、ネットワークのやり取りが多くなりすぎる時点があります。
3) シャードあたりの最大ドキュメント数は20億（最近のバージョンで変更がなければ）
-ufuk
こんにちは、
シャーディングに関しては、厳密なルールはなく、多くの場合、ワークロードに応じて測定や実験が必要です。
シャードのサイズ以外にも考慮すべき点があります。なぜクエリが遅いのでしょうか？何行を要求していますか？ファセットやグループ化を使用していますか？
各ノード/シャードには25GBのデータがありますが、各ノードにはどれだけのRAMがあり、そのうちどれだけのRAMをSolr/Javaに割り当てましたか？
一般的な間違いは、Solrに過剰なRAM/ヒープを割り当てて、Linuxで仮想メモリキャッシングが行われなくなることです。
たとえば、ノードに32GBの物理RAMがある場合、そのうち30GBをSolrに与えてはいけません。代わりに、8GBをSolrに割り当て、24GBをディスクキャッシングに利用できるようにします。
他に考慮すべきこととしては、クエリをより効率的な等価物に書き換えることで最適化できるかどうかを確認することです。場合によっては、Solrレベルのキャッシュも役立つことがあります。
シャードの効率に関して言えば、すでに8つのシャードがある場合、16に増やすことはそれほどコストがかかりませんが、1つの障害がリクエストに影響を与えるリスクが高まります。
Jan
これは非常に良いアドバイスです。
最適なシャード数というのはありません。4つのシャードで運用していたクラスターもあれば、現在は96シャードのクラスターと320シャードのクラスターもあります。次に構築するクラスターは、おそらくシャーディングを行わないでしょう。
長いクエリの場合、通常、シャーディングによってほぼ線形のスピードアップが見られます。シャードを2倍にすると、応答時間が半分になります。
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
はい、もし平均的なクエリが多くのドキュメントに触れる（例えば、大規模なORクエリなど）場合や、各ヒットに対して処理が必要（スコアリング、結果変換、ハイライトなど）な場合、シャーディングでデータを分割することが役立つかもしれません。また、100のファセットを要求し、ファセットが遅い場合は、facet.threadsを使ってその部分を加速することができるかもしれません。グルーピングを使用している場合は、collapseを試すこともできます。などなど。データ、クエリ、使用ケースについてさらに詳しく知ることで、最適な対策が見えてくるでしょう。
Jan
@Walter,
一体どうやって320のシャードに対してすべての重要なSolr Cloudパラメーターを監視しているのですか？
よろしくお願いします、
Bernd
大変な作業だと思っていたのですが、実際にはそうではありませんでした。私たちはArgoCDとKubernetesデプロイメントでクラスターを構築しています。ノードはすべてDataDogにレポートしています。唯一の面倒な点は、特定のノードの管理UIに直接アクセスするのが難しいことです。ホスト名や外部からの権限に問題があるようです。
ああ、それと私たちはブルー/グリーンクラスターも運用しているので、これらのビーストが二つあります。
管理UIのグラフィカルディスプレイは非常に印象的です。こちらがその一部のビューです。
コレクションには現在約25億のドキュメントがあります。以前Infoseekで働いていた時、私たちの全ウェブインデックスは1200万のドキュメントでした。
これはLexisNexisでの話です。
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
@Walter、
320のシャードと25億のドキュメントで、クエリスループットはどのようになっていますか？ファンアウトによる内部分散トラフィックが非常に大きいと思いますが。
よろしくお願いします、
Wei
トピックへ返信するには、ログインが必要です。