lucene 为什么TieredMergePolicy比其他策略更好?

nzkunb0c  于 2022-11-07  发布在  Lucene
关注(0)|答案(2)|浏览(245)

我正在学习ElasticSearch和Apache Lucene。
最近,我发现Apache Lucene有一些合并策略,但是ElasticSearch使用TieredMergepolicy而不是其他合并策略,如LogMergepolicy和LogByteSizeMergepolicy。
所以我一直在搜索有关TieredMergepolicy的信息。我找到了算法,但我看不出为什么TieredMergepolicy比其他算法更好(我的意思是在一般情况下,而不是特殊情况下)
为什么在段合并时挑选相似大小的段是重要的,以及它如何影响整体性能?
请帮帮我。

pgky5nke

pgky5nke1#

在这个Chinese post的主题中,我发现了下面的语句,它提供了一些关于TieredMergePolicy优于LogByteSizeMergePolicy的好处的见解,LogByteSizeMergePolicy是Lucene在TieredMergePolicy之前的默认合并策略:
TieredMergePolicyLogByteSizeMergepolicy的区别在于前者可以合并非相邻的线段,并且区分了一次允许合并的最大线段数setMaxMergeAtOnce(int v)和一个层中允许的最大线段数setSegmentsPerTier(double v)
对于TieredMergePolicy的更广泛的解释,一个很好的来源是github上对该类的评论。以下信息来自该来源,并在Apache 2许可证下提供:
合并大小大致相等的段,但每层允许的段数受限。这类似于LogByteSizeMergePolicy,不同之处在于此合并策略能够合并不相邻的段,并将一次合并的段数(setMaxMergeAtOnce)与每层允许的段数(setSegmentsPerTier)分开。此合并策略也不会过度合并(即级联合并)。
对于正常合并,此策略首先计算索引中允许的段数的“预算”。如果索引超出预算,则此策略将按大小递减对段进行排序(按删除百分比按比例分配),然后查找成本最低的合并。合并成本由合并的“偏差”和(最大段的大小除以最小段的大小)、总合并大小和回收的删除百分比,以便优先选择具有较低偏斜、较小大小和回收更多删除的合并。
如果合并将产生大于'setMaxMergedSegmentMB'的段,则该策略将合并较少的段(如果该段有删除,则一次合并1个),以使段大小保持在预算之内。

注意:此策略可自由合并不相邻的段;如果这是一个问题,请使用'LogMergePolicy'。
注意:此策略始终按段的字节大小合并,始终按删除百分比按比例分配
注意从Lucene 7.5开始,有几处变更:+'findForcedMerges'和'findForcedDeletesMerges')在默认情况下遵守最大段大小。+当使用'maxSegmentCount'而不是1调用'findForcedmerges'时,产生的索引并不保证有〈='maxSegmentCount'个段。相反,它是基于“尽力而为”的原则。具体来说,计算理论上的理想段大小,并添加25%的“fudge因子”作为新的'+'findForcedDeletesMerge'不会产生大于'maxSegmentSize'的段。

ubbxdtey

ubbxdtey2#

TieredMergePolicy首先计算索引中应包含多少段的允许“预算”,方法是计算给定总索引大小、最小段大小时“完美对数阶梯”需要多少步(已被锁定),立即合并,以及允许您设置允许宽度的新配置maxSegmentsPerTier楼梯中每个楼梯的(段数)。这很好,因为它将一次合并多少段与楼梯可以有多宽解耦。

相关问题