Home
Blog
发布 VDBBench 1.0：开源向量数据库基准测试与您的实际生产工作负载

发布 VDBBench 1.0：开源向量数据库基准测试与您的实际生产工作负载

Announcements

July 04, 2025

Tian Min

大多数向量数据库基准测试都使用静态数据和预建索引。但生产系统并非如此--当用户运行查询时，数据会不断流动，过滤器会分割索引，性能特征会在并发读/写负载下发生显著变化。

今天，我们发布了VDBBench 1.0，这是一款开源基准测试工具，其设计初衷是在实际生产条件下测试向量数据库：流式数据摄取、具有不同选择性的元数据过滤以及揭示实际系统瓶颈的并发工作负载。

下载 VDBBench 1.0 →| 查看排行榜 →VDBBench 1.0

目前的基准测试为何具有误导性

老实说，在我们的行业中有一个奇怪的现象。每个人都在谈论 "不要玩基准"，但许多人却恰恰参与了这种行为。自 2023 年向量数据库市场爆发以来，我们已经看到了无数系统 "基准性能出色"，但在生产中却 "惨遭失败 "的例子，浪费了工程时间，损害了项目信誉。

我们亲眼目睹了这种脱节现象。例如，Elasticsearch 标榜毫秒级的查询速度，但在幕后，仅优化索引就需要 20 多个小时。哪个生产系统能忍受这样的停机时间？

问题源于三个基本缺陷：

过时的数据集：许多基准测试仍依赖于 SIFT（128 维）等传统数据集，而现代嵌入数据集的维度范围为 768-3,072 维。在 128 维与 1024 维以上向量上操作的系统，其性能特征有着本质区别--内存访问模式、索引效率和计算复杂度都发生了巨大变化。
虚荣指标：基准测试关注的是平均延迟或峰值 QPS，这会造成图像失真。平均延迟为 10 毫秒但 P99 延迟为 2 秒的系统会带来糟糕的用户体验。30 秒内测出的峰值吞吐量对持续性能毫无帮助。
过于简化的应用场景：大多数基准测试都是测试基本的 "写入数据、建立索引、查询 "工作流程--基本上是 "Hello World "级别的测试。真正的生产涉及在提供查询的同时持续摄取数据、碎片化索引的复杂元数据过滤以及争夺资源的并发读/写操作。

VDBBench 1.0 有哪些新功能？

VDBBench 不仅对过时的基准测试理念进行了更新，还从最初的原则出发重建了这一概念，并坚持一个指导思想：基准测试只有在预测实际生产行为时才有价值。

我们对 VDBBench 进行了精心设计，以在数据真实性、工作负载模式和性能测量方法这三个关键方面忠实再现真实世界的条件。

让我们来详细了解一下 VDBBench 带来了哪些新功能。

🚀 重新设计的仪表板，具有与生产相关的可视化功能

大多数基准仅关注原始数据输出，但重要的是工程师如何解释这些结果并采取行动。我们重新设计了用户界面，将清晰度和交互性放在首位，使您能够发现系统间的性能差距，并快速做出基础架构决策。

新的仪表板不仅可视化性能数字，还可视化它们之间的关系：QPS 在不同的过滤选择性水平下如何降低，召回率在流媒体摄取过程中如何波动，以及延迟分布如何揭示系统稳定性特征。

我们使用最新配置和推荐设置重新测试了主要的向量数据库平台，包括Milvus、Zilliz Cloud、Elastic Cloud、Qdrant Cloud、Pinecone 和 OpenSearch，确保所有基准数据都能反映当前的能力。所有测试结果均可在 VDBBench Leaderboard 上查看。

🏷️ 标签过滤：隐藏的性能杀手

现实世界中的查询很少是孤立进行的。应用程序将向量相似性与元数据过滤相结合（"查找与这张照片相似但价格低于 100 美元的鞋子"）。这种过滤向量搜索带来了独特的挑战，而大多数基准却完全忽略了这一点。

过滤搜索在两个关键领域引入了复杂性：

过滤复杂性：更多的标量字段和复杂的逻辑条件增加了计算需求，并可能导致召回率不足和图索引碎片化。
过滤选择性：这是我们在生产中反复验证的 "隐藏性能杀手"。当过滤条件具有高度选择性（过滤掉 99% 以上的数据）时，查询速度可能会出现数量级的波动，并且由于索引结构在稀疏结果集上的挣扎，召回率可能会变得不稳定。

VDBBench 系统地测试了各种过滤选择性水平（从 50% 到 99.9%），提供了这种关键生产模式下的综合性能概况。测试结果往往会揭示出传统基准测试中从未出现过的性能悬崖。

例如在 Cohere 1M 测试中，Milvus 在所有过滤选择性级别中都保持了持续的高召回率，而 OpenSearch 则表现出不稳定的性能，召回率在不同的过滤条件下大幅波动--在许多情况下召回率低于 0.8，这对于大多数生产环境来说是不可接受的。

图Milvus 和 OpenSearch 在不同过滤选择性水平下的 QPS 和召回率（Cohere 1M 测试）。

流读写：超越静态索引测试

生产系统很少有静态数据。在执行搜索时，新信息会不断涌入--在这种情况下，许多原本令人印象深刻的数据库会在保持搜索性能和处理连续写入的双重压力下崩溃。

VDBBench 的流场景模拟了真实的并行操作，帮助开发人员了解高并发环境下的系统稳定性，特别是数据写入对查询性能的影响，以及随着数据量的增加性能是如何变化的。

为确保在不同系统间进行公平比较，VDBBench 采用了结构化方法：

配置受控写入率，以反映目标生产工作负载（例如，500 行/秒分布在 5 个并行进程中）
每摄取 10%的数据后触发搜索操作，在串行和并行模式之间交替进行
记录综合指标：延迟分布（包括 P99）、持续 QPS 和调用准确性
随着数据量和系统压力的增加，跟踪性能随时间的变化情况

这种受控的增量负载测试可揭示系统在不断摄取数据的情况下如何保持稳定性和准确性，而传统的基准很少能捕捉到这一点。

举例说明：在 Cohere 10M 流测试中，与 Elasticsearch 相比，Pinecone 在整个写入周期中保持了更高的 QPS 和召回率。值得注意的是，Pinecone 的性能在摄取完成后显著提高，显示出在持续负载下的强大稳定性，而 Elasticsearch 在主动摄取阶段则表现得更加不稳定。

图：Pinecone 的 QPS 和 RecallPinecone 与 Elasticsearch 在 Cohere 10M 流测试中的 QPS 和召回率对比（500 行/秒摄取率）。

VDBBench 更进一步，支持可选的优化步骤，允许用户比较索引优化前后的流搜索性能。它还能跟踪并报告每个阶段所花费的实际时间，从而更深入地了解系统在类似生产条件下的效率和行为。

图优化后 Pinecone 与 Elasticsearch 在 Cohere 10M 流测试中的 QPS 和召回率对比（500 行/秒摄取率）

如我们的测试所示，Elasticsearch 在索引优化后的 QPS 方面超过了 Pinecone。但是，当 x 轴反映实际耗时时，Elasticsearch 显然需要更长的时间才能达到这一性能。在生产中，这种延迟非常重要。这种比较揭示了一个关键的权衡：峰值吞吐量与服务时间。

反映当前人工智能工作负载的现代数据集

我们彻底改造了用于向量数据库基准测试的数据集。VDBBench 不再使用 SIFT 和 GloVe 等传统测试集，而是使用 OpenAI 和 Cohere 等最先进的嵌入模型生成的向量，这些模型为当今的人工智能应用提供了动力。

为了确保相关性，特别是对于检索增强生成（RAG）等用例，我们选择了反映真实世界企业和特定领域场景的语料库：


语料库	嵌入模型	尺寸	大小	使用案例
维基百科	Cohere V2	768	1M / 10M	通用知识库
BioASQ	Cohere V3	1024	1M / 10M	特定领域（生物医学）
C4	OpenAI	1536	500K / 5M	网络规模文本处理
MSMarco V2	udever-bloom-1b1	1536	1m / 10m / 138m	大规模搜索

这些数据集更好地模拟了当今的大容量、高维向量数据，可在与现代人工智能工作负载相匹配的条件下，对存储效率、查询性能和检索准确性进行实际测试。

⚙️ 针对特定行业测试的自定义数据集支持

每个企业都是独一无二的。金融行业可能需要侧重于交易嵌入的测试，而社交平台则更关心用户行为向量。VDBBench 可让您使用自己的数据进行基准测试，这些数据由您的特定嵌入模型生成，适用于您的特定工作负载。

您可以自定义

向量维度和数据类型
元数据 Schema 和过滤模式
数据量和摄取模式
与生产流量相匹配的查询分布

毕竟，没有数据集比您自己的生产数据更能说明问题。

VDBBench 如何衡量生产中的实际重要因素

以生产为重点的指标设计

VDBBench 优先考虑反映实际性能的指标，而不仅仅是实验室结果。我们围绕生产环境中的实际问题重新设计了基准：负载下的可靠性、尾部延迟特性、持续吞吐量和精度保持。

针对真实用户体验的 P95/P99 延迟：平均/中位延迟掩盖了令真实用户沮丧的异常值，并可能表明潜在的系统不稳定性。VDBBench 专注于 P95/P99 等尾部延迟，揭示 95% 或 99% 的查询实际将达到的性能。这对于 SLA 规划和了解最坏情况下的用户体验至关重要。
负载下的可持续吞吐量：在生产中，5 秒钟内性能良好的系统并不能满足要求。VDBBench 会逐渐增加并发量，以找出数据库每秒的最大可持续查询次数 (max_qps)，而不是短时间理想条件下的峰值。这种方法揭示了系统在一段时间内的支持能力，有助于进行切合实际的容量规划。
调用与性能的平衡：没有准确性的速度是毫无意义的。VDBBench 中的每一个性能数字都与召回率测量值配对，因此您可以清楚地知道，为了获得吞吐量，您需要牺牲多少相关性。这样就能在内部权衡大相径庭的系统之间进行公平、公正的比较。

反映现实的测试方法

VDBBench 设计中的一项关键创新是将串行测试和并发测试分离开来，这有助于捕捉系统在不同类型负载下的表现，并揭示不同用例的重要性能特征。

延迟测量分离：

serial_latency_p99 测量最小负载下的系统性能，即一次只处理一个请求。这代表了延迟的最佳情况，有助于确定基线系统能力。
conc_latency_p99 高并发：捕捉现实高并发条件下的系统行为，即多个请求同时到达并争夺系统资源。

两阶段基准结构：

串行测试：单进程运行 1,000 次查询，确定基准性能和准确性，报告serial_latency_p99 和召回率。该阶段有助于确定理论性能上限。
并发测试：模拟在持续负载下的生产环境，其中包含几项关键创新：
- 真实的客户端模拟：每个测试进程都使用自己的连接和查询集独立操作，避免了共享状态干扰而导致结果失真
- 同步启动：所有进程同时启动，确保测得的 QPS 准确反映声称的并发水平
- 独立查询集：防止出现无法反映生产查询多样性的不切实际的缓存命中率