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 字段),或合并成本高昂的字段类型(如密集向量)。 享受加速!

相关推荐
Elastic 中国社区官方博客4 小时前
使用 Elastic AI Assistant for Search 和 Azure OpenAI 实现从 0 到 60 的转变
大数据·人工智能·elasticsearch·microsoft·搜索引擎·ai·azure
Francek Chen6 小时前
【大数据技术基础 | 实验十二】Hive实验:Hive分区
大数据·数据仓库·hive·hadoop·分布式
Natural_yz9 小时前
大数据学习17之Spark-Core
大数据·学习·spark
Karoku06610 小时前
【企业级分布式系统】ELK优化
运维·服务器·数据库·elk·elasticsearch
莫叫石榴姐10 小时前
数据科学与SQL:组距分组分析 | 区间分布问题
大数据·人工智能·sql·深度学习·算法·机器学习·数据挖掘
魔珐科技11 小时前
以3D数字人AI产品赋能教育培训人才发展,魔珐科技亮相AI+教育创新与人才发展大会
大数据·人工智能
上优12 小时前
uniapp 选择 省市区 省市 以及 回显
大数据·elasticsearch·uni-app
samLi062013 小时前
【更新】中国省级产业集聚测算数据及协调集聚指数数据(2000-2022年)
大数据
Mephisto.java13 小时前
【大数据学习 | Spark-Core】Spark提交及运行流程
大数据·学习·spark
EasyCVR14 小时前
私有化部署视频平台EasyCVR宇视设备视频平台如何构建视频联网平台及升级视频转码业务?
大数据·网络·音视频·h.265