@Elasticsearch之深度应用及原理剖析--索引文档存储段合并机制

---

title: ElasticSearch之深度应用及原理剖析
author: Xoni
tags:

• 搜索引擎
• Elasticsearch
  categories:
• 搜索引擎
• Elasticsearch
  abbrlink: 5a1f6e0b

---

第2节 索引文档存储段合并机制（segment merge、policy、optimize）

2.1 段合并机制(重点)

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 CPU 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。 被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
启动段合并在进行索引和搜索时会自动进行。这个流程像在 图 25 中提到的一样工作：
1、 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。
2、 合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。

图 25. 两个提交了的段和一个未提交的段正在被合并到一个更大的段

3、合并完成时的活动：

• 新的段被刷新（flush）到了磁盘。 写入一个包含新段且排除旧的和较小的段的新提交点。
• 新的段被打开用来搜索。
• 老的段被删除。

图 26. 一旦合并结束，老的段被删除

合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。默认情况下，归并线程的限速配置 indices.store.throttle.max_bytes_per_sec 是 20MB。对于写入量较大，磁盘转速较高，甚至使用 SSD 盘的服务器来说，这个限速是明显过低的。对于 ELK Stack 应用，建议可以适当调大到100MB或者更高。

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

用于控制归并线程的数目，推荐设置为cpu核心数的一半。 如果觉得自己磁盘性能跟不上，可以降低配置，免得IO情况瓶颈。
index.merge.scheduler.max_thread_count

2.2 归并策略 policy

归并线程是按照一定的运行策略来挑选 segment 进行归并的。主要有以下几条：

• index.merge.policy.floor_segment 默认 2MB，小于这个大小的 segment，优先被归并。
• index.merge.policy.max_merge_at_once 默认一次最多归并 10 个
• segment index.merge.policy.max_merge_at_once_explicit默认 optimize 时一次最多归并 30 个 segment。
• index.merge.policy.max_merged_segment 默认 5 GB，大于这个大小的 segment，不用参与归 并。optimize 除外。

optimize API
optimize API 大可看做是强制合并 API。它会将一个分片强制合并到 max_num_segments 参数指定大小的段数目。 这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。
在特定情况下，使用 optimize API 颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。 老的索引实质上是只读的；它们也并不太可能会发生变化。在这种情况下，使用optimize 优化老的索引，将每一个分片合并为一个单独的段就很有用了；这样既可以节省资源，也可以使搜索更加快速：
POST /logstash-2014-10/_optimize?max_num_segments=1

forceMergeRequest.maxNumSegments(1)