Milvus 架構概述
Milvus 是一個開放源碼、雲原生向量資料庫，專為在大量向量資料集上進行高效能相似性搜尋而設計。它建構在流行的向量搜尋程式庫（包括 Faiss、HNSW、DiskANN 和 SCANN）之上，可增強人工智能應用程式和非結構化資料檢索情境的能力。在繼續之前，請先熟悉嵌入式檢索的基本原理。
架構圖
下圖說明 Milvus 的高階架構，展示其模組、可擴充及雲原生的設計，以及完全分解的儲存層與運算層。
架構圖
架構原則
Milvus 遵循資料平面與控制平面分解的原則，包含四個主要層級，在可擴充性及災難復原方面相互獨立。這種共用儲存架構具有完全分解的儲存層與運算層，可讓運算節點進行水平擴充，同時將 Woodpecker 實作為零磁碟 WAL 層，以增加彈性並降低作業開銷。
透過將串流處理分離為串流節點 (Streaming Node)，並將批次處理分離為查詢節點 (Query Node) 和資料節點 (Data Node)，Milvus 可在滿足即時處理需求的同時達到高效能。
詳細的層架構
第 1 層：存取層
存取層由一組無狀態代理組成，是系統的前端層，也是使用者的端點。它會驗證用戶端的要求，並減少傳回的結果：
- 代理本身是無狀態的。它使用負載平衡元件（如 Nginx、Kubernetes Ingress、NodePort 和 LVS）提供統一的服務位址。
- 由於 Milvus 採用大規模平行處理 (MPP) 架構，因此代理會先將中間結果聚合並進行後處理，再將最終結果回傳給用戶端。
第二層：協調器
協調器是 Milvus 的大腦。在任何時候，整個群集都會有一位 Coordinator 正處於活動狀態，負責維護群集拓樸、排程所有任務類型，並確保群集層級的一致性。
以下是一些由Coordinator 處理的任務：
- DDL/DCL/TSO 管理：處理資料定義語言 (DDL) 和資料控制語言 (DCL) 請求，例如建立或刪除集合、分割或索引，以及管理時間戳 Oracle (TSO) 和時間刻度發佈。
- 串流服務管理：將 Write-Ahead Log (WAL) 與串流節點綁定，並提供串流服務的服務發現。
- 查詢管理：管理查詢節點的拓樸結構和負載平衡，並提供和管理服務查詢檢視，以引導查詢路由。
- 歷史資料管理：將離線工作（例如壓縮和建立索引）分派給資料節點，並管理區段的拓樸結構和資料檢視。
第 3 層：工作節點
手腳。工作節點是遵循協調器指示的啞巴執行器。由於儲存與計算的分離，工作節點是無狀態的，當部署在 Kubernetes 上時，可促進系統擴充與災難復原。Worker 節點有三種類型：
串流節點
Streaming Node 作為 shard 層級的「小腦」，提供 shard 層級的一致性保證和基於底層 WAL 儲存的故障復原。同時，Streaming Node 也負責成長中的資料查詢和產生查詢計畫。此外，它還處理將成長中的資料轉換為封存（歷史）資料。
查詢節點
查詢節點從物件儲存載入歷史資料，並提供歷史資料查詢。
資料節點
資料節點負責離線處理歷史資料，例如壓縮和建立索引。
第四層：儲存
儲存是系統的骨骼，負責資料的持久性。它包括元儲存、日誌中介和物件儲存。
元儲存
元存儲儲存了元資料的快照，例如收集模式和訊息消耗檢查點。儲存元資料需要極高的可用性、強大的一致性和交易支援，因此 Milvus 選擇 etcd 作為元儲存。Milvus 也使用 etcd 進行服務註冊和健康檢查。
物件儲存
物件儲存存放日誌的快照檔案、標量與向量資料的索引檔案，以及中間查詢結果。Milvus 使用 MinIO 作為物件儲存，並可隨時部署在 AWS S3 和 Azure Blob 這兩種全球最流行、最具成本效益的儲存服務上。然而，物件儲存有很高的存取延遲，並且會依據查詢次數收費。為了提升效能並降低成本，Milvus 計劃在記憶體或 SSD 為基礎的快取記憶體池上實施冷熱資料分離。
WAL 儲存
Write-Ahead Log (WAL) 儲存是分散式系統中資料耐久性與一致性的基礎。在提交任何變更之前，首先會將其記錄在日誌中，以確保在發生故障時，可以準確地恢復到之前的位置。
常見的 WAL 實作包括 Kafka、Pulsar 和 Woodpecker。與傳統基於磁碟的解決方案不同，Woodpecker 採用雲原生、零磁碟設計，直接寫入物件儲存。這種方法可以毫不費力地根據您的需求進行擴展，並透過消除管理本機磁碟的開銷來簡化作業。
透過提前記錄每次寫入作業，WAL 層可保證可靠的全系統復原與一致性機制 - 無論您的分散式環境有多複雜。
資料流程與 API 分類
Milvus API 依其功能分類，並遵循架構的特定路徑：
| API 類別 | 操作 | 示例 API | 架構流程 |
|---|---|---|---|
| DDL/DCL | 模式與存取控制 | createCollection,dropCollection,hasCollection 、createPartition | 存取層 → 協調器 |
| DML | 資料處理 | insert,delete 、upsert | 存取層 → 串流工作節點 |
| 資料查詢 | 資料查詢 | search,query | 存取層 → 批次工作節點 (查詢節點) |
資料流程範例：搜尋作業
- 用戶端透過 SDK/RESTful API 發送搜尋請求
- 負載平衡器將請求路由至存取層中可用的代理伺服器
- 代理使用路由快取記憶體決定目標節點；只有在快取記憶體不可用時才聯絡協調器
- 代理將請求轉發至適當的串流節點，然後與查詢節點協調進行密封資料搜尋，同時在本機執行成長中的資料搜尋
- 查詢節點依需要從物件儲存載入封存區段，並執行區段層級搜尋
- 搜尋結果進行多層次還原：查詢節點還原多個區段的結果，串流節點還原查詢節點的結果，代理還原所有串流節點的結果，然後再返回用戶端
資料流程範例：資料插入
- 用戶端傳送包含向量資料的插入請求
- 存取層驗證並轉發請求給串流節點
- 流節點將作業記錄到 WAL 儲存區以獲得持久性
- 即時處理資料，並提供給查詢使用
- 當區段達到容量時，串流節點會觸發轉換為密封區段
- 資料節點處理壓縮，並在密封區段之上建立索引，將結果儲存於物件儲存空間中
- 查詢節點載入新建立的索引，並取代相對應的成長中資料