elasticsearchmerge

这两周主要看了下 Elasticsearch&＃xff08;其实是Lucene&＃xff09;的 segments 的 merge 流程。事情起因是&＃xff0c;线上的ES有些大索引&＃xff0c;其中的segments 个数几十个&＃xff0c;每个大小100M&＃43;&＃xff0c;小 segments 若干&＃xff0c;而遇到问题就是这些大的 segments 不再做 merge 了&＃xff0c;除非强制进行forceMerge 操作&＃xff0c;由于我们第一次ES上线&＃xff0c;其实也不清楚这究竟是个问题还是本来 Lucene 就是这样&＃xff0c;网上找了一些关于ES 或者 Lucene 的 merge 的策略介绍&＃xff0c;除了说道大家都了解的一些常规的参数&＃xff0c;如最大size&＃xff0c;最大doc 下不会再做merge云云&＃xff0c;就是没提到到了多少个 segments 之后就不 merge &＃xff0c;接着问了Elasticsearch 圈子的一些人&＃xff0c;也没有找到非常确定的答案。查找几天资料无果&＃xff0c;顺带就看看源码&＃xff0c;最终在昨天又瞄了几眼终于发现一段算法&＃xff0c;虽无验证&＃xff0c;但应八九不离十&＃xff0c;故记录分享之。

Segments

首先还是先重温一下 Lucene 下的 segments&＃xff0c;对这个比较陌生的可以阅读三斗大神的这一节

• segment、buffer和translog对实时性的影响

Lucene产生segments示意图

我只引用最下面那张图介绍一下&＃xff0c;绿色的就是已经固化的一个个的 segments 文件&＃xff0c;不会再更新&＃xff0c;左下角就是当前在内存的 Lucene 维护的查询可见的仍为持久化的segment&＃xff0c;当Elasticsearch 配置的refresh_invterval &＃xff08;默认是1s&＃xff0c;可调&＃xff09;到时&＃xff0c;这些in in-memory buffer就会推送到OS的文件系统缓存中去&＃xff0c;注意这里只是到缓存&＃xff0c;很可能OS仍未持久化到文件系统&＃xff0c;成为一个单独的 segment 文件&＃xff0c;而啥时commit 到文件系统永不丢失&＃xff0c;则由Lucene 的flush 机制保证&＃xff0c;当Lucene 做完flush 则表明该 segment 真正推送到文件系统&＃xff0c;此时才会在translog做标记并可以删除commit之前的translog 了。

注意这里只是一个简化描述&＃xff0c;据三斗和赖总介绍&＃xff0c;Lucene 仍有很多因素会促使产生一个segment 而不是百分百由Elasticsearch的refresh_interval 决定。这里就不继续讨论究竟在哪些情况会立即生成一个segment了。

Segment 的merge

详细信息可看三斗这一节 这里只引用两个图介绍一下

merge前

merge后

从图上看&＃xff0c;Lucene每次会选取一些小的segments 进而merge到一个大的segment&＃xff0c;我这里不再赘述流程和策略&＃xff0c;这里只补充一句就是&＃xff0c;如果你之前用的scroll查询&＃xff0c;之前的scroll还是会指向老的segments&＃xff0c;也就是说老的segments 的引用会知道scroll失效后才会被回收。

Elasticsearch 5.x merge 参数的变化

在老的Elasticsearch 中&＃xff0c;merge 被认为是一个非常消耗资源的操作&＃xff0c;甚至只有一个线程来做这事&＃xff0c;并且会影响indexing的request。在之前的版本里&＃xff0c;merge 操作用的是一类 merge throttle limit这样的配置来限制各种峰值数据&＃xff0c;如下面这些参数&＃xff0c;注意这些参数都已经在5.x 中移除掉了。

• indices.store.throttle.type

• indices.store.throttle.max_bytes_per_sec

因为在Elasticsearch 5.x 想采用多线程和动态调整这种方式来更加智能地去执行merge操作。如检测是否使用SSD硬盘&＃xff0c;应该启动多少个merge线程等。
在Elasticsearch 5.x 下&＃xff0c;tired merge policy 成为了唯一的merge策略。因此下面的参数同样也在5.x 下被移除了。

• index.merge.policy.type

• index.merge.policy.min_merge_size
• index.merge.policy.max_merge_size
• index.merge.policy.merge_factor
• index.merge.policy.max_merge_docs
• index.merge.policy.calibrate_size_by_deletes
• index.merge.policy.min_merge_docs
• index.merge.policy.max_merge_docs

如上面说的&＃xff0c;ES希望采用一种更智能的方式去调整这些参数&＃xff0c;达到一个性能的折中。在5下我们可以配置这些参数&＃xff1a;

• index.merge.policy.expunge_deletes_allowed: 指删除了的文档数在一个segment里占的百分比&＃xff0c;默认是10&＃xff0c;大于这个值时&＃xff0c;在执行expungeDeletes 操作时将会merge这些segments.

• index.merge.policy.floor_segment: 官网的解释我没大看懂&＃xff0c;我的个人理解是ES会避免产生很小size的segment&＃xff0c;小于这个阈值的所有的非常小的segment都会做merge直到达到这个floor 的size&＃xff0c;默认是2MB.
• index.merge.policy.max_merge_at_once: 一次最多只操作多少个segments&＃xff0c;默认是10.
• index.merge.policy.max_merge_at_once_explicit: 显示调用optimize 操作或者 expungeDeletes时可以操作多少个segments&＃xff0c;默认是30.
• index.merge.policy.max_merged_segment: 超过多大size的segment不会再做merge&＃xff0c;默认是5g.
• index.merge.policy.segments_per_tier: 每个tier允许的segement 数&＃xff0c;注意这个数要大于上面的at_once数&＃xff0c;否则这个值会先于最大可操作数到达&＃xff0c;就会立刻做merge&＃xff0c;这样会造成频繁
• index.reclaim_deletes_weight: 考虑merge的segment 时删除文档数量多少的权重&＃xff0c;默认即可.
• index.compund_format: 还不知道干啥用的&＃xff0c;默认即可.

merge 线程调整

Elasticsearch 5 采用了多线程去执行merge&＃xff0c;可以通过修改index.merge.scheduler.max_thread_count 来动态调整这个线程数&＃xff0c;默认的话是通过下面公式去计算&＃xff1a;