作者：来自 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、评分）GA
- 线性检索器 （Advancing Hybrid Search）
- HNSW 的 ACORN-1 性能改进
- 提前终止如何加快 Approximate KNN 搜索速度
我们致力于持续创新，以便您可以构建最快的搜索应用程序。
原文：Elasticsearch sorting just got up to 900x faster - Elasticsearch Labs
