Elasticsearch 8.11 中的合并更少，摄取更快

作者：ADRIEN GRAND

Elasticsearch 8.11 改进了管理索引缓存的方式，从而减少了段合并。

我们对 Elasticsearch 8.11 从索引缓存回收内存的方式进行了重大更改，这有助于减少合并开销，从而加快索引速度。 使用我们的日志跟踪，我们观察到，当使用 1GB 堆运行时，这些变化使摄取吞吐量提高了 8%。

它在 Elasticsearch 8.10 及更早版本中的工作原理

当索引数据时，Elasticsearch 开始在内存中构建新的段，并将索引操作写入 transaction log 中以实现持久性。 这些内存中的段最终会序列化到磁盘，或者当需要使更改可见时（Elasticsearch 中称为 “refresh” 的操作），或者当需要回收内存时。 本博客主要关注后者。

为了管理索引缓冲区的内存，Elasticsearch 会跟踪本地节点上所有分片使用了多少 RAM。 每当此内存量超过限制（默认为堆大小的 10%）时，它将识别使用最多内存的分片并刷新 (refresh) 它。

变化1：一次刷新一个段

当给定分片的更改缓冲在内存中时，不存在任何待处理的段。 为了能够并发索引，Lucene 维护了一个待处理段池。 当线程想要索引新文档时，它会从该池中选取一个挂起段，更新它，然后将挂起段移回池中。 如果池中没有空闲的挂起段，则会创建一个新段。 池中通常有许多待处理的段，它们按照峰值索引并发的顺序排列。

我们应用的第一个更改是更新此逻辑，不再一次刷新分片中的所有段，而是使用 Lucene 的 IndexWriter#flushNextBuffer() API 仅刷新最大的待处理段。 这很有帮助，因为挂起段的大小通常不统一，因为 Lucene 倾向于更新最大的挂起段，因此这种新方法有助于刷新更少的段，而这些段也应该明显更大。 由于合并的段较少，因此需要较少的合并来控制段的数量。

变化2：以循环方式刷新分片

跨多个分片管理共享索引缓冲区是一个难题。 现有逻辑假设，选择索引缓冲区使用最多内存的分片作为下一个从中回收内存的分片是很明智的。 毕竟，这是在我们再次达到索引缓冲区的最大内存量之前争取时间的最有效方法。 但另一方面，这也会对摄取最活跃的分片造成惩罚，因为它们会比摄取率适中的分片更频繁地刷新分段。 这里有许多移动部件，这使得很难对这些不同因素如何相互作用有一个良好的直觉，并找出选择下一个要刷新的分片的最佳策略。

因此，我们用各种方法进行了实验来选择下一个要刷新的分片，有趣的是，选择最大的分片是最差的，随机选择分片明显优于选择最大的分片。 实际上，唯一稍微优于随机挑选碎片的方法是以循环方式挑选分片。 这就是 Elasticsearch 现在选择下一个要刷新的分片的方式。

结论

这两项更改应该有助于减少合并开销并加快摄取速度，特别是对于小堆和在索引缓冲区中消耗大量 RAM 的字段类型（如 text 和 match_only_text 字段），或合并成本高昂的字段类型（如密集向量）。 享受加速！