[4]es 段合并的原理和作用

本文集主要是总结自己在项目中使用ES 的经验教训，包括各种实战和调优。

elasticsearch 中每个索引都会创建一个到多个分片和零个到多个副本，这些分片或副本实质上都是lucene索引。

lucene索引是基于多个索引段创建，索引文件中绝大部分数据都是只写一次，读多次，而只有用于保存文档删除信息的文件才会被多次更改

在某些时刻，当某种条件满足时，多个索引段会被拷贝合并到一个更大的索引段，而那些旧的索引段会被抛弃并从磁盘中删除，这操作叫做段合并

进行段合并的原因

索引段的个数越多，搜索性能越低且消耗内存更多
索引段是不可变的，物理上你并不能从中删除信息（如果你碰巧从索引中删除了大量文档，但这些文档只是做了删除标记，物理上并没有被删除）而当段合并发送时，这些标记为删除的文档并没有被复制到新的索引段中。
注：elasticsearch在进行删除时，是不会直接物理删除，而是对要删除的对象进行标记，在进行段合并的时候不复制这些数据到新的索引段中。

elasticsearch允许用户选择段合并政策（merge policy）及储存级节流（store level throttling）

一般不需要修改段合并的默认设置，在记录日志时，日志是按照每天，周，月存入索引。旧的索引一般是只可读的，它们是不可能修改的。这种情况下，把每个索引的段降至1是有效的。搜索过程就会用到更少的资源，性能更好。

尽管段合并是lucene的责任，elasticsearch也允许用户配置想用的段合并策略
到目前为止有三种可用的合并策略：

为了告知elasticsearch我们想使用的段合并策略，可以将配置文件的index.merge.policy字段泪痣成我们期望的段合并策略类型例如：index.merge.policy.type: tiered

es允许我们定制合并策略的执行方式，调度器分两种
默认的是并发合并调度器 ConcurrentMerge-Scheduler

该调度器使用多线程执行索引合并操作

它使用同一个线程执行所有的索引合并操作，在执行合并时，该线程的其他文档处理都会被挂起，从而索引操作会延迟进行

通过每秒自动刷新创建新的段，用不了多久段的数量就爆炸了。有太多的段是一个问题。每个段消费文件句柄，内存，cpu资源。更重要的是，每次搜索请求都需要依次检查每个段。段越多，查询越慢。

ES通过后台合并段解决这个问题。小段被合并成大段，再合并成更大的段。

这是旧的文档从文件系统删除的时候。旧的段不会再复制到更大的新段中。

这个过程你不必做什么。当你在索引和搜索时ES会自动处理。这个过程如图：两个提交的段和一个未提交的段合并为了一个更大的段所示：

图1：两个提交的段和一个未提交的段合并为了一个更大的段

图2：段合并完后，旧的段被删除

合并大的段会消耗很多IO和CPU，如果不检查会影响到搜素性能。默认情况下，ES会限制合并过程，这样搜索就可以有足够的资源进行。

optimize API最好描述为强制合并段API。它强制分片合并段以达到指定max_num_segments参数。这是为了减少段的数量（通常为1）达到提高搜索性能的目的。

警告
不要在动态的索引（正在活跃更新）上使用optimize API。后台的合并处理已经做的很好了，优化命令会阻碍它的工作。不要干涉！

在特定的环境下，optimize API是有用的。典型的场景是记录日志，这中情况下日志是按照每天，周，月存入索引。旧的索引一般是只可读的，它们是不可能修改的。这种情况下，把每个索引的段降至1是有效的。搜索过程就会用到更少的资源，性能更好:

POST /logstash-2014-10/_optimize?max_num_segments=1 <1>

参考链接：