8つのシャードとレプリケーションファクター8で管理するのは大変でした。その時点で、AWSのより大きなインスタンスに垂直スケールしました。それにより、72 CPUインスタンスまではスムーズにスケールしました。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

ありがとう、Walter。私たちは1対1のマッピングを行っており、各物理サーバーが単一のSolrコアをホストしているため、ノードごとのCPUリソースは十分です。しかし、インデックスサイズが常に増加し、各シャードがX百万ドキュメントしか保持できず、シャードが最大容量に達することを望まないため、シャードの数は数百にまで増加する可能性があります。私の質問は、Solrクラウド/Zookeeperの観点から、シャード（およびそれに対応するノード）の数が一定の閾値に達する際に、ハードリミットやパフォーマンスへの影響はあるのでしょうか？もう一つの選択肢として、データを複数の小さなSolrクラウドに分割することも考えていますが、その場合、異なるクラウドからの結果の集約をSolrの外で処理する必要があり、ソルのスコアの比較やソートの処理などの課題があります。

ありがとうございます、
Wei

私たちは、単一のSolr Cloud内で数百のノードを持つクラスターを運用しており、多くのコレクションがあり、その中には2,048シャードに達するものもあります。一般的に、私たちが直面している課題は、特にクラスター内のノードの再起動時に、state.json の更新を処理することに関連しています。ノードの再起動は、state.json 内のレプリカの状態変更を引き起こすためです。大量のシャードがある場合、state.json ファイルの頻繁な読み書きが発生し、ノードの再起動速度に影響を及ぼす可能性があります。また、state.json 自体がZookeeperのデフォルトファイルサイズ制限である1MBを超えることがあります。このデフォルトの制限はZookeeperで設定できますが、注意が必要です。現在、state.json の圧縮を可能にするPRを上流に提出中です。詳細はここをご覧ください: PR #1267。

また、FullStoryでIshan/Nobleと共に、Per Replica Stateというレプリカの状態管理の代替手段を開発しました。これについてはここで詳しく読めます: Per Replica State。これにより、state.json の読み書きを制限できるため、大規模な運用において効果的でした。

ありがとう、Justin。とても役立ちます。state.json の更新に関する課題は、レプリカの数によって引き起こされるのか、シャードの数によって引き起こされるのか、どちらですか？また、Per Replica State機能はSolr 8.8以降で利用可能ですか？

よろしくお願いします、
Wei

圧縮は興味深いアイデアです。ただし、以下の問題に対して圧縮が効果的かどうかはわかりません：

https://issues.apache.org/jira/browse/SOLR-7191

その時は、state.json はかなり小さかったのですが、数が非常に多かったです。その状況では、ボトルネックはオーバーシアーのようです。オーバーシアーキューの各エントリを処理するのにはかなりの時間がかかります。数千のコレクションを持つSolrノードを再起動すると、オーバーシアーキューに大量の更新が発生します。もしオーバーシアーがもっと速く処理できるなら、その問題は解消されるかもしれません。

ありがとう、
Shawn