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