検証した環境

Solr:8.6（Cloud シャード:1,NRT:2)

セグメント(Segment)とは

Solrはコミットをするとインデックスに書き込みをします、内部的にはセグメントと呼ばれる単位で分割されています。
Segmentはインデックスを更新してコミットを実行するたびに新しいセグメントが作成されます。

例1

100件のドキュメントを登録してコミットする

パラメータ	数値
Num Docs	100
MaxDoc	100
Deleted Docs	0
Segment Count	1

_0 -> docs:100, dels:0

更に30件新規のドキュメントを登録してコミットする

パラメータ	数値
Num Docs	130
MaxDoc	130
Deleted Docs	0
Segment Count	2

_0 -> docs:100, dels:0
_1 -> docs:30, dels:0

あとから登録した30件は_1のセグメントに含まれます。

例2

次は100件登録してコミットしたあとに30件のドキュメントを更新してコミットしてみます。

パラメータ	数値
Num Docs	100
MaxDoc	130
Deleted Docs	30
Segment Count	2

_0 -> docs:100, dels:30
_1 -> docs:30, dels:0

ドキュメントの更新の場合は0のセグメントのうち、1のセグメントに含まれるドキュメントは削除済みとして扱われます。

セグメントのマージ

ドキュメントの追加、更新、削除を繰り返すとセグメント数が増えていきます。
セグメント数が多くなると検索性能が劣化していきます。
また例２の場合のように削除済みとしてマークされているものは検索時には使用されないですがディスク上に残ってしまうので無駄になってしまいます。
なのでsolrではセグメントをマージする機能があります。

セグメントのマージ方法

optimizeによる強制マージ
コミット時にMergePolicyによるマージ
expungeDeletesによるマージ

optimizeによる強制マージ

※ optimizeによる強制マージはあまり推奨されていないようです。 MergePolicyを利用したマージを使うほうが主流のようです。

curl -X POST -H 'Content-Type: application/json' 'http://localhost:8981/solr/{collection}/update' --data-binary '
{
  "optimize": {maxSegments:1}
}'

MergePolicyによるマージ

今回はデフォルトのマージポリシーのTieredMergePolicyについてまとめます。

マージに関連するsolrconfig.xmlの設定

solrconfig.xml

<config>
  <indexConfig>
        <mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
          <int name="segmentsPerTier">10</int>
          <int name="floorSegmentMB">2</int>
          <int name="deletesPctAllowed">33</int>
          <int name="maxMergedSegmentMB">5000</int>
          <int name="maxMergeAtOnce">10</int>
          <int name="forceMergeDeletesPctAllowed">10</int>
        </mergePolicyFactory>
  </indexConfig>
</config>

マージのしきい値となる設定

segmentsPerTier(デフォルト値:10)

階層のSegment Countがしきい値(allowedSegCount)の設定値を超えると、次回のコミット時にマージが実行されます

SegmentCount > allowedSegCount

デフォルトの10だとSegment Countが11になるとしきい値を超えるので次のコミット時にマージされます。
（※ドキュメントのトータルのサイズが小さい時）

「0」から「9」がマージされbになる

allowedSegCountの算出方法

TieredMergePolicyでは以下のロジックでallowedSegCountが決定します。

    final int mergeFactor = (int) Math.min(maxMergeAtOnce, segsPerTier);
    long levelSize = Math.max(minSegmentBytes, floorSegmentBytes);
    long bytesLeft = totIndexBytes;
    double allowedSegCount = 0;
    while (true) {
      final double segCountLevel = bytesLeft / (double) levelSize;
      if (segCountLevel < segsPerTier || levelSize == maxMergedSegmentBytes) {
        allowedSegCount += Math.ceil(segCountLevel);
        break;
      }
      allowedSegCount += segsPerTier;
      bytesLeft -= segsPerTier * levelSize;
      levelSize = Math.min(maxMergedSegmentBytes, levelSize * mergeFactor);
    }
    allowedSegCount = Math.max(allowedSegCount, segsPerTier);

floorSegmentBytes = floorSegmentMB * 1024 * 1024

solrconfig.xmlで指定できる、floorSegmentMBの値を上げるとallowedSegCountの値も上がりにくくなります。

floorSegmentMB=1と設定した場合

ドキュメントのトータルサイズが、10MBを超えるとallowedSegCount=12に変化します。

deletesPctAllowed(デフォルト値:33)

Deletionsの割合がdeletesPctAllowedを超えると、次回のコミット時にマージが実行されます

Deletions = \frac{Deleted Docs}{MaxDoc} * 100 > deletesPctAllowed

33%超えるとピンク色になるので次回のコミット時にマージされるのがわかります。

マージするセグメント数の設定

maxMergeAtOnce(デフォルト値:10)

マージが実行されるときにmaxMergeAtOnceの値までのセグメントがマージの対象となります

maxMergeAtOnce=2,maxMergedSegmentMB=5000の場合

マージ対象がmaxMergeAtOnceの0,1だけが対象となります。

maxMergedSegmentMB(デフォルト値:5000)

マージが実行されるときにマージするセグメントの合計サイズがmaxMergedSegmentMBを超えない範囲が対象となります。

maxMergeAtOnce=10,maxMergedSegmentMB=1の場合

この場合は0から4までがmaxMergedSegmentMBの値に収まるのでマージの対象となっていることがわかります。

expungeDeletes

コミット時にexpungeDeletesというのを指定することができます。

curl -X POST -H 'Content-Type: application/json' 'http://localhost:8981/solr/{collection}/update' --data-binary '
{
  "commit": {expungeDeletes: true}
}'

expungeDeletesを指定すると削除済みが含まれるセグメントがマージされます。
このときセグメント単体でみた削除のドキュメントの割合がforceMergeDeletesPctAllowed以下の場合は対象外となります。

expungeDeletesを実行

削除を含むセグメント0と1がマージされ4になりました。

Solr8系のセグメントのマージの動作とsolrconfig.xmlの設定について(SolrCloud)