向量数据库性能验证
建议更改
PDF
本节重点介绍对向量数据库执行的性能验证。
性能验证
性能验证在矢量数据库和存储系统中都发挥着关键作用、是确保最佳运行和高效利用资源的关键因素。向量数据库因处理高维度数据和执行相似性搜索而闻名、需要保持高性能水平、才能快速准确地处理复杂的查询。性能验证有助于识别瓶颈、微调配置、并确保系统可以处理预期负载而不会降低服务质量。同样、在存储系统中、性能验证对于确保高效存储和检索数据至关重要、不会出现可能影响整体系统性能的延迟问题或瓶颈。它还有助于在存储基础架构的必要升级或更改方面做出明智的决策。因此、性能验证是系统管理的一个关键方面、它可以显著提高服务质量、运营效率和整体系统可靠性。
在本节中、我们将深入探讨Milvus和pgvector.rs等向量数据库的性能验证、重点介绍其存储性能特征、例如I/O配置文件和NetApp存储控制器在LLM生命周期内支持RAG和推导工作负载时的行为。我们将评估并确定将这些数据库与ONTAP存储解决方案结合使用时的任何性能差异。我们的分析将基于关键绩效指标、例如每秒处理的查询数量(QPS)。
请在下面检查用于milvus的方法和进度。
详细信息 |
Milvus (独立和集群) |
Postgre (pg向 量.rs)# |
version |
2.3.2. |
0.2.0 |
文件系统 |
iSCSI LUN上的XFS |
|
工作负载生成器 |
"向数据库平台" v0.0.5 |
|
数据集 |
LAION数据集 |
|
存储控制器 |
AFF 800 版本—9.14.1 * 4个100GbE—适用于Milvus、2个100GbE适用于后端 iSCSI |
VittorDB-Bench与Milvus独立集群
我们使用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次操作/秒
下一节介绍了存储性能指标。
| 工作负载阶段 | 衡量指标 | 价值 |
|---|---|---|
数据载入 |
IOPS |
< 1、000 |
延迟 |
小于400美元 |
|
工作负载 |
读/写混合、大多数为写入 |
|
IO大小 |
64 KB |
|
查询 |
IOPS |
峰值为32、000 |
延迟 |
小于400美元 |
|
工作负载 |
100%缓存读取 |
|
IO大小 |
主要为8 KB |
以下是以下的bittorDB-bench结果。
从独立Milvus实例的性能验证来看、很明显、当前设置不足以支持一个包含500万向量且维度为1536的数据集。我们已确定存储具有足够的资源、不会在系统中构成瓶颈。
VittorDB-Bench与Milvus集群
在本节中、我们将讨论如何在Kubbernetes环境中部署Milvus集群。此Kubnetes设置是在VMware vSphere部署基础上构建的、该部署托管Kubnetes主节点和工作节点。
以下各节介绍了VMware vSphere和Kubnetes部署的详细信息。
在本节中、我们将介绍测试Milvus数据库时观察到的结果。
*使用的索引类型为DiskANN。
*下表提供了在维数为1536的情况下处理500万向量时独立部署与集群部署之间的比较。我们发现、在集群部署中、数据采集和插入后优化所需的时间较短。与独立设置相比、集群部署中查询延迟的第99个百位数减少了6倍。
*虽然集群部署中的每秒查询数(QPS)率较高、但并未达到所需的级别。
下图提供了各种存储指标的视图、包括存储集群延迟和总IOPS (每秒输入/输出操作数)。
下一节介绍了主要的存储性能指标。
| 工作负载阶段 | 衡量指标 | 价值 |
|---|---|---|
数据载入 |
IOPS |
< 1、000 |
延迟 |
小于400美元 |
|
工作负载 |
读/写混合、大多数为写入 |
|
IO大小 |
64 KB |
|
查询 |
IOPS |
峰值为147、000 |
延迟 |
小于400美元 |
|
工作负载 |
100%缓存读取 |
|
IO大小 |
主要为8 KB |
根据独立Milvus和Milvus集群的性能验证、我们将提供存储I/O配置文件的详细信息。
*我们发现、无论是独立部署还是集群部署、I/O配置文件都保持一致。
*峰值IOPS的观察到差异可能是由于集群部署中的客户端数量较多所致。
使用Postgre的向量数据库工作台(pg向 量.rs)
我们使用了向量数据库对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 (每秒输入/输出操作数)。
The following section presents the key storage performance metrics. image:pgvecto_storage_perf_metrics.png["图中显示了输入/输出对话框或表示已写入内容"]
Vector DB Bench上的Milvus与postgres之间的性能比较
根据我们使用VittorDBBench对Milvus和PostgreSQL进行的性能验证、我们观察到以下情况：
-
索引类型：HNSW
-
数据集：具有768个维度的1000万向量
我们发现、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应用程序的矢量数据库最重要的操作阶段。此处的含义是、存储性能不会对这些应用程序的整体性能产生显著影响。