譯者 | 陳林

審校 | 孫淑娟 梁策

Milvus向量型數據庫的目標

當我們第一次出現Milvus向量型數據庫的想法時，我們希望構建的是一個數據基礎設施，從而加速人工智能在人們組織架構中的使用。

為了完成這一使命，我們為Milvus項目設定了兩個關鍵目標。

易用性

人工智能/機器學習是一個新興領域，新技術不斷涌現。大多數開發人員對于高速發展的AI技術和工具并不熟悉。開發人員花費了大量的精力來尋找、訓練和調整模型，基本沒有額外的精力來處理模型生成的大量嵌入向量，更不用說處理海量數據一直都是一項相當有挑戰的任務。

因此，我們給“易用性”定了相當高的優先級，因為它可以顯著地降低開發成本。

低運行成本

• AI投入實際生產應用的最大阻礙之一就是合理衡量投資回報比。有了更低的運行成本，我們將AI應用程序投入生產中將有更大的可能性，這將有利于提高邊際的潛在收益。

Milvus 2.0的設計原則

我們在 Milvus 1.0 中朝著這些目標邁出了第一步，但這還遠遠不夠，尤其是在可擴展性和可用性方面。然后我們開始研發Milvus 2.0來完善這些點。我們為2.0新版本制定的原則包括：

• 以高可擴展性和可用性為目標
• 基于成熟的云基礎架構和實踐
• 云端的最小性能妥協性

也就是說，我們想讓Milvus數據庫集群成為云原生。

Milvus數據庫集群的演進

向量數據庫是一種新型數據庫，因為它處理的向量數據是一種新的數據類型。它面臨與其他數據庫相同的挑戰，但也具有自身的一些場景和需求。在本文剩下的部分，我將重點介紹我們從現有的數據庫集群實現中能學到什么，以及我們在設計新的Milvus Group架構時的思考旅程。

如果你對Milvus Group組件的實現細節感興趣，請繼續關注 Milvus文檔。我們將在Milvus GitHub倉庫、Milvus官網和Milvus博客上持續發布技術文章。

理想的數據庫集群

讓我們首先羅列出一個理想的數據庫集群應該具備的關鍵能力。

• 支持并發且無單點故障：連接到不同組成員的用戶可以同時對同一條數據進行讀/寫訪問。
• 一致性：不同的組成員看到的數據應該是相同的。
• 可擴展性：我們可以隨時隨地添加或刪除組成員。

說實在的，現有數據庫是無法同時提供和保障這些能力的。在現代數據庫集群的實現中，人們不得不對其中的部分功能妥協。我們并不期望一個完美的數據庫集群，只要能夠適用和滿足用戶的業務場景就行了。然而，共享 “一切” 的集群一度非常接近理想的數據庫集群。如果我們想學習一些經驗，我們應該以它為基礎開始。

數據庫集群的主要考慮因素

與其他數據庫實現相比，shared-everything的數據庫集群具有更久遠的歷史。DB2數據共享組和Oracle RAC是典型的shared-everything集群。許多人認為shared-everything意味著共享磁盤，其實遠不止于此。

shared-everything的數據庫集群在組中只有一種數據庫成員。用戶可以連接到這些對等成員中的任何一個實例來訪問任何數據。完成這項操作需要共享的 “一切” 是什么?

組內事件序列

首先，組內事件序列對于解決不同組成員由于并發訪問引起的潛在沖突至關重要。我們通常使用數據庫日志記錄序號來表示事件的順序。同時，日志記錄序號一般是由時間戳生成的。

因此，對組內事件順序的要求等價于對全局定時器的需要。如果我們可以為組配備一個原子鐘，那就太棒了。然而，Milvus是一個開源軟件項目，這意味著我們應該依賴常用的資源。迄今為止，原子鐘仍然是大公司的首選。

我們在Milvus 2.0數據庫集群中實現了時間同步組件。您可以在附錄中找到鏈接。

全局鎖

數據庫有一個鎖定機制來解決并發訪問沖突，無論是樂觀鎖還是悲觀鎖。同樣，我們需要使用全局鎖定來解決不同組成員之間同時訪問的沖突。

全局鎖定意味著不同的組成員必須相互交談以協商鎖定請求。 影響這個全局鎖定協商過程的效率主要有幾個重要的因素：

• 系統間連接的速度
• 需要參與協商過程的組成員數量
• 組內發生沖突的頻率

通常的組大小不超過100。例如，DB2 DSG為32;Oracle RAC為100。這些組成員將被放置在一個通過光纖連接的服務器機房中，以最大限度地減少傳輸延遲。這就是為什么它有時被稱為集中式集群。 由于組大小的限制，人們會選擇高端服務器(大型機或小型機，在 CPU、內存、I/O 通道等方面具有更多容量)來組成共享一切集群。

這種硬件假設在現代云環境中發生了巨大變化。現如今，云數據中心都是由高密度服務器機房組成，集群配置了(數千臺) TCP/IP 網絡連通的商用 X86 服務器。如果我們依靠這些 X86 服務器來構建數據庫集群，那么組大小應該會增加到數百(甚至數千)臺機器。而在一些業務場景中，我們希望這數百臺X86機器分布在不同的區域。因此實現全局鎖定的價值和意義就不大了，因為全局鎖定性能不夠好。

在Milvus 2.0中，我們不會實現全局鎖定功能。一方面，向量數據不會有更新(用戶傾向于刪除后插入而不是更新)。所以我們不需要擔心基于分片編排的Milvus組內的同一條數據的由于多次寫入造成沖突。同時，我們可以使用MVCC(多版本并發控制，一種避免鎖的并發控制方法)來解決讀寫沖突。

另一方面，向量數據處理比結構化數據處理消耗更多的內存占用。 人們一直在尋找具有高擴展性的向量數據庫。

共享內存數據緩存

我們可以簡單地將數據庫引擎分為兩部分，即存儲引擎和計算引擎。存儲引擎負責兩項關鍵任務：

• 將數據寫入持久化存儲永久存儲。
• 將數據從持久化存儲加載到內存數據緩存(AKA緩沖池);這是計算引擎訪問數據的唯一地方。

在數據庫集群場景中，如果成員A更新了成員B中緩存的數據怎么辦?成員B如何知道其內存數據已過期?對于經典的 shared-everything集群，有一種緩沖區交叉失效機制來解決這個問題。 如果我們在組成員之間維持強一致性，則緩沖區交叉失效機制將類似于全局鎖。如上所述，它在現有的云環境中并不實用。所以我們決定將Milvus彈性云分組的一致性級別降低為最終一致性的方式。這樣，Milvus 2.0中的緩沖區交叉失效機制就可以是一個異步過程。

共享存儲

共享存儲可能是人們在討論數據庫集群時會想到的第一件事。

近年來，隨著云存儲的發展，存儲可選項也發生了顯著的變化。 存儲連接網絡 (SAN) 一直是shared-everything的存儲基礎。但是在云環境中并沒有SAN，數據庫必須使用本地磁盤連接到云虛擬機。使用本地磁盤對于跨組成員的數據一致性帶來了新的挑戰，而且我們還不得不考慮組成員的高可用。

Snowflake數據倉庫為打算使用云共享存儲(S3存儲)的云數據庫樹立了一個很好的榜樣，它也啟發了Milvus 2.0。如上所述，我們打算基于成熟的云基礎設施實現Milvus 2.0，但在我們能夠利用云共享存儲之前，我們必須考慮以下問題。

首先，S3存儲便宜且可靠，但它不是為像數據庫那樣的實時讀寫的場景而設計的。我們需要創建數據組件(我們在Milvus 2.0中稱為數據節點)來橋接本地內存/磁盤和S3存儲。市面上有一些示例可以參考，如Alluxio、JuiceFS等。無法直接集成這些項目的原因是我們考慮到不同的數據粒度。Alluxio和JuiceFS是為數據集或POSIX文件設計的，而我們專注于數據記錄(向量)級別。

當向量數據在S3存儲的問題被解決時，元數據的存儲很簡單：將它們存儲在etcd。那么日志數據呢?在傳統的實現中，日志存儲也是基于SAN。一個數據庫組成員的日志文件在數據庫集群內共享，用于故障恢復。在進入云環境之前這不是問題。

在Spanner論文中，Google展示了他們是如何使用Paxos共識算法實現全局分布式數據庫(組)的。你需要基于狀態機復制組實現數據庫集群，重做日志(redo log)通常就是用于整個組復制的那個“狀態”。

共識算法的重做日志(redo log)復制是一種強大的工具，在某些業務場景中具有相當大的優勢。但是，對于Milvus向量數據庫，我們沒有找到足夠的措施創建一個完整的狀態機復制組。我們決定使用云消息隊列/平臺(Apache Pulsar、Apache Kafka等)用于日志存儲，作為共享云存儲的替代品。通過將日志存儲委托給消息傳遞平臺，我們獲得了以下好處：

• 更加的事件驅動化，整個處理過程可以是異步的，從而提高了可擴展性。
• 組件耦合更松散，使得在線滾動升級和發布更容易，可用性和可操作性顯著提高。

我們將在后面的部分重新討論這個話題。

到目前為止，我們已經總結了設計一款數據庫集群要考慮的關鍵因素。在開始討論Milvus 2.0架構之前，讓我先說明一下我們是如何在Milvus中管理向量的。

數據管理和性能可預測性

Milvus將向量存儲在集合中。“集合”是一個邏輯概念，相當于SQL數據庫中的“表”。一個“集合”可以有多個物理文件來保存向量，一個物理文件是一個“段”。“段”是一個物理概念，類似于SQL數據庫中的表空間文件。當數據量較小時，我們可以將所有內容保存在單個段/物理文件中。但是，現如今不斷面臨著海量數據的存儲，當有多個段/物理文件時，應該如何將數據分散到不同的數據分區中?

盡管數據先于索引到來，但我們必須以更適合索引算法的方式存儲數據，以便在大多數情況下高效地訪問數據。SQL數據庫中常用的策略是以分區鍵值的范圍進行分區。通常情況下，就是創建一個聚集索引來強制分區鍵。這對于SQL數據庫來說是一種不錯的方法，一方面數據存儲良好，另一方面針對 I/O(預取)進行了優化，但仍然存在以下缺陷：

• 數據傾斜：某些分區可能比其他分區存儲了更多的數據，實際應用中數據的分布并不像數值范圍那么簡單。
• 訪問熱點：更多工作負載可能會流向其中幾個數據分區。

當越來越多的工作負載流向數據傾斜度高的分區時，我們需要對各個分區的數據進行重新平衡。

向量的聚集索引

我們還可以為向量創建聚集索引(倒排列表索引)，這與SQL 數據庫的索引不同。給SQL數據庫建立索引后，通過索引訪問數據非常高效，計算量少，I/O操作少。然而對于向量數據來說，即使有索引，計算和I/O操作也不會因此減少。因此，在向量數據庫集群中，數據傾斜和熱點數據集中的影響更為明顯。此外，由于數據量和計算復雜性因素，在不同分段對向量進行重新平衡的成本非常高。

在Milvus中，我們采用分區自動增長的策略。當我們將數據存入向量集合時，Milvus會將新向量追加到集合中的最新段。一旦這個段的大小達到某個閾值(閾值可配置)，Milvus將關閉該段并為關閉的段建立索引。同時，它還將創建一個新段來存儲新的數據。這種簡單的策略對于向量處理來說平衡性更友好。

向量查詢指的是在向量集合中查詢與目標條件匹配度最相近的結果。它是一個典型的Map Reduce過程。例如，如果想從包含10個分段的向量集合中搜索前20個相似的結果，我們可以搜索每個段的前20個，然后將20 * 10個查詢合并，篩選出其中20個結果返回。 由于每個段具有相同數量的向量和相似的索引，因此每個段的處理時間幾乎相同。這樣的好處是帶來了性能可預測性的優勢，它在規劃數據庫集群的規模時至關重要。

Milvus 2.0的新范式

在Milvus 1.0中，我們實現了與大多數SQL數據庫一樣的讀寫分離分片組。這種實現對Milvus數據庫集群來說是種不錯的嘗試，但帶來的問題也是顯而易見的。

Milvus 1.0：分片集群

在Milvus 1.0中，寫節點必須全程維護最新的段，其中就包括在未索引的段中追加向量、搜索向量，以及建立索引等操作。由于每個集合只有一個寫節點，如果數據在源源不斷地寫入系統，寫入節點將會成為瓶頸。寫節點和其他讀節點之間的數據共享性能也是一個問題。此外，我們必須依賴 NFS(不穩定)或者商用云存儲(太貴)來作為共享數據存儲。

以上問題在Milvus 1.0架構中很難解決。 因此，我們在Milvus 2.0設計中引入了新的范式。

Milvus 2.0：彈性云向量數據庫

Actor模型

現在有兩種常用的并發計算的模型編程。

• 共享內存：對應的是并發控制(鎖定)和同步處理。
• Actor模型(AKA 消息傳遞)：對應的是消息驅動和異步處理。

我們也可以在分布式數據庫集群中應用這兩種模型。

近年來，基于Redo-log復制的算法一直是最被高估的數據庫技術,它存在兩個關鍵問題。

• Redo-log復制更好的假設是脆弱的。
• 供應商誤導了人們對共識算法能力的期望。

假設我們有兩個數據庫節點，一個是主節點，另一個是從節點。 從一開始，兩個節點的數據是完全一致的。我們在主節點上有一些修改操作(新增/更新/刪除的SQL語句)，我們希望保持從節點同步更新。我們應該做什么?最簡單的方法是在從節點上重放更新操作，但這不是最高效的手段。

考慮新增/更新/刪除語句的運行成本：我們可以將其分為執行準備和實際執行部分。執行準備部分包括SQL解析器、SQL優化器等工作，不管影響到了多少條數據記錄，成本都是固定的。實際執行部分的成本取決于有多少數據記錄會受到影響，它的成本是浮動的。 redo-log復制背后的想法是為了節約從節點上的固定成本，即只在從節點上重放redo-log即可。

成本節省率和redo-log記錄數成反比。如果一次更新操作只影響一條記錄，redo-log復制其實有很大的提升空間。如果是10000條記錄呢?當然，我們還應該關心網絡可靠性。哪個更可靠，發送一個操作還是10000條redo-log記錄?一百萬條記錄又怎么樣? redo-log復制最適合的場景是支付系統、元數據系統等。在這些場景中，每個數據庫新增/更新/刪除操作只影響少量的記錄(1或2)，它不適用于I/O密集型類的場景，例如任務批處理。

部分供應商總是聲稱共識算法可以為數據庫集群提供強一致性。雖然redo-log記錄在不同節點上是一致的，但這并等價于數據視圖也是一致的。沒有將redo-log記錄合并到數據庫表之前，即使使用這種同步處理，我們也只能在數據上保證最終一致性。

我們應該在合適的場景下使用redo-log復制一致性算法。 Milvus 2.0中使用的元數據系統(etcd)和消息中間件平臺(例如 Apache Pulsar)已經實現了一致性算法。但正如我之前所說的，“對于Milvus向量數據庫，目前還沒有辦法讓它成為一個完整的狀態機復制組。

在Milvus 2.0中，我們使用Actor模型來編排工作節點。工作節點是單獨隔離的，它們只與消息中間件平臺通信，獲取命令并發送結果。

Actor模型是異步的，它適用于對擴展性和可用性要求高的場景。由于工作節點之間是互相隔離的，加入或移除部分工作節點對其他工作節點沒有影響。

可用性和持久性的分離

在 Milvus 2.0 中，我們實現的是操作重放而不是日志重放。因為在向量數據庫中，操作重放和日志重放沒有太大區別。我們沒有更新功能，也沒有查詢插入功能，并且使用Actor模型進行操作回放要簡單得多。

多個工作節點可能會根據各自的職責從消息中間件平臺執行相同的操作。之前提到我們決定使用S3云存儲作為Milvus數據庫集群的共享存儲層。S3存儲非常可靠，那么不同的工作節點是否需要將相同的數據寫入共享存儲呢?

因此，我們把工作節點分類為以下三個角色：

• 查詢節點：它維護一個內存數據視圖。查詢節點的工作包括提供向量搜索和對內存中數據的更新。但它不需要向S3存儲寫入任何內容。它是組中對內存最敏感的節點。
• 數據節點：負責將新數據寫入S3存儲。數據節點不需要維護內存中的數據視圖，因此數據節點的硬件配置與查詢節點有很大的不同。
• 索引節點：當段的大小達到閾值時，索引節點為數據節點已關閉的段建立索引。這是該組中對CPU密集性要求最高的節點。

這三種類型的節點分擔了不同類型的工作負載。它們可以獨立擴展。這里的可用性和持久性分離是從微軟Socrates云數據庫中學習衍生而來的。

總結和展望

本文回顧了Milvus向量數據庫2.0版本的幾個設計決策。讓我們在這里快速總結一下這些要點。

• Milvus集群2.0版本選擇了最終一致性。
• 我們盡可能將成熟的云組件集成到Milvus 2.0中，并控制了因適用Milvus 2.0引入到用戶生產環境中的新組件。
• Milvus 2.0遵循Actor模型，對可用性和持久性實現了分離，在云環境中易于擴展。

到目前為止，Milvus 2.0彈性云數據庫的骨架已經定型，目前還有許多來自Milvus社區的需求需要滿足。如果您有相同的使命(“構建更多開源基礎設施軟件，加速AI轉型”)，歡迎加入Milvus社區。

Milvus是LF AI & Data基金會的孵化的項目。你無需為Milvus 簽署任何CLA!

附錄

Milvus設計文檔

??https://github.com/milvus-io/milvus/tree/master/docs/design_docs??

Raft的C++實現

如果你對共識算法感興趣，建議你查看eBay的開源項目 Gringofts。它是Raft共識算法(Paxos系列的一個變體)的C++實現。它是我的朋友Jacky和Elvis(我在摩根士丹利的前同事)為eBay 在線支付系統構建的，這也正是它最適合的場景之一。

譯者介紹

陳林，51CTO社區編輯，某零售銀行龍頭DevOps持續集成平臺技術負責人，主導核心業務方案設計落地，推動產品架構持續演進。負責安全工具接入、掃描中臺建設、構建加速、SCM性能優化、鏡像治理等模塊。參與微服務治理、多活構建調度架構、異構存儲集群集成、緩存和分布式限流等架構優化。熱愛開源技術和寫文章，追求技術廣度和領域深度。

原文標題：Evolution of Milvus Cloud-Scalable Vector Database，作者：Jun Gu