性能验证在矢量数据库和存储系统中都起着至关重要的作用，是确保最佳运行和高效资源利用的关键因素。矢量数据库以处理高维数据和执行相似性搜索而闻名，需要保持高性能水平才能快速准确地处理复杂查询。性能验证有助于识别瓶颈、微调配置并确保系统能够处理预期负载而不会降低服务质量。同样，在存储系统中，性能验证对于确保数据高效存储和检索至关重要，不会出现可能影响整体系统性能的延迟问题或瓶颈。它还有助于对存储基础设施的必要升级或变更做出明智的决策。因此，性能验证是系统管理的一个重要方面，对维持高服务质量、运行效率和整体系统可靠性有重要贡献。
在本节中，我们旨在深入研究矢量数据库（例如 Milvus 和 pgvecto.rs）的性能验证，重点关注它们的存储性能特征，例如 I/O 配置文件和 NetApp 存储控制器在 LLM 生命周期内支持 RAG 和推理工作负载的行为。当这些数据库与ONTAP存储解决方案结合时，我们将评估并识别任何性能差异因素。我们的分析将基于关键性能指标，例如每秒处理的查询数（QPS）。
请检查下面用于 milvus 和进度的方法。
在本节中，我们分享测试 Milvus 独立数据库的观察和结果。。我们选择 DiskANN 作为这些测试的索引类型。。提取、优化和创建大约 100GB 数据集的索引大约需要 5 个小时。在此持续时间的大部分时间里，配备 20 个内核（启用超线程时相当于 40 个 vCPU）的 Milvus 服务器都以其最大 CPU 容量 100% 运行。我们发现 DiskANN 对于超过系统内存大小的大型数据集尤为重要。。在查询阶段，我们观察到每秒查询次数 (QPS) 为 10.93，召回率为 0.9987。查询的第 99 个百分位延迟测量为 708.2 毫秒。
从存储角度来看，数据库在摄取、插入后优化和索引创建阶段发出大约 1,000 个操作/秒。在查询阶段，它要求每秒 32,000 次操作。
以下部分介绍存储性能指标。
带有 milvus 集群的 VectorDB-Bench
在本节中，我们讨论在 Kubernetes 环境中部署 Milvus 集群。此 Kubernetes 设置构建于 VMware vSphere 部署之上，该部署托管 Kubernetes 主节点和工作节点。
以下部分介绍 VMware vSphere 和 Kubernetes 部署的详细信息。
在本节中，我们分享测试 PostgreSQL 数据库（特别是使用 pgvecto.rs）的观察和结果。 * 我们选择 HNSW 作为这些测试的索引类型，因为在测试时，DiskANN 不适用于 pgvecto.rs。 * 在数据提取阶段，我们加载了 Cohere 数据集，该数据集包含 1000 万个向量，维度为 768。该过程大约耗时 4.5 小时。 * 在查询阶段，我们观察到每秒查询次数 (QPS) 为 1,068，召回率为 0.6344。查询的第 99 个百分位延迟测量为 20 毫秒。在大部分运行时间内，客户端 CPU 都以 100% 的容量运行。
下图提供了各种存储指标的视图，包括存储集群延迟总 IOPS（每秒输入/输出操作）。
我们发现 pgvecto.rs 的每秒查询数 (QPS) 达到 1,068，召回率为 0.6344，而 Milvus 的每秒查询数 (QPS) 达到 106，召回率为 0.9842。
如果您优先考虑查询的高精度，那么 Milvus 的性能优于 pgvecto.rs，因为它在每个查询中检索到更高比例的相关项目。但是，如果每秒查询次数是一个更关键的因素，那么 pgvecto.rs 就超过了 Milvus。但值得注意的是，通过 pgvecto.rs 检索的数据质量较低，大约 37% 的搜索结果是不相关的项目。
根据我们的性能验证得出的观察结果：
根据我们的性能验证，我们做出了以下观察：
在 Milvus 中，I/O 配置文件与 OLTP 工作负载非常相似，例如 Oracle SLOB 中的工作负载。基准测试包括三个阶段：数据提取、后优化和查询。初始阶段主要以 64KB 写入操作为特征，而查询阶段主要涉及 8KB 读取。我们希望ONTAP能够熟练地处理 Milvus I/O 负载。
PostgreSQL I/O 配置文件不会带来具有挑战性的存储工作负载。鉴于目前正在进行的内存实现，我们在查询阶段没有观察到任何磁盘 I/O。
DiskANN 成为存储区分的关键技术。它使得向量数据库搜索能够超越系统内存边界进行有效扩展。然而，不太可能通过内存中的向量数据库索引（例如 HNSW）建立存储性能差异。
还值得注意的是，当索引类型为 HSNW 时，存储在查询阶段并不起关键作用，而查询阶段是支持 RAG 应用的矢量数据库最重要的操作阶段。这里的含义是存储性能不会显著影响这些应用程序的整体性能。
