我们如何在 Elasticsearch 8.6、8.7 和 8.8 中加速数据摄入

作者：Adrien Grand, Joe Gallo, Tyler Perkins

正如你们中的一些人已经注意到的，Elasticsearch 8.6、8.7 和 8.8 在各种数据集上带来了良好的索引加速，从简单的关键字到繁重的 KNN 向量，以及摄取管道繁重的摄取工作负载。摄取涉及许多组件 —— 运行摄取管道、反转内存中的数据、刷新段、合并段 —— 所有这些通常都需要不可忽略的时间。对你来说幸运的是，我们在所有这些领域都进行了改进，从而实现了更快的端到端摄取速度。

例如，在我们的基准测试中，8.8 的摄取速度比 8.6 快 13%，该基准模拟了具有多个数据集、摄取管道等的实际日志记录用例。下图显示了在我们实施这些优化期间，摄取率从约 22.5k 文档/秒变为约 25.5k 文档/秒。

本博客深入探讨了一些有助于在 8.6、8.7 和 8.8 中实现摄取加速的更改。

更快地合并 kNN 向量

Elasticsearch 的 kNN 搜索的底层结构是 Lucene 的分层可导航小世界 (HNSW) 图。该图甚至可以在数百万个向量上提供异常快速的 kNN 搜索。然而，构建图表本身可能是一项昂贵的任务；它需要在现有图上执行多次搜索、建立连接并更新当前的邻居集。在 Elasticsearch 8.8 之前，当合并段（segements）时，会创建一个全新的 HNSW 图索引 - 这意味着来自每个段的每个向量都被单独添加到一个完全空的图中。随着段规模的扩大，其数量也会增加，而合并的成本可能会高得令人望而却步。

在 Elasticsearch 8.8 中，Lucene 在合并 HNSW 图方面做出了重大改进。 Lucene 智能地重用现有最大的 HNSW 图。因此，Lucene 不再像以前那样从空图开始，而是利用之前完成的所有工作来构建现有的最大分段。当合并较大的段，这一变化的影响非常显着。在我们自己的基准测试中，我们发现合并所用时间减少了 40% 以上，刷新吞吐量提高了一倍多。这显着减少了索引较大矢量数据集时集群所经历的负载。

优化摄取管道

摄取管道（ingest pipelines）在索引文档之前使用处理器对文档执行转换 - 例如，设置或删除字段、解析日期或 JSON 字符串等值，以及使用 IP 地址或其他数据丰富查找地理位置。通过摄取管道，可以从日志文件发送文本行，并让 Elasticsearch 完成繁重的工作，将该文本转换为结构化文档。我们的大多数开箱即用的集成（integrations）都使用摄取管道，使你能够在几分钟内解析和丰富新的数据源。

在 8.6 和 8.7 中，我们通过多种方式优化了摄取管道和处理器：

我们已经消除了单个文档经过多个管道处理的大部分开销。
我们优化了一些最常用的处理器：
- 使用 mustache 模板的 set 和 append 处理器现在可以更快地创建模板模型和执行 mustache 模板。
- Date 处理器现在缓存其关联的日期解析器。
- Geoip 处理器不再依赖反射（reflection）。
- 在 8.6.0 中，我们通过两种方式优化了无痛脚本，改进了脚本处理器和条件检查。
此外，摄取处理的总体指标和统计数据比以前更准确：
- 正确考虑了管道执行后序列化数据所花费的时间。
- 针对多个管道执行的文档仅计数一次。
最后，低级热代码的优化减少了所有处理文档的开销，例如更快的集合交集、更快的元数据验证和更快的自引用检查。

结合所有这些改进，我们的每日安全集成基准的摄取管道性能提高了 45%，每日日志记录集成基准的摄取管道性能提高了 35%。

我们预计这些加速能够在升级到 8.7 或更新版本后，一些重要的摄入用例将会看到的改进。

关键字和数字字段的优化

我们有许多数据集，其中大多数字段都是简单的数字和关键字字段，它们将自动受益于这些字段类型的改进。两项主要改进有助于索引这些字段类型：

Elasticsearch 在适用时切换到 Lucene 的 IntField、LongField、FloatField 和 DoubleField（Lucene 9.5 中的新增功能）以及 Lucene 的 KeywordField（Lucene 9.6 中的新增功能）。这些字段允许用户在单个 Lucene 字段上启用索引（indexing）和文档值（doc values） - 否则您需要提供两个字段：一个启用索引，另一个启用文档值。事实证明，这一旨在使 Lucene 更加用户友好的更改也有助于提高索引率，超出了我们的预期！请参阅注释 AH 和 AJ 以了解这些更改对 Lucene 夜间基准测试的影响。
简单的关键字现在可以直接索引，而不是通过 TokenStream 抽象。 TokenStreams 通常是分析器的输出，并公开术语、位置、偏移量和有效负载 - 为文本字段构建倒排索引所需的所有信息。为了保持一致性，还使用简单关键字通过生成返回单个标记的 TokenStream 来进行索引。现在，关键字值会直接被索引，而无需经过 TokenStream 抽象。请参阅注释 AH 以了解此更改对 Lucene 的夜间基准测试的影响。

索引排序的优化

索引排序是一项强大的功能，可以通过提前终止查询或将可能与相同查询匹配的文档聚集在一起来加速查询。此外，索引排序是时间序列数据流基础的一部分。因此，我们花了一些时间来解决索引排序的一些索引时间瓶颈。这使得我们的基准摄取加速了 12%，该基准摄取了按 @timestamp 降序排序的简单 HTTP 日志数据集。

基于时间的数据的新合并策略

直到最近，Elasticsearch 一直依赖 Lucene 的默认合并策略：TieredMergePolicy。这是一个非常明智的合并策略，它尝试将段组织成指数大小的层，其中默认情况下每层有 10 个段。它擅长计算廉价的合并、回收删除等。那么为什么要使用不同的合并策略呢？

时序数据的特殊之处在于它通常以近似@timestamp的顺序写入，因此通过后续刷新操作形成的段时间戳范围通常是不会重叠的。对于在@timestamp字段上进行范围查询，这是一个有趣的属性，因为许多段要么根本不与查询范围重叠，要么完全包含在查询范围内，这是处理范围查询非常高效的两种情况。不幸的是，段时间戳范围不重叠的特性会被TieredMergePolicy破坏，因为它更乐意将不相邻的段合并在一起。

所以有@timestamp日期类型字段的分片现在使用Lucene的LogByteSizeMergePolicy，它是TieredMergePolicy的前身. 两者之间的一个关键区别是LogByteSizeMergePolicy只会合并相邻的段，所以在假设数据以 @timestamp 顺序写入的情况下，这可以使得合并后段的@timestamp属性继续保持不会重叠。这个变化使得在EQL 基准测试中一些查询速度加快了多达3倍，这些查询需要按“@timestamp”顺序遍历事件的序列！

但这个属性也有一个缺点，因为LogByteSizeMergePolicy在计算相等大小段的合并方面不如 TieredMergePolicy灵活，这是通过合并限制写入放大的最佳方法。为了减轻这种不利影响，合并因子已从TieredMergePolicy的10提高到 32。虽然增加合并因子通常会使搜索速度变慢，但由于在相同的合并因子下， LogByteSizeMergePolicy比TieredMergePolicy会更积极地合并数据，并且保留段的@timestamp 范围不重叠极大地帮助了时间戳字段的范围查询，通常对于时序数据最常用的就是根据时间戳进行过滤。

这就是对 8.6、8.7 和 8.8写入性能提升的分析。我们会在后续多个小版本中带来更多的加速优化，敬请期待！

想要详细了解每个版本中包含的内容吗？阅读他们各自的发布博客以了解详细信息：