作者：来自 Elastic Benjamin Trent, Mayya Sharipova, Chenhui Wang 及 Libby Lin

了解我们如何通过更快的 float / half_float 排序和 integer 排序的延迟优化来加快 Elasticsearch 排序速度。

Elasticsearch 引入了大量新功能，帮助你为你的使用场景构建最佳搜索解决方案。深入了解我们的示例笔记本，开始免费云试用，或立即在本地机器上尝试 Elastic。

---

Elasticsearch 在字段类型排序速度方面持续优化，9.0.1 版本已加速了 float / half_float 排序。此外，即将发布的 Elasticsearch 9.1 也将带来 integer 排序的显著延迟提升。

这些新的排序优化不仅已应用于 Elastic Cloud Serverless，也将回溯至 Elasticsearch 8.19，让尚未升级到 Elasticsearch 9.x 的用户也能享受排序性能提升。

通过两个不同的基准测试，我们观察到延迟显著改善：

• NYC Taxis 的 float 和 half_float 排序：提升 83 倍到 920 倍

• Http_logs 的 integer 排序：提升 41 倍到 531 倍

在这里查看我们对 http_logs 的 nightly 基准测试结果（注意：2025 年 5 月新增了排序延迟指标）。

背景

在 2020 年，我们在 Elasticsearch 7.6 中对 long 和 date 字段类型的排序进行了重大优化。例如，按最新时间戳排序检索日志的速度大幅提升。随后在 7.16 版本中，我们引入了 search_after 参数，支持了常见的分页场景。

这一次，我们将同样的优化应用到 integer、short 和 byte 字段类型，以及 float 和 half_float 字段类型。

根据你的数据及其在各个 segment 之间的分布情况，你可能会看到对 integer、short、byte、float 和 half_float 数据类型进行排序查询的速度提升从几倍到数百倍不等。

我们是怎么做到的？

我们没有依赖 index sorting，而是采用了一种新方法：将 BKD（Block k-dimensional）树与 distance 查询结合使用。BKD 树的叶子块具有便于跳过的特性，因为每个块的字段最小值和最大值是可比较的。

结合使用 distance_feature 查询，我们可以在比较过程中快速判断哪些块不具备竞争性，从而跳过这些无效的数据区域，大大节省处理时间。

至于是从全局最小值还是最大值计算距离，取决于排序是升序还是降序。

这也意味着字段必须已建立索引，且不能为 null。

更详细的内容可以参考我们之前关于排序查询优化的博客。

下面是结果……

结果

NYC Taxis 基准测试

在 NYC Taxis 基准测试中（添加了 half_float 类型），性能提升范围为 83 倍到 920 倍（通过旧的 P90 延迟除以新的 P90 延迟计算得出）：

从对数尺度的图像上可以直观看到显著的提升：

Http_logs 基准测试

我们使用了开源工具 Rally 中的 http_logs track，采用了此处提供的默认设置。

在 integer 排序优化中，http_logs 基准测试的八种不同使用场景下，性能提升在 41 倍到 531 倍之间（同样通过旧的 P90 延迟除以新的 P90 延迟计算得出）。

同样，即使在对数尺度下，我们也能看到明显的性能提升对比：

根据我们的 nightly 基准测试，integer 排序的性能提升非常显著，结果如下复现：

许多用例都受益于这一性能提升，包括 Observability、Security 和 Search 中的分析仪表盘。更低的延迟也带来了更高效的计算和更低的基础设施成本。

展望 Elasticsearch 9.1

Elastic 9.1 还将包含其他令人兴奋的改进，包括但不限于：

• ES|QL 全文搜索（MATCH、QSTR、评分）正式版

• 线性检索器（推进混合搜索）

• HNSW 的 ACORN-1 性能提升

• 提前终止如何加速近似 KNN 搜索

我们致力于持续创新，帮助你构建最快的搜索应用。

原文：Elasticsearch sorting just got up to 900x faster - Elasticsearch Labs