我们使用vittorDB-Bench对Milvus独立集群进行了以下性能验证。
Milvus独立集群的网络和服务器连接如下。

在本节中、我们将分享测试Milvus独立数据库时观察到的结果。
。 我们选择DiskANN作为这些测试的索引类型。
。 为大约100 GB的数据集执行数据导入、优化和创建索引大约需要5小时。在这段时间内的大部分时间内、配备20个核心(启用超线程时相当于40个vCPU)的Milvus服务器以其100%的最大CPU容量运行。我们发现、DiskANN对于超过系统内存大小的大型数据集尤为重要。
。 在查询阶段、我们观察到每秒查询数(Queries Per Second、QPS)比率为10.93、而调用率为0.9987。查询延迟的第99个百位点在708.2毫秒处测量。

从存储角度来看、在加载、插入后优化和索引创建阶段、数据库发出的操作数大约为1、000次/秒。在查询阶段、它需要32,000次操作/秒

下一节介绍了存储性能指标。

以下是以下的bittorDB-bench结果。

从独立Milvus实例的性能验证来看、很明显、当前设置不足以支持一个包含500万向量且维度为1536的数据集。我们已确定存储具有足够的资源、不会在系统中构成瓶颈。

在本节中、我们将讨论如何在Kubbernetes环境中部署Milvus集群。此Kubnetes设置是在VMware vSphere部署基础上构建的、该部署托管Kubnetes主节点和工作节点。

以下各节介绍了VMware vSphere和Kubnetes部署的详细信息。

在本节中、我们将介绍测试Milvus数据库时观察到的结果。
*使用的索引类型为DiskANN。
*下表提供了在维数为1536的情况下处理500万向量时独立部署与集群部署之间的比较。我们发现、在集群部署中、数据采集和插入后优化所需的时间较短。与独立设置相比、集群部署中查询延迟的第99个百位数减少了6倍。
*虽然集群部署中的每秒查询数(QPS)率较高、但并未达到所需的级别。

下图提供了各种存储指标的视图、包括存储集群延迟和总IOPS (每秒输入/输出操作数)。

下一节介绍了主要的存储性能指标。

根据独立Milvus和Milvus集群的性能验证、我们将提供存储I/O配置文件的详细信息。
*我们发现、无论是独立部署还是集群部署、I/O配置文件都保持一致。
*峰值IOPS的观察到差异可能是由于集群部署中的客户端数量较多所致。

我们使用了向量数据库对PostgreSQL (pg向 量.rs)执行了以下操作：
有关PostgreSQL (特别是pg向 量.rs)的网络和服务器连接的详细信息如下：

在本节中、我们将分享对PostgreSQL数据库(尤其是使用pg向 量.rs)进行测试后观察到的结果。
*我们选择HNSW作为这些测试的索引类型、因为在测试时、DiskANN不适用于pg向 量.rs。
*在数据载入阶段、我们加载了cothere数据集、该数据集由1、000万个向量组成、维数为768。此过程大约需要4.5小时。
*在查询阶段、我们观察到每秒查询数(Queries Per Second、QPS)比率为1、068、而调用率为0.6344。查询延迟的第99个百位点在20毫秒处测量。在运行时的大部分时间内、客户端CPU都以100%的容量运行。

下图提供了各种存储指标的视图、包括存储集群延迟总IOPS (每秒输入/输出操作数)。

根据我们使用VittorDBBench对Milvus和PostgreSQL进行的性能验证、我们观察到以下情况：

我们发现、pgvrecto .rs的每秒查询数(Queries Per Second、QPS)为1、068、召回率为0.6344、而Milvus的召回率为106、召回率为0.9842。

如果查询的高精度是优先事项、则Milvus的性能会优于pgvitou.rs、因为它会在每个查询中检索更高比例的相关项。但是、如果每秒查询数是一个更关键的因素、则pgvECG.rs将超过Milvus。但是、需要注意的是、通过pg向 量.rs检索的数据质量较低、大约37%的搜索结果是不相关的项目。

根据我们的性能验证、我们观察到以下情况：

在Milvus中、I/O配置文件与OLTP工作负载非常相似、例如Oracle slob中的工作负载。基准测试由三个阶段组成：数据采集、优化后和查询。初始阶段的特征主要是64 KB写入操作、而查询阶段主要涉及8 KB读取。我们希望ONTAP能够出色地处理Milvus I/O负载。

PostgreSQL I/O配置文件不会产生具有挑战性的存储工作负载。鉴于当前正在实施内存、我们在查询阶段未发现任何磁盘I/O。

DiskANN成为实现存储差异化优势的关键技术。它可以高效地将矢量数据库搜索扩展到系统内存边界之外。但是、使用HNSW等内存向量数据库索引不太可能建立存储性能差异。

此外、还需要注意的是、当索引类型为HSNW时、存储在查询阶段并不起关键作用、HSNW是支持RAG应用程序的矢量数据库最重要的操作阶段。此处的含义是、存储性能不会对这些应用程序的整体性能产生显著影响。