在 Qdrant，性能是首要任务。我们始终确保高效利用系统资源，以便您以**最优惠的云成本获得最快、最准确的结果**。因此，从选择 Rust、I/O 优化、无服务器支持、二值量化，到我们的fastembed 库，我们所有的决定都基于我们的原则。在本文中，我们将比较 Qdrant 与其他向量搜索引擎的性能表现。
以下是我们设计这些基准测试时遵循的原则
我们的一些实验设计决定在常见问题解答部分中有所描述。如果您想讨论任何与 Qdrant 或这些基准测试相关的问题，请在我们的Discord 频道上联系我们。
我们使用不同数据集上的各种配置，对多个向量数据库进行了基准测试，以查看结果可能如何变化。这些数据集可能具有不同的向量维度，并且使用的距离函数也不同。我们还尝试捕捉在使用一些不同的配置参数时可能出现的差异，包括引擎本身和搜索操作的参数。
更新日期：2024年1月/6月
自我们上次运行以来，大多数引擎都有所改进。生活和软件都有权衡，但有些引擎表现明显更优
Qdrant 在几乎所有场景中都实现了最高的 RPS 和最低的延迟。**它在其中一个数据集上还显示出 4 倍的 RPS 提升。Elasticsearch 变得相当快，但在索引时间方面非常慢。存储 1000 万以上 96 维向量时，它可能慢 10 倍！（32 分钟 对比 5.5 小时）Milvus 在索引时间方面最快，并保持了良好的精度。然而，当向量维度更高或向量数量更多时，在 RPS 或延迟方面，它与其它引擎相比稍逊一筹。Redis 能够实现良好的 RPS，但主要是在较低精度下。它在单线程下也实现了低延迟，但随着并行请求的增加，其延迟迅速上升。这种速度提升部分来自于其自定义协议。Weaviate 的改进最小。在我们的基准测试中，我们测试了实践中出现的两种主要搜索使用场景。
我们的基准测试工具受到了github.com/erikbern/ann-benchmarks 的启发。我们使用以下数据集来测试引擎在 ANN 搜索任务上的性能
| 数据集 | 向量数 | 维度 | 距离函数 |
|---|---|---|---|
| dbpedia-openai-1M-angular | 100万 | 1536 | 余弦 |
| deep-image-96-angular | 1000万 | 96 | 余弦 |
| gist-960-euclidean | 100万 | 960 | 欧氏距离 |
| glove-100-angular | 120万 | 100 | 余弦 |
基准测试配置
Standard D8ls v5）Standard D8s v3）dbpedia-openai-1M-1536-angular 数据集，也很少需要 100万 * 1536 * 4 字节 * 1.5 = 8.6GB 的内存（包括向量 + 索引）。因此，我们决定为所有引擎提供大约 3 倍于需求的内存。请注意，由于 25GB 内存限制，某些引擎的某些配置在某些数据集上崩溃了。这就是为什么在选择更高的精度阈值时，您可能会看到某些引擎的数据点较少的原因。
对搜索结果应用过滤带来了全新的复杂性级别。仅仅对原始数据应用一个算法已经不够了。通过过滤，这变成了一个不同索引之间进行交叉集成的问题。
为了衡量不同搜索引擎在此场景中的表现，我们准备了一套**过滤 ANN 基准数据集** - https://github.com/qdrant/ann-filtering-benchmark-datasets
它与ann-benchmarks 项目中使用的数据集类似，但增加了 Payload 元数据和预先生成的过滤请求。它包含带有各种过滤条件的合成和真实世界数据集，从关键词到地理空间查询。
没有多少 ANN 算法兼容过滤功能。HNSW 是少数支持过滤的算法之一，但搜索引擎集成它的方式各不相同
除此之外，搜索精度也存在问题。这表现在如果过滤掉太多向量，HNSW 图会变得断开连接。
Qdrant 采用了一种不同的方法，无需预过滤或后过滤，同时解决了精度问题。在我们的可过滤 HNSW 文章中阅读更多关于 Qdrant 方法的信息。
可能存在。即使我们努力做到客观，我们也不是所有现有向量数据库的使用专家。我们构建 Qdrant，因此对其了解最多。因此，我们可能忽略了不同向量搜索引擎中的一些重要调整。
然而，我们已尽力做到最好，反复查阅文档，尝试了不同配置的组合，并给予所有引擎同等的表现机会。如果您认为可以做得比我们更好，我们的**基准测试已完全开源，欢迎贡献**！
在决定使用哪个数据库时，需要考虑几个因素。当然，其中一些支持不同的功能子集，这可能是做出决定的关键因素。但总的来说，我们都关心搜索精度、速度以及实现这些所需的资源。
有一点很重要——**只有在精度相同时，才能比较向量数据库的速度**。否则，它们可能会通过提供不准确的结果来最大化速度，这是每个人都宁愿避免的。因此，我们的基准测试结果仅在特定的搜索精度阈值下进行比较。
在我们的实验中，我们不关注指标的绝对值，而是关注不同引擎之间的相对比较。重要的是我们对所有测试使用了相同的机器。在启动不同引擎之间会擦除机器状态。
我们选择了一台普通机器，您可以轻松地从几乎任何云提供商那里租用。不需要额外的配额或自定义配置。
FAISS 等库为向量搜索实验提供了很棒的工具。但它们距离生产环境的实际使用还有很远的距离。如果您在生产环境中使用 FAISS，最好的情况是您永远不需要实时更新它。最坏的情况是，您必须在其周围构建自定义封装层来支持 CRUD 操作、高可用性、横向扩展、并发访问等等。
一些向量搜索引擎甚至在底层使用 FAISS，但搜索引擎不仅仅是一个索引算法。
不过，我们确实使用了与著名的ann-benchmarks 项目相同的基准数据集，因此出于任何实际原因，您可以调整您的预期。
关于运行基准测试的最佳技术，目前没有共识。您可以自由选择 Go、Java 或 Rust 等系统。但我们使用 Python 进行此测试主要有两个原因
从用户的角度来看，关键在于使用特定库（在大多数情况下是 Python 客户端）时感知到的延迟。没有人能够，甚至不应该仅仅因为使用某个特定的搜索工具而重新定义整个技术栈。这就是为什么我们决定主要关注数据库作者提供的官方 Python 库。这些库底层可能使用了不同的协议，但最终，我们并不关心数据是如何传输的，只要它最终到达目标位置即可。
有些向量数据库仅作为 SaaS 提供，因此我们无法在与测试其他系统相同的机器上对其进行测试。这使得比较不公平。这就是为什么我们纯粹专注于测试开源向量数据库，以便所有人都能轻松重现基准测试。
这并非最终列表，我们将继续对尽可能多的不同引擎进行基准测试。
源代码可在Github 上获取，其中包含一个 README.md 文件，描述了针对特定引擎运行基准测试的过程。
我们将基准测试开源，因为我们相信它必须透明。我们可能配置某个引擎有误，或者只是效率不高。如果您认为可以帮助我们，请查看我们的基准测试仓库。