Elasticsearch DiskBBQ 在网络附加存储上的向量搜索性能比 Qdrant 快 7 倍

作者：来自 Elastic Sachin Frayne

Elasticsearch DiskBBQ 在网络附加存储环境下，以相当的召回率实现了最高达 Qdrant 7 倍的向量搜索吞吐量。了解基准测试方法以及完整测试结果。

试用这个用于Search AI的自定进度动手学习来自己体验向量搜索。你可以启动一个免费云试用，或者立即在你的本地机器上尝试 Elastic。

Elasticsearch DiskBBQ 在可比 recall 下，相比 Qdrant 提供最高达 7x 更高的 throughput，并在网络附加的持久化存储上进行了测试，这是大多数托管云部署实际使用的拓扑结构。该差距在 recall 从 0.93 到 0.97 的各个水平之间保持一致，并且随着 recall 增加而扩大。DiskBBQ 在 search breadth 增长时保持 latency 几乎平稳；Qdrant 的 latency 随着 hnsw_ef 增加而显著上升，这是由于在重评分期间从磁盘读取原始向量的随机读驱动的。如果你在 Kubernetes 或托管云环境中运行 vector search，这就是这种权衡的表现。

向量检索 是 Large Language Model (LLM) 应用、Retrieval Augmented Generation (RAG) 以及其他 AI 工作负载的关键基础。在该 benchmark 中，Elasticsearch 在相同存储拓扑上，在可比 recall 下，相比 Qdrant 实现最高 7x 更高吞吐量。Elasticsearch 作为 vector database 提供强大的向量检索性能，即使 在网络附加持久化存储仍然处于 query 路径上。

这种差异反映了两个系统与磁盘交互方式的不同。Elasticsearch DiskBBQ 的设计目标是在 persistent storage 仍然位于 query 路径时保持向量检索的高效性，它使用紧凑的量化表示，并在 search 过程中限制对 full precision 向量的昂贵访问。在这种配置下，Qdrant 依赖基于 graph 的 search 路径，并在磁盘上存储的原始向量上进行 rescoring。在 network-attached persistent storage 上，这种 random access 成本会显著增加，因此随着 recall 提升，性能差距进一步扩大。因此该 benchmark 专门聚焦于 network-attached persistent storage，这是一种在 managed cloud 和 Kubernetes 环境中非常常见的部署模型。

延迟曲线的关键模式不仅在于差距的大小，还在于其形状。随着 recall 提升，Elasticsearch 的 latency 保持相对平稳，这表明更高的 recall 并不需要显著增加昂贵的存储访问操作。Qdrant 的 latency 随着 hnsw_ef 增加而急剧上升，这与更宽的候选集探索导致在磁盘上的原始向量进行更多 rescoring 工作是一致的。

完整结果表

下表展示了 Elasticsearch 和 Qdrant 的完整参数扫描结果。由于两个引擎在向量检索中提供了不同的调优控制，因此结果使用各自引擎的完整 parameter key 进行展示，而不是尝试在不同设置之间建立一一对应的映射。

关于指标的说明：

• ParamKey：该次运行所使用的完整参数设置。

• Recall：基于该 benchmark 查询集的 ground-truth top-100 结果计算得到的 Recall@100。取值范围为 0 到 1，越高越好。

• Latency_Avg：从 benchmarking client 测得的端到端平均每查询延迟，单位为毫秒。越低越好。

• Latency_P95：第 95 百分位查询延迟，单位为毫秒，用于表示典型慢查询的上界。越低越好。

• Throughput：在整个运行过程中平均每秒处理的查询数。越高越好。

每一行将 Elasticsearch 和 Qdrant 在该 recall 水平上最接近的配置进行配对展示。

在相近 recall 下的匹配对比

为了保证对比的公平性，仅在达到相近 recall 的配置之间计算速度提升（speedup）。这样可以避免将准确率差异较大的设置放在一起比较，从而导致不合理的性能结论。

这个“matched-recall”视图最清楚地表达了底层系统之间的差异。在相近 recall 水平下，Elasticsearch 同时提供更低的 latency 和更高的 throughput，并且随着 recall 上升，这种差距进一步扩大。recall-throughput 模式之所以重要，是因为在该 benchmark 中，提高 recall 需要更广泛的 search。DiskBBQ 在这种扩展下只带来相对较小的额外成本，而 Qdrant 的 graph 加 rescoring 路径则更容易受到 persistent storage 上对原始向量随机访问的限制。

Benchmark 方法论

用于这些测试的 benchmarking 工具 Jingra 最初是用 Python 编写的，后来重写为 Java 项目。在本次测试中，Jingra 运行在与被测 engine 相同 cluster 内的 Kubernetes pod 中。这有助于减少外部 network 波动，并保持不同运行之间测试环境的一致性。每次运行中，Jingra 以固定的 client concurrency 执行 query set，记录端到端 client-side latency 和 throughput，并基于预先计算好的 ground-truth top-100 集合计算 recall。

该 benchmark 有意选择 network-attached persistent storage，而不是 local NVMe。在已发布的结果中，storage 使用的是 GCP Hyperdisk Balanced 200 GiB volume 的基础性能配置，没有显式 provisioning IOPS 或 throughput。我们之所以选择这种 topology，是因为它代表了一种真实的 cloud deployment 模型，同时也让 storage efficiency 在 query path 上变得更加可见。

Qdrant 在 local NVMe 上通常表现更好，因此使用 local NVMe 的部署结果可能与本文展示的结果不同。本 benchmark 专门测试 network-attached persistent storage，因为这是常见的 managed-cloud 部署模型，也因为它能更清晰地暴露 storage path 在 end-to-end query performance 中的影响。

由于 Elasticsearch 和 Qdrant 在 vector search 调优上暴露的 query parameter 不同，两者之间不存在严格的一一映射关系。因此我们不直接比较“等价参数”，而是以 recall 作为主要对齐点。下面的 matched comparisons 将基于相近 recall 进行配对，而不是基于表面相似的 parameter value。

由于单个 parameter setting 的 recall 无法预先得知，我们为每个 engine 扫描多个 search configuration，然后在相近 recall level 上进行对比。在发布结果中，oversampling 在两个引擎中都固定为 1，从而确保 recall 主要由 search breadth 而不是 rescoring expansion 来调节。

Elasticsearch 如何配置向量检索？

{ "query": { "knn": { "field": "embedding", "query_vector": "{{query_vector}}", "k": "{{k}}", "visit_percentage": "{{visit_percentage}}", "rescore_vector": { "oversample": "{{oversample}}" } } }, "size": "{{size}}", "_source": false }

• query_vector：用于相似度检索的输入向量。Elasticsearch 会将该向量与字段中存储的向量进行比较。

• k：要检索的最近邻数量。

• visit_percentage：控制 DiskBBQ（Elasticsearch 的磁盘优化 vector index）在近似搜索阶段被探索的比例。该值越高通常 recall 越高，但 latency 也会增加。

• oversample：控制进入 rescoring 阶段的候选向量数量，相对于 k 的额外扩展倍数。该值越高通常可以提升 recall，但会带来额外成本。

• size：最终返回结果的数量。

• _source: false：关闭返回 document 的_source字段，以减少响应大小，并避免在 benchmarking 过程中产生额外检索开销。

示例

{ "query": { "knn": { "field": "embedding", "query_vector": [ -0.0095683, 0.0072035934, ... ], "k": "100", "visit_percentage": "3", "rescore_vector": { "oversample": "1" } } }, "size": "100", "_source": false }

参数：

recall@100: - { size: 100, k: 100, visit_percentage: 1, oversample: 1 } - { size: 100, k: 100, visit_percentage: 1.5, oversample: 1 } - { size: 100, k: 100, visit_percentage: 2, oversample: 1 } - { size: 100, k: 100, visit_percentage: 2.5, oversample: 1 } - { size: 100, k: 100, visit_percentage: 3, oversample: 1 } - { size: 100, k: 100, visit_percentage: 3.5, oversample: 1 } - { size: 100, k: 100, visit_percentage: 4, oversample: 1 } - { size: 100, k: 100, visit_percentage: 4.5, oversample: 1 } - { size: 100, k: 100, visit_percentage: 5, oversample: 1 } - { size: 100, k: 100, visit_percentage: 5.5, oversample: 1 }

我们保持k = size = 100，使 search request 与 benchmark 目标对齐：返回 top 100 结果。为了提升 recall，我们调整visit_percentage，而不是通过增加最终返回结果数量来实现，同时在所有运行中保持oversample = 1不变。

Qdrant 如何配置 vector search？

{ "vector": "{{query_vector}}", "limit": "{{size}}", "with_payload": false, "with_vector": false, "params": { "hnsw_ef": "{{hnsw_ef}}", "quantization": { "rescore": true, "oversampling": "{{oversampling}}" } } }

• query_vector / vector：用于相似度检索的输入向量。Qdrant 会将该向量与 collection 中存储的向量进行比较。

• size / limit：返回的最近邻结果数量。

• with_payload: false：关闭返回 payload 字段，以减少响应大小，并避免在 benchmarking 中产生额外检索开销。

• with_vector: false：关闭返回存储向量本身，从而减少响应体大小，并使 benchmark 更聚焦于搜索性能。

• hnsw_ef：控制 HNSW search 中探索的候选数量。该值越高通常 recall 越高，但 latency 也会增加。它与 Elasticsearch 的 visit_percentage 类似，都影响 search breadth，但两者是 engine-specific 的参数，不能直接等价。

• quantization.rescore: true：在 quantized search 之后，使用原始向量对 candidate set 进行 rescoring。

• oversampling：控制在 rescoring 阶段相对于最终结果数量额外考虑的候选数量。该值越高通常可以提升 recall，但会带来额外成本。

示例

{ "vector": [ -0.0095683, 0.0072035934, ... ], "limit": "100", "with_payload": false, "with_vector": false, "params": { "hnsw_ef": "150", "quantization": { "rescore": true, "oversampling": "1" } } }

参数：

recall@100: - { size: 100, hnsw_ef: 50, oversampling: 1 } - { size: 100, hnsw_ef: 100, oversampling: 1 } - { size: 100, hnsw_ef: 150, oversampling: 1 } - { size: 100, hnsw_ef: 200, oversampling: 1 } - { size: 100, hnsw_ef: 256, oversampling: 1 }

我们保持size = 100，以确保每个 request 与 evaluation 目标对齐（在本例中为 top 100 retrieval）。Recall 通过扫描hnsw_ef进行调优，该参数控制 search 过程中探索的候选数量。更高的hnsw_ef通常可以提升 recall，但也会增加 latency 并降低 throughput。我们在所有运行中保持oversampling = 1不变，从而让主要调优变量集中在 search breadth，而不是 rescoring 扩展。

Cluster setup 和 DiskBBQ 配置

我们在 GCP 上运行该 benchmark，使用三个 n4-standard-8 节点，每个 pod 分配 7 vCPUs 和 26 GB RAM，并使用 200 GiB 的 GCP Hyperdisk Balanced volume（基础性能配置）。corpus 包含 2100 万 vectors（更多细节和下载链接见 dataset 部分），对应约 60.1 GiB 原始 float vector 数据。在 2-bit 量化下，vector payload 下降到约 3.8 到 4.0 GB。然而，当加入 graph 和其他 index 结构后，完整 index footprint 远大于此。因此该 workload 仍然对 network-attached storage 性能非常敏感，尤其是在 rescoring 阶段仍需要从磁盘读取精确 vector 值的情况下。

我们有意选择该 node size，使 benchmark 处于这样一种状态：network-attached persistent storage 仍然处于 query path，而不是让整个 working set 完全驻留在 memory 中。每个系统因此都在该 workload 的 tuning scope 内使用我们识别出的最佳配置。在 Elasticsearch 中，这意味着使用bbq_disk。在 Qdrant 中，原始 vectors 存储在 disk 上，而用于 approximate search 的 2-bit quantized representation 则通过always_ram: true保存在 RAM 中。由于两个系统在 search strategy 和 tuning control 上不同，我们使用 matched recall 进行比较，而不是尝试一一映射参数。

Elasticsearch 使用 DiskBBQ 作为 disk-optimized 的 approximate nearest neighbor vector search 方法，并采用 2-bit quantization。DiskBBQ 通过激进的 quantization 来保持 index 紧凑，同时使用 original vectors 进行 rescoring 以保证 accuracy。这有助于在维持较高 recall 的同时保持 disk-based search 的效率。

bbq_disk是 Elasticsearch Enterprise feature。我们在此使用它，是因为本 benchmark 的目标是比较在该 workload 下，每个 engine 中最强的 disk-oriented vector search configuration，而不是比较 licensing tiers 或默认功能。

我们没有将bbq_hnsw纳入对比，因为该 benchmark 专门设计用于评估 disk-oriented vector search 在 disk-sensitive workload 下的表现。

这个 storage topology 之所以重要，是因为 Qdrant 的 rescore step 会在每次 query 中从 disk 以 random access 方式读取原始 float32 vectors。在 local NVMe 上，这些读取速度更快，因此 Qdrant 表现更好。但在 network-attached persistent storage 上，这种 random-read rescore path 会成为更明显的 bottleneck。随着hnsw_ef增加，Qdrant latency 急剧上升，而 Elasticsearch 在相同 recall 增长路径上保持相对平稳。

我们选择 2-bit quantization 是因为 Qdrant 在 1-bit binary quantization 下无法达到目标 recall 范围。由于两个系统暴露的 disk-oriented vector search strategy 不同，我们在各自 feature set 范围内选择了最强配置进行调优。

两个系统都配置为三个 shard 分布在三个节点上，并在 cluster 中保留两份数据副本。在 Elasticsearch 中，number_of_shards: 3和number_of_replicas: 1表示一个 primary + 一个 replica，共两份数据副本。在 Qdrant 中，shard_number: 3和replication_factor: 2同样表示两份数据副本，因为 Qdrant 的 replication factor 指的是总副本数，而不是额外副本数。因此尽管字段名称不同，两者的 effective replication level 是一致的。

Elasticsearch mapping

{ "mappings": { "properties": { "embedding": { "type": "dense_vector", "element_type": "float", "dims": 768, "index": true, "similarity": "cosine", "index_options": { "type": "bbq_disk", "bits": 2 } } } }, "settings": { "number_of_shards": "3", "number_of_replicas": "1" } }

Qdrant mapping：

{ "vectors": { "size": 768, "distance": "Cosine", "on_disk": true }, "shard_number": 3, "replication_factor": 2, "hnsw_config": { "m": 16, "ef_construct": 256 }, "quantization_config": { "turbo": { "bits": "bits2", "always_ram": true } } }

数据集

本 benchmark 使用 Hugging Face 上的 kenhktsui/wiki_dpr_e5 数据集，这是一个大规模 Wikipedia passage 检索数据集，专为 dense vector search 设计。该 corpus 包含 2100 万条嵌入 passage，每条由 768 维 float32 vector 表示，每个向量 3072 bytes。这对应约 60.1 GiB 的原始 vector 数据，在不包含额外字段和源数据文件格式开销之前。由于这些原因，可下载的data.parquet文件更大，达到 85.2 GB。

我们选择该数据集，是因为它反映了 LLM、RAG 和 retrieval 系统中的常见 production pattern：在语义 embedding 的大规模语料库中进行搜索，同时在 recall、latency 和 throughput 之间进行权衡。该数据集规模达到 2100 万 vectors、约 60 GiB 原始 vector 数据，足以使 disk-based vector search 成为一个值得评估的运行模式。

两个引擎都使用 2-bit quantization，将每个 vector 从 3072 bytes 压缩到 192 bytes，实现 16x 压缩，使 quantized vector corpus 约为 4 GB。在 Qdrant 中，该 quantized representation 被保存在 RAM 中用于 search，而 original vectors 仍然存储在 disk 上。即便如此，该 workload 仍然对 network-attached storage performance 保持显著敏感，因为 rescoring 仍需要访问 disk 上的 original vectors。

你可以从以下链接下载数据集和 query 文件：

• data.parquet

• queries.parquet

Jingra 与 benchmark 复现

本 benchmark 使用 Jingra v0.2.3，并采用 es-9.4-vs-qd-1.18-vector-search 中描述的配置。Jingra 负责数据加载、query 执行、参数 sweep 以及 Elasticsearch 和 Qdrant 的指标收集，使 benchmark 可重复且更易对比。

要复现该实验，需要公开的数据集、query set、engine 配置以及可比的 cluster hardware。在这些条件满足的情况下，Jingra 可以重新运行 benchmark，并生成与本文相近的 recall、latency 和 throughput 结果。

结论

在相近 recall 水平下，Elasticsearch DiskBBQ 在本 benchmark 中持续优于 Qdrant，表现为更高 throughput 和更低 latency，覆盖我们测试的整个 recall 范围。尤其值得注意的是，这一对比是在 network-attached persistent storage 上进行的，在这种环境下 storage-aware vector search 的效率至关重要。作为 vector database，Elasticsearch 使组织能够在较慢的 persistent storage 上实现高 recall，同时保持更低 latency 和更高 throughput。

同样重要的是，该 benchmark 强调了按 matched recall 而不是 nominal parameter settings 进行对比的价值。由于 Elasticsearch 和 Qdrant 暴露的 control 不同，最公平的比较不是 parameter-to-parameter，而是 outcome-to-outcome。在整个 recall 区间内，Elasticsearch 在 latency 和 throughput 上都保持明显优势。

如果你想自己复现该实验，我们已经公开发布了所使用的数据集和 query set，以便他人验证结果并在此基础上扩展。

进一步阅读：

• 介绍一种新的向量存储格式：DiskBBQ

• Elasticsearch BBQ vs TurboQuant

原文：Elasticsearch BBQ: optimized scalar quantization vs. TurboQuant - Elasticsearch Labs