elasticsearch搜索引擎-关于段合并思考
Posted 水的精神
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了elasticsearch搜索引擎-关于段合并思考相关的知识,希望对你有一定的参考价值。
段合并对于es来说是一件至关重要的事情。因为段是es发生检索的最小执行单元。一个索引的数据是由分片组成的,分片是一个lucene实例,而分片又是由段组成的。因此,一个检索任务,最终是在每一个段中执行完检索,最后合并结果的。
因此了解段就显得至关重要。段的优劣,直接决定了检索的性能。常用es的,大家可能会遇到一个情况,就是es用着用着越来越慢了。段合并问题是一个重要的影响因素。
通过这篇文章,我们将深入的了解段合并流程,段合并过程,段合并策略,已经段合并问题。我参看的文档原文为:
- LogMergePolicy-html (通过这篇文章,我们将会学到段合并的一些基础知识。了解到段合并的过程。其中LogMergePolocy 是lucene 最早版本的合并策略)
- TieredMergePolicy-html (将会学到 lucene默认的合并策略,已经为什么要有第二中策略,来替换更新前边的策略)
以上两篇文章,实际上对应的是lucene的两种段合并策略。
带着问题读文章
我是在寻找es索引为什么在使用一段时间之后变慢的原因。 所以研究了段合并的问题。段合并只是一个点,但是至关重要。
问题列表:
- 为什么需要段合并。
- 为什么TieredMergePolicy 合并策略,会成为默认的段合并策略,替换了LogMergePolicy
- 什么时候发生段合并。
- 段合并的过程究竟是怎么样的。
- 我认为本片文章最重要的问题:什么时候就不再进行段合并(段合并的条件是什么)已经不进行段合并,会有什么致命的问题?这个问题也是我最初问题的答案。
问题一:为什么需要段合并
通过读上边的两篇文章,我基本上已经能够知道段合并的细节问题。其实段合并有两个目的
- 想要降低段的个数。把小段合并成大段,合并成大段,利于检索。
- 段合并其实上想要调整段的大小,尽可能的使段均匀。
问题二:为什么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搜索引擎:ES的segment段合并原理
ElasticSearch探索之路集群与分片:选举动态更新近实时搜索事务日志段合并