elasticsearch搜索引擎-关于段合并思考

Posted 水的精神

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了elasticsearch搜索引擎-关于段合并思考相关的知识,希望对你有一定的参考价值。

  段合并对于es来说是一件至关重要的事情。因为段是es发生检索的最小执行单元。一个索引的数据是由分片组成的,分片是一个lucene实例,而分片又是由段组成的。因此,一个检索任务,最终是在每一个段中执行完检索,最后合并结果的。

  因此了解段就显得至关重要。段的优劣,直接决定了检索的性能。常用es的,大家可能会遇到一个情况,就是es用着用着越来越慢了。段合并问题是一个重要的影响因素。

  通过这篇文章,我们将深入的了解段合并流程,段合并过程,段合并策略,已经段合并问题。我参看的文档原文为:

  •  LogMergePolicy-html (通过这篇文章,我们将会学到段合并的一些基础知识。了解到段合并的过程。其中LogMergePolocy 是lucene 最早版本的合并策略)
  • TieredMergePolicy-html (将会学到 lucene默认的合并策略,已经为什么要有第二中策略,来替换更新前边的策略)

  以上两篇文章,实际上对应的是lucene的两种段合并策略。

带着问题读文章

  我是在寻找es索引为什么在使用一段时间之后变慢的原因。 所以研究了段合并的问题。段合并只是一个点,但是至关重要。

  问题列表:

  1. 为什么需要段合并。
  2. 为什么TieredMergePolicy 合并策略,会成为默认的段合并策略,替换了LogMergePolicy
  3. 什么时候发生段合并。
  4. 段合并的过程究竟是怎么样的。
  5. 我认为本片文章最重要的问题:什么时候就不再进行段合并(段合并的条件是什么)已经不进行段合并,会有什么致命的问题?这个问题也是我最初问题的答案。

问题一:为什么需要段合并

通过读上边的两篇文章,我基本上已经能够知道段合并的细节问题。其实段合并有两个目的

  1. 想要降低段的个数。把小段合并成大段,合并成大段,利于检索。
  2. 段合并其实上想要调整段的大小,尽可能的使段均匀。

问题二:为什么TieredMergePolicy 合并策略,会成为默认的段合并策略,替换了LogMergePolicy

   这个问题,从文章中也能找到答案。我们先看两个合并策略上的差别:

  • LogMergePolicy总是合并相邻的段文件,合并相邻的段文件(Adjacent Segment)描述的是对于IndexWriter提供的段集,LogMergePolicy会选取连续的部分(或全部)段集区间来生成一个待合并段集
  • TieredMergePolicy中会先对IndexWriter提供的段集进行排序,然后在排序后的段集中选取部分(可能不连续)段来生成一个待合并段集,即非相邻的段文件(Non-adjacent Segment)

  此外,这个问题也要和第一个问题关联起来,段合并的目的。通过了解LogMergePolicy策略我们知道,它是把相邻的段进行合并。但是这样并不能达到段合并的第二个目的(使段均匀)

  在了解TieredMergePolicy以后,我们可以知道,它使用了更多的算法来优化段合并的过程。它对段进行的打分(了解文章二中的打分算法规则即可),并做了排序,然后有限合并小段。显然合并小段花费更少的资源,且会带来更好合并效果。

问题三:什么时候发生段合并

  某次提交(commit)或者刷新(flush)的所有索引文件属于一个新的段(Segment),所以也可以称为段合并(Segment Merge)。当IndexWriter索引中的数据有任意修改动作,它会调用findMerges(...)方法通过某个合并策略(MergePolicy)来找出需要合并的段集,如果需要合并,那么合并策略会返回一个oneMerge的集合,oneMerge的个数描述了IndexWriter需要执行合并的次数,单个oneMerge中包含了需要合并为一个新段(New Segment)的段集合。

  另外段合并的条件是(TieredMergePolicy 默认段合并策略下):

  • 默认的限制段合并的大小为5G,也就是说当一个段的大小大于 2.5G就不再发生段合并,段的大小需要小于 2.5G,这个是一个参数,我们可以控制(配置)。
  • 段中删除数据的大于设定的比例值,默认为三分之一,也就是当删除的数据大于该段总大小的三分之一,就会符合段合并的条件。这个我们可以设置,可设置的范围为:20% - 50%。

  以上连个条件为或的关系,满足其中一个就可以进行段合并。

问题四:段合并的过程究竟是怎么样的

  直接从原文找答案吧。

问题五:什么时候就不再进行段合并 + 不再段合并会有什么问题

  在问题三中,已经说了段合并的两个条件,当两个条件都不满足的情况下,则段不能合并。

  此时在极端情况,如果发生了,段的大小大于2.5G。且删除的数据不够百分之三十。则这个大段不会发生段合并,假如段中删除的内容又比较多,就是很大的问题。它门会占用我们我们的磁盘空间,相当于是发生了磁盘空间泄露。另外,在检索过程中,实际上是,检索出所有的数据,然后再去掉标记删除的数据,如果迟迟不能发生段合并,无法将删除的数据释放出去,则会给检索过程带来负面影响。

  

以上是关于elasticsearch搜索引擎-关于段合并思考的主要内容,如果未能解决你的问题,请参考以下文章

关于 elasticsearch 近实时特征的思考

ElasticSearch 段合并

Elasticsearch搜索引擎:ES的segment段合并原理

ElasticSearch探索之路集群与分片:选举动态更新近实时搜索事务日志段合并

ElasticSearch探索之路集群与分片:选举动态更新近实时搜索事务日志段合并

ElasticSearch探索之路集群与分片:选举动态更新近实时搜索事务日志段合并