Elasticsearch里面的segment合并

经过前面的文章，咱们已经知道在elasticsearch中每一个shard每隔1秒都会refresh一次，每次refresh都会生成一个新的segment，按照这个速度过不了多久segment的数量就会爆炸，因此存在太多的segment是一个大问题，由于每个segment都会占用文件句柄，内存资源，cpu资源，更加剧要的是每个搜索请求都必须访问每个segment，这就意味着存在的segment越多，搜索请求就会变的更慢。

那么elaticsearch是如何解决这个问题呢？ 实际上elasticsearch有一个后台进程专门负责segment的合并，它会把小segments合并成更大的segments，而后反复这样。在合并segments的时候标记删除的document不会被合并到新的更大的segment里面，全部的过程都不须要咱们干涉，es会自动在索引和搜索的过程当中完成，合并的segment能够是磁盘上已经commit过的索引，也能够在内存中还未commit的segment：

（1）在索引时refresh进程每秒会建立一个新的segment而且打开它使得搜索可见

（2）merge进程会在后台选择一些小体积的segments，而后将其合并成一个更大的segment，这个过程不会打断当前的索引和搜索功能。

（3）一旦merge完成，旧的segments就会被删除，流程以下：

3.1 新的segment会被flush到磁盘

3.2 而后会生成新的commit point文件，包含新的segment名称，并排除掉旧的segment和那些被合并过的小的segment

3.3 接着新的segment会被打开用于搜索

3.4 最后旧的segment会被删除掉

至此原来标记伪删除的document都会被清理掉，若是不加控制，合并一个大的segment会消耗比较多的io和cpu资源，同时也会搜索性能形成影响，因此默认状况下es已经对合并线程作了资源限额以便于它不会搜索性能形成太大影响。

api以下：

PUT /_cluster/settings
{
    "persistent" : {
        "indices.store.throttle.max_bytes_per_sec" : "100mb"
    }
}

或者不限制：

PUT /_cluster/settings
{
    "transient" : {
        "indices.store.throttle.type" : "none" 
    }
}

es的api也提供了咱们外部发送命令来强制合并segment，这个命令就是optimize，它能够强制一个shard合并成指定数量的segment，这个参数是：max_num_segments ，一个索引它的segment数量越少，它的搜索性能就越高，一般会optimize成一个segment。须要注意的是optimize命令不要用在一个频繁更新的索引上面，针对频繁更新的索引es默认的合并进程就是最优的策略，optimize命令一般用在一个静态索引上，也就是说这份索引没有写入操做只有查询操做的时候是很是适合用optimize来优化的，好比说咱们的一些日志索引，基本都是按天，周，或者月来索引的，只要过了今天，这周或这个月就基本没有写入操做了，这个时候咱们就能够经过optimize命令，来强制合并每一个shard上索引只有一个segment，这样查询性能就能大大提高，api以下：

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

注意，由外部发送的optimize命令是没有限制资源的，也就是你系统有多少IO资源就会使用多少IO资源，这样可能致使某一段时间内搜索没有任何响应，因此若是你计划要optimize一个超大的索引，你应该使用shard allocation功能将这份索引给移动到一个指定的node机器上，以确保合并操做不会影响其余的业务或者es自己的性能。