单节点基准测试

观察

自上次运行以来，大多数引擎都有所改进。生活和软件都有权衡，但有些显然做得更好

• Qdrant 在几乎所有场景下都实现了最高的 RPS 和最低的延迟，无论我们选择哪种精度阈值和指标。它还在其中一个数据集上显示出 4 倍的 RPS 提升。
• Elasticsearch 在许多情况下变得相当快，但在索引时间方面非常慢。当存储 10M+ 个 96 维度的向量时，它可能慢 10 倍！（32分钟 vs 5.5 小时）
• Milvus 在索引时间方面最快，并保持了良好的精度。然而，当你的嵌入维度更高或向量数量更多时，在 RPS 或延迟方面与其他引擎相比并不占优。
• Redis 能够实现良好的 RPS，但主要是在较低精度下。它在单线程下也实现了低延迟，然而随着并行请求的增加，其延迟迅速上升。部分速度提升源于其自定义协议。
• 自上次运行以来，Weaviate 的改进最少。

如何阅读结果

• 选择您想查看的数据集和指标。
• 选择一个满足您用例需求的精度阈值。这很重要，因为 ANN 搜索本质上是权衡精度与速度。这意味着在任何向量搜索基准测试中，只有当精度相似时，才能比较两个结果。然而，大多数基准测试都忽略了这一关键点。
• 表格按选定指标（RPS / 延迟 / p95 延迟 / 索引时间）的值进行排序，第一个条目始终是该类别的赢家 🏆

延迟 vs RPS

在我们的基准测试中，我们测试了实践中出现的两种主要搜索使用场景。

• 每秒请求数 (RPS)：以单个请求耗时更长（即延迟更高）为代价，每秒处理更多请求。这是网络应用的典型场景，多个用户同时进行搜索。为了模拟此场景，我们使用多线程并行运行客户端请求，并衡量引擎每秒可以处理多少请求。
• 延迟：快速响应单个请求，而不是并行处理更多请求。这是服务器响应时间至关重要的应用的典型场景。自动驾驶汽车、工业机器人和其他实时系统就是这类应用的良好示例。为了模拟此场景，我们使用单线程运行客户端，并测量每个请求所需的时间。

测试数据集

我们的基准测试工具受github.com/erikbern/ann-benchmarks启发。我们使用以下数据集来测试引擎在 ANN 搜索任务上的性能

设置

• 这是我们本次实验的设置
  • 客户端：8 vCPU，16 GiB 内存，64 GiB 存储（Azure 云上的 Standard D8ls v5）
  • 服务器：8 vCPU，32 GiB 内存，64 GiB 存储（Azure 云上的 Standard D8s v3）
• Python 客户端将数据上传到服务器，等待所有必需索引构建完成，然后使用配置的线程数执行搜索。我们为每个引擎重复此过程，采用不同的配置，然后为给定精度选择最佳配置。
• 我们在 docker 中运行所有引擎，并将内存限制为 25GB。这样做是为了确保公平性，避免某些引擎配置过度占用 RAM。这个 25GB 的限制是完全公平的，因为即使是处理最大的 dbpedia-openai-1M-1536-angular 数据集，所需的 RAM（包括向量 + 索引）也很少超过 1M * 1536 * 4字节 * 1.5 = 8.6GB。因此，我们决定为所有引擎提供约 3 倍于需求的内存。

请注意，由于 25GB 内存限制，某些引擎的某些配置在某些数据集上崩溃了。这就是为什么在选择更高精度阈值时，某些引擎的点数可能较少。