短期职业技能培训班,怎么 给自己的网站做优化呢,钟祥网站开发,哪些网站用jsp作者#xff1a;Adrien Grand, Joe Gallo, Tyler Perkins 正如你们中的一些人已经注意到的#xff0c;Elasticsearch 8.6、8.7 和 8.8 在各种数据集上带来了良好的索引加速#xff0c;从简单的关键字到繁重的 KNN 向量#xff0c;以及摄取管道繁重的摄取工作负载。 摄取涉及…作者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 和 DoubleFieldLucene 9.5 中的新增功能以及 Lucene 的 KeywordFieldLucene 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写入性能提升的分析。我们会在后续多个小版本中带来更多的加速优化敬请期待
想要详细了解每个版本中包含的内容吗 阅读他们各自的发布博客以了解详细信息
8.6 release blog8.7 release blog8.8 release blogElasticsearch 3rd Party Performance Report 原文How we sped up data ingestion in Elasticsearch 8.6, 8.7, and 8.8 | Elastic Blog
