网络信息工程师,衡阳seo外包,wordpress博客文章怎么设置,网页设计的网站推荐作者#xff1a;ADRIEN GRAND
Elasticsearch 8.11 改进了管理索引缓存的方式#xff0c;从而减少了段合并。 我们对 Elasticsearch 8.11 从索引缓存回收内存的方式进行了重大更改#xff0c;这有助于减少合并开销#xff0c;从而加快索引速度。 使用我们的日志跟踪#x…作者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 字段或合并成本高昂的字段类型如密集向量。 享受加速
