elasticarch的段合并机制
es创建⼀个document的时候会向translog和in memory buffer中写⼊，为了近实时性，会将buffer中的数据写⼊到gment，进⼊了gment的数据才能被搜索到。
1. es默认每秒钟refresh创建⼀个gment
2. 后台将这些⼩的gment合并成⼤的gment。每次的⽂档删除操作，会仅仅标记 Segment 中该⽂档 为删除状态， ⽽不会真正的
⽴马物理删除，在段合并的时候不会把已删除的⽂档拷贝到新的gment中。
（上图中两个已经通过flush提交到磁盘的gment和⼀个未提交的gment⼀起合并到⼀个⼤的gment）
3. 新的gment被flush到磁盘，写⼊⼀个包含新段且排除旧的和较⼩的段的新提交点。然后删除⽼的段
Elasticarch 在默认情况下会对合并流程进⾏资源限制，为了给搜索功能留⾜够的资源。默认的限速配置为20mb，如果磁盘转速⾼可以适当调⼤
PUT /_cluster/ttings
{
"persistent":{
"indices.store.throttle.max_bytes_per_c":"100mb"
}
}
optimize API是⼀个合并的api，它会将⼀个分⽚强制合并到 max_num_gments 参数指定 ⼤⼩的段数⽬
POST /logstash-2014-10/_optimize?max_num_gments=1
#java中
forceMergeRequest.maxNumSegments(1)
gment归并策略policy：
可以在tting中配置
#默认2MB，⼩于这个⼤⼩的 gment，优先被归并
"policy.floor_gment":"10mb"
#归并的线程数
"scheduler.max_thread_count":"1"
#默认⼀次最多归并 10 个gment
"policy.max_merge_at_once":"10"
#默认optimize 时⼀次最多归并30个gment。
"policy.max_merge_at_once_explicit":"10"
#默认5GB，⼤于这个⼤⼩的gment，不参与归并。optimize除外
"policy.max_merged_gment":"5gb"
