向量資料庫效能驗證
建議變更
PDF
本節重點介紹在向量資料庫上執行的效能驗證。
性能驗證
效能驗證在向量資料庫和儲存系統中都起著至關重要的作用，是確保最佳運作和高效資源利用的關鍵因素。向量資料庫以處理高維度資料和執行相似性搜尋而聞名，需要保持高效能水準才能快速準確地處理複雜查詢。效能驗證有助於識別瓶頸、微調配置並確保系統能夠處理預期負載而不會降低服務品質。同樣，在儲存系統中，效能驗證對於確保資料高效儲存和檢索至關重要，不會出現可能影響整體系統效能的延遲問題或瓶頸。它還有助於對儲存基礎設施的必要升級或變更做出明智的決策。因此，效能驗證是系統管理的重要方面，對維持高服務品質、運作效率和整體系統可靠性有重要貢獻。
在本節中，我們旨在深入研究向量資料庫（例如 Milvus 和 pgvecto.rs）的效能驗證，重點關注它們的儲存效能特徵，例如 I/O 設定檔和 NetApp 儲存控制器在 LLM 生命週期內支援 RAG 和推理工作負載的行為。當這些資料庫與ONTAP儲存解決方案結合時，我們將評估並識別任何效能差異因素。我們的分析將基於關鍵效能指標，例如每秒處理的查詢數（QPS）。
請檢查下面用於 milvus 和進度的方法。
細節 |
Milvus（單機和叢集） |
Postgres（pgvecto.rs）# |
版本 |
2.3.2 |
0.2.0 |
檔案系統 |
iSCSI LUN 上的 XFS |
|
工作負載產生器 |
"VectorDB-Bench"– v0.0.5 |
|
數據集 |
LAION 資料集 * 1000 萬個嵌入 * 768 個維度 * 資料集大小約 300GB |
|
儲存控制器 |
AFF 800 * 版本 — 9.14.1 * 4 x 100GbE — 用於 milvus，2x 100GbE 用於 postgres * iscsi |
帶有 Milvus 獨立叢集的 VectorDB-Bench
我們使用vectorDB-Bench在milvus獨立叢集上進行了以下效能驗證。 milvus 獨立叢集的網路和伺服器連線如下。
在本節中，我們分享測試 Milvus 獨立資料庫的觀察和結果。。我們選擇 DiskANN 作為這些測試的索引類型。。提取、優化和建立大約 100GB 資料集的索引大約需要 5 個小時。在此持續時間的大部分時間裡，配備 20 個核心（啟用超線程時相當於 40 個 vCPU）的 Milvus 伺服器都以其最大 CPU 容量 100% 運行。我們發現 DiskANN 對於超過系統記憶體大小的大型資料集尤其重要。。在查詢階段，我們觀察到每秒查詢次數 (QPS) 為 10.93，回想率為 0.9987。查詢的第 99 個百分位延遲測量為 708.2 毫秒。
從儲存角度來看，資料庫在攝取、插入後最佳化和索引建立階段發出約 1,000 次操作/秒。在查詢階段，它要求每秒 32,000 次操作。
以下部分介紹儲存效能指標。
| 工作負載階段 | 公制 | 價值 |
|---|---|---|
資料擷取和插入後優化 |
每秒輸入/輸出次數 |
< 1,000 |
延遲 |
< 400 微秒 |
|
工作量 |
讀/寫混合，主要是寫入 |
|
IO大小 |
64KB |
|
詢問 |
每秒輸入/輸出次數 |
峰值為32,000 |
延遲 |
< 400 微秒 |
|
工作量 |
100% 快取讀取 |
|
IO大小 |
主要為8KB |
VectorDB-bench 結果如下。
從獨立 Milvus 實例的效能驗證來看，目前的設定不足以支援 500 萬個向量、維度為 1536 的資料集。我們已確定儲存擁有足夠的資源，不會構成系統的瓶頸。
帶有 milvus 叢集的 VectorDB-Bench
在本節中，我們討論在 Kubernetes 環境中部署 Milvus 叢集。此 Kubernetes 設定建置於 VMware vSphere 部署之上，該部署託管 Kubernetes 主節點和工作節點。
以下部分介紹 VMware vSphere 和 Kubernetes 部署的詳細資訊。
在本節中，我們介紹了測試 Milvus 資料庫的觀察結果和結果。 * 使用的索引類型是 DiskANN。 * 下表比較了在處理 500 萬個向量（維度為 1536）時獨立部署和集群部署的差異。我們觀察到，在叢集部署中，資料擷取和插入後最佳化所需的時間較短。與獨立設定相比，叢集部署中查詢的第 99 個百分位延遲減少了六倍。 * 儘管叢集部署中的每秒查詢數 (QPS) 率較高，但並未達到預期水準。
下圖提供了各種儲存指標的視圖，包括儲存叢集延遲和總 IOPS（每秒輸入/輸出操作）。
以下部分介紹關鍵的儲存效能指標。
| 工作負載階段 | 公制 | 價值 |
|---|---|---|
資料擷取和插入後優化 |
每秒輸入/輸出次數 |
< 1,000 |
延遲 |
< 400 微秒 |
|
工作量 |
讀/寫混合，主要是寫入 |
|
IO大小 |
64KB |
|
詢問 |
每秒輸入/輸出次數 |
峰值為147,000 |
延遲 |
< 400 微秒 |
|
工作量 |
100% 快取讀取 |
|
IO大小 |
主要為8KB |
基於獨立 Milvus 和 Milvus 叢集的效能驗證，我們展示了儲存 I/O 設定檔的詳細資訊。 * 我們觀察到 I/O 設定檔在獨立部署和叢集部署中保持一致。 * 峰值 IOPS 的觀察到的差異可以歸因於群集部署中的客戶端數量較多。
附有 Postgres 的vectorDB-Bench（pgvecto.rs）
我們使用 VectorDB-Bench 對 PostgreSQL（pgvecto.rs）進行瞭如下操作：PostgreSQL（具體來說，pgvecto.rs）的網路和伺服器連線詳情如下：
在本節中，我們分享測試 PostgreSQL 資料庫（特別是使用 pgvecto.rs）的觀察和結果。 * 我們選擇 HNSW 作為這些測試的索引類型，因為在測試時，DiskANN 不適用於 pgvecto.rs。 * 在資料擷取階段，我們載入了 Cohere 資料集，該資料集包含 1,000 萬個向量，維度為 768。該過程大約耗時 4.5 小時。 * 在查詢階段，我們觀察到每秒查詢次數 (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["此圖顯示輸入/輸出對話框或表示書面內容"]
milvus 與 postgres 在向量資料庫基準測試上的效能對比
根據我們使用 VectorDBBench 對 Milvus 和 PostgreSQL 進行的效能驗證，我們觀察到以下情況：
-
索引類型：HNSW
-
資料集：包含 768 個維度的 1000 萬個向量
我們發現 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 應用的向量資料庫最重要的操作階段。這裡的含義是儲存效能不會顯著影響這些應用程式的整體效能。