マージポリシーの最大セグメントサイズ + 再インデックス化
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/sx5nbg1shrvjwos0vlvyznw45x82w6xl into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
マージポリシーのファクトリ設定で、デフォルトより大きな最大セグメントサイズを設定しました。この設定を変更してクラウドを再起動した場合、Lucene のセグメントは自動的に分割されて、新しい小さい最大セグメントサイズに適合するようになりますか？ それとも、データの完全な再インデックス化が必要になりますか？
-Kevin Liang
私の知る限りでは、再インデックス化は必要ありません。ただし、NRT（Near Real-Time）が発生していない場合に、上記の変更が反映されるかどうかは確信が持てません。
こちらの記事が参考になると思います：
Visualizing Lucene's segment merges
ありがとうございます。
Ramesh
申し訳ありません、最初のメッセージの表現が適切ではありませんでした。
現在、より大きな最大セグメントサイズ（例えば 10GB）を設定しており、これを 5GB に減らすように設定を更新したいと考えています。この変更を反映させるには、再インデックス化が必要でしょうか？
私が見た限りでは、セグメントのマージ（つまり、2つのセグメントを結合して大きなセグメントにする）に関するコードや説明しかなく、セグメントの分割に関するものは見当たりません（おそらく分割は発生しないのではないかと思いますが）。
はい、設定を更新して最大セグメントサイズを縮小した場合に、Solrがセグメントを分割するのか気になっています。
間違っていたら訂正してください。すでにマージされたセグメントを分割することにメリットがあるのか疑問です。私の理解では、大きな単一のセグメントはクエリに有利であり、小さな複数のセグメントはインデックス作成に有利ですが、そのメリットはあくまでインデックス作成中のみです。そのため、すでにマージされたインデックスを分割しても、インデックス作成が速くなるわけではありません。なぜなら、負荷の高い処理はすでに完了しているからです。
元の質問についてですが、テストして確認しないと確実なことは言えませんが、Solrがすでにマージされたインデックスに戻ってそれを分割するとは考えにくいです。これは、すでに最適化されたハードディスクを意図的に断片化するようなものです。ドキュメントには次のように記載されています。
新しいセグメントを作成すると、最下層のセグメント数が
mergeFactorの値を超える場合、それらのセグメントはすべて1つの大きなセグメントにマージされる。
この記述から私が理解するのは、Solrは常にセグメントを1つに統合しようとするということです。設定できるのは、どの程度のセグメント数で最初のマージが発生するかのみです。mergeFactor の値が低いと、マージが頻繁に発生し、負荷の高いインデックス作成時にノードに追加の負担がかかることになります。
-ufuk
Lucene（およびSolr）はセグメントを分割しません。
唯一、それに近い動作をする可能性があるのは、「rewrite」メソッドを使用したシャード分割の場合です。
トピックへ返信するには、ログインが必要です。