譯者 | 陳林

審校 | 孫淑娟 梁策

Milvus向量型數(shù)據(jù)庫(kù)的目標(biāo)

當(dāng)我們第一次出現(xiàn)Milvus向量型數(shù)據(jù)庫(kù)的想法時(shí)，我們希望構(gòu)建的是一個(gè)數(shù)據(jù)基礎(chǔ)設(shè)施，從而加速人工智能在人們組織架構(gòu)中的使用。

為了完成這一使命，我們?yōu)镸ilvus項(xiàng)目設(shè)定了兩個(gè)關(guān)鍵目標(biāo)。

易用性

人工智能/機(jī)器學(xué)習(xí)是一個(gè)新興領(lǐng)域，新技術(shù)不斷涌現(xiàn)。大多數(shù)開(kāi)發(fā)人員對(duì)于高速發(fā)展的AI技術(shù)和工具并不熟悉。開(kāi)發(fā)人員花費(fèi)了大量的精力來(lái)尋找、訓(xùn)練和調(diào)整模型，基本沒(méi)有額外的精力來(lái)處理模型生成的大量嵌入向量，更不用說(shuō)處理海量數(shù)據(jù)一直都是一項(xiàng)相當(dāng)有挑戰(zhàn)的任務(wù)。

因此，我們給“易用性”定了相當(dāng)高的優(yōu)先級(jí)，因?yàn)樗梢燥@著地降低開(kāi)發(fā)成本。

低運(yùn)行成本

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

Milvus 2.0的設(shè)計(jì)原則

我們?cè)?Milvus 1.0 中朝著這些目標(biāo)邁出了第一步，但這還遠(yuǎn)遠(yuǎn)不夠，尤其是在可擴(kuò)展性和可用性方面。然后我們開(kāi)始研發(fā)Milvus 2.0來(lái)完善這些點(diǎn)。我們?yōu)?.0新版本制定的原則包括：

• 以高可擴(kuò)展性和可用性為目標(biāo)
• 基于成熟的云基礎(chǔ)架構(gòu)和實(shí)踐
• 云端的最小性能妥協(xié)性

也就是說(shuō)，我們想讓Milvus數(shù)據(jù)庫(kù)集群成為云原生。

Milvus數(shù)據(jù)庫(kù)集群的演進(jìn)

向量數(shù)據(jù)庫(kù)是一種新型數(shù)據(jù)庫(kù)，因?yàn)樗幚淼南蛄繑?shù)據(jù)是一種新的數(shù)據(jù)類(lèi)型。它面臨與其他數(shù)據(jù)庫(kù)相同的挑戰(zhàn)，但也具有自身的一些場(chǎng)景和需求。在本文剩下的部分，我將重點(diǎn)介紹我們從現(xiàn)有的數(shù)據(jù)庫(kù)集群實(shí)現(xiàn)中能學(xué)到什么，以及我們?cè)谠O(shè)計(jì)新的Milvus Group架構(gòu)時(shí)的思考旅程。

如果你對(duì)Milvus Group組件的實(shí)現(xiàn)細(xì)節(jié)感興趣，請(qǐng)繼續(xù)關(guān)注 Milvus文檔。我們將在Milvus GitHub倉(cāng)庫(kù)、Milvus官網(wǎng)和Milvus博客上持續(xù)發(fā)布技術(shù)文章。

理想的數(shù)據(jù)庫(kù)集群

讓我們首先羅列出一個(gè)理想的數(shù)據(jù)庫(kù)集群應(yīng)該具備的關(guān)鍵能力。

• 支持并發(fā)且無(wú)單點(diǎn)故障：連接到不同組成員的用戶(hù)可以同時(shí)對(duì)同一條數(shù)據(jù)進(jìn)行讀/寫(xiě)訪(fǎng)問(wèn)。
• 一致性：不同的組成員看到的數(shù)據(jù)應(yīng)該是相同的。
• 可擴(kuò)展性：我們可以隨時(shí)隨地添加或刪除組成員。

說(shuō)實(shí)在的，現(xiàn)有數(shù)據(jù)庫(kù)是無(wú)法同時(shí)提供和保障這些能力的。在現(xiàn)代數(shù)據(jù)庫(kù)集群的實(shí)現(xiàn)中，人們不得不對(duì)其中的部分功能妥協(xié)。我們并不期望一個(gè)完美的數(shù)據(jù)庫(kù)集群，只要能夠適用和滿(mǎn)足用戶(hù)的業(yè)務(wù)場(chǎng)景就行了。然而，共享 “一切” 的集群一度非常接近理想的數(shù)據(jù)庫(kù)集群。如果我們想學(xué)習(xí)一些經(jīng)驗(yàn)，我們應(yīng)該以它為基礎(chǔ)開(kāi)始。

數(shù)據(jù)庫(kù)集群的主要考慮因素

與其他數(shù)據(jù)庫(kù)實(shí)現(xiàn)相比，shared-everything的數(shù)據(jù)庫(kù)集群具有更久遠(yuǎn)的歷史。DB2數(shù)據(jù)共享組和Oracle RAC是典型的shared-everything集群。許多人認(rèn)為shared-everything意味著共享磁盤(pán)，其實(shí)遠(yuǎn)不止于此。

shared-everything的數(shù)據(jù)庫(kù)集群在組中只有一種數(shù)據(jù)庫(kù)成員。用戶(hù)可以連接到這些對(duì)等成員中的任何一個(gè)實(shí)例來(lái)訪(fǎng)問(wèn)任何數(shù)據(jù)。完成這項(xiàng)操作需要共享的 “一切” 是什么?

組內(nèi)事件序列

首先，組內(nèi)事件序列對(duì)于解決不同組成員由于并發(fā)訪(fǎng)問(wèn)引起的潛在沖突至關(guān)重要。我們通常使用數(shù)據(jù)庫(kù)日志記錄序號(hào)來(lái)表示事件的順序。同時(shí)，日志記錄序號(hào)一般是由時(shí)間戳生成的。

因此，對(duì)組內(nèi)事件順序的要求等價(jià)于對(duì)全局定時(shí)器的需要。如果我們可以為組配備一個(gè)原子鐘，那就太棒了。然而，Milvus是一個(gè)開(kāi)源軟件項(xiàng)目，這意味著我們應(yīng)該依賴(lài)常用的資源。迄今為止，原子鐘仍然是大公司的首選。

我們?cè)贛ilvus 2.0數(shù)據(jù)庫(kù)集群中實(shí)現(xiàn)了時(shí)間同步組件。您可以在附錄中找到鏈接。

全局鎖

數(shù)據(jù)庫(kù)有一個(gè)鎖定機(jī)制來(lái)解決并發(fā)訪(fǎng)問(wèn)沖突，無(wú)論是樂(lè)觀鎖還是悲觀鎖。同樣，我們需要使用全局鎖定來(lái)解決不同組成員之間同時(shí)訪(fǎng)問(wèn)的沖突。

全局鎖定意味著不同的組成員必須相互交談以協(xié)商鎖定請(qǐng)求。 影響這個(gè)全局鎖定協(xié)商過(guò)程的效率主要有幾個(gè)重要的因素：

• 系統(tǒng)間連接的速度
• 需要參與協(xié)商過(guò)程的組成員數(shù)量
• 組內(nèi)發(fā)生沖突的頻率

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

這種硬件假設(shè)在現(xiàn)代云環(huán)境中發(fā)生了巨大變化?，F(xiàn)如今，云數(shù)據(jù)中心都是由高密度服務(wù)器機(jī)房組成，集群配置了(數(shù)千臺(tái)) TCP/IP 網(wǎng)絡(luò)連通的商用 X86 服務(wù)器。如果我們依靠這些 X86 服務(wù)器來(lái)構(gòu)建數(shù)據(jù)庫(kù)集群，那么組大小應(yīng)該會(huì)增加到數(shù)百(甚至數(shù)千)臺(tái)機(jī)器。而在一些業(yè)務(wù)場(chǎng)景中，我們希望這數(shù)百臺(tái)X86機(jī)器分布在不同的區(qū)域。因此實(shí)現(xiàn)全局鎖定的價(jià)值和意義就不大了，因?yàn)槿宙i定性能不夠好。

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

另一方面，向量數(shù)據(jù)處理比結(jié)構(gòu)化數(shù)據(jù)處理消耗更多的內(nèi)存占用。 人們一直在尋找具有高擴(kuò)展性的向量數(shù)據(jù)庫(kù)。

共享內(nèi)存數(shù)據(jù)緩存

我們可以簡(jiǎn)單地將數(shù)據(jù)庫(kù)引擎分為兩部分，即存儲(chǔ)引擎和計(jì)算引擎。存儲(chǔ)引擎負(fù)責(zé)兩項(xiàng)關(guān)鍵任務(wù)：

• 將數(shù)據(jù)寫(xiě)入持久化存儲(chǔ)永久存儲(chǔ)。
• 將數(shù)據(jù)從持久化存儲(chǔ)加載到內(nèi)存數(shù)據(jù)緩存(AKA緩沖池);這是計(jì)算引擎訪(fǎng)問(wèn)數(shù)據(jù)的唯一地方。

在數(shù)據(jù)庫(kù)集群場(chǎng)景中，如果成員A更新了成員B中緩存的數(shù)據(jù)怎么辦?成員B如何知道其內(nèi)存數(shù)據(jù)已過(guò)期?對(duì)于經(jīng)典的 shared-everything集群，有一種緩沖區(qū)交叉失效機(jī)制來(lái)解決這個(gè)問(wèn)題。 如果我們?cè)诮M成員之間維持強(qiáng)一致性，則緩沖區(qū)交叉失效機(jī)制將類(lèi)似于全局鎖。如上所述，它在現(xiàn)有的云環(huán)境中并不實(shí)用。所以我們決定將Milvus彈性云分組的一致性級(jí)別降低為最終一致性的方式。這樣，Milvus 2.0中的緩沖區(qū)交叉失效機(jī)制就可以是一個(gè)異步過(guò)程。

共享存儲(chǔ)

共享存儲(chǔ)可能是人們?cè)谟懻摂?shù)據(jù)庫(kù)集群時(shí)會(huì)想到的第一件事。

近年來(lái)，隨著云存儲(chǔ)的發(fā)展，存儲(chǔ)可選項(xiàng)也發(fā)生了顯著的變化。 存儲(chǔ)連接網(wǎng)絡(luò) (SAN) 一直是shared-everything的存儲(chǔ)基礎(chǔ)。但是在云環(huán)境中并沒(méi)有SAN，數(shù)據(jù)庫(kù)必須使用本地磁盤(pán)連接到云虛擬機(jī)。使用本地磁盤(pán)對(duì)于跨組成員的數(shù)據(jù)一致性帶來(lái)了新的挑戰(zhàn)，而且我們還不得不考慮組成員的高可用。

Snowflake數(shù)據(jù)倉(cāng)庫(kù)為打算使用云共享存儲(chǔ)(S3存儲(chǔ))的云數(shù)據(jù)庫(kù)樹(shù)立了一個(gè)很好的榜樣，它也啟發(fā)了Milvus 2.0。如上所述，我們打算基于成熟的云基礎(chǔ)設(shè)施實(shí)現(xiàn)Milvus 2.0，但在我們能夠利用云共享存儲(chǔ)之前，我們必須考慮以下問(wèn)題。

首先，S3存儲(chǔ)便宜且可靠，但它不是為像數(shù)據(jù)庫(kù)那樣的實(shí)時(shí)讀寫(xiě)的場(chǎng)景而設(shè)計(jì)的。我們需要?jiǎng)?chuàng)建數(shù)據(jù)組件(我們?cè)贛ilvus 2.0中稱(chēng)為數(shù)據(jù)節(jié)點(diǎn))來(lái)橋接本地內(nèi)存/磁盤(pán)和S3存儲(chǔ)。市面上有一些示例可以參考，如Alluxio、JuiceFS等。無(wú)法直接集成這些項(xiàng)目的原因是我們考慮到不同的數(shù)據(jù)粒度。Alluxio和JuiceFS是為數(shù)據(jù)集或POSIX文件設(shè)計(jì)的，而我們專(zhuān)注于數(shù)據(jù)記錄(向量)級(jí)別。

當(dāng)向量數(shù)據(jù)在S3存儲(chǔ)的問(wèn)題被解決時(shí)，元數(shù)據(jù)的存儲(chǔ)很簡(jiǎn)單：將它們存儲(chǔ)在etcd。那么日志數(shù)據(jù)呢?在傳統(tǒng)的實(shí)現(xiàn)中，日志存儲(chǔ)也是基于SAN。一個(gè)數(shù)據(jù)庫(kù)組成員的日志文件在數(shù)據(jù)庫(kù)集群內(nèi)共享，用于故障恢復(fù)。在進(jìn)入云環(huán)境之前這不是問(wèn)題。

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

共識(shí)算法的重做日志(redo log)復(fù)制是一種強(qiáng)大的工具，在某些業(yè)務(wù)場(chǎng)景中具有相當(dāng)大的優(yōu)勢(shì)。但是，對(duì)于Milvus向量數(shù)據(jù)庫(kù)，我們沒(méi)有找到足夠的措施創(chuàng)建一個(gè)完整的狀態(tài)機(jī)復(fù)制組。我們決定使用云消息隊(duì)列/平臺(tái)(Apache Pulsar、Apache Kafka等)用于日志存儲(chǔ)，作為共享云存儲(chǔ)的替代品。通過(guò)將日志存儲(chǔ)委托給消息傳遞平臺(tái)，我們獲得了以下好處：

• 更加的事件驅(qū)動(dòng)化，整個(gè)處理過(guò)程可以是異步的，從而提高了可擴(kuò)展性。
• 組件耦合更松散，使得在線(xiàn)滾動(dòng)升級(jí)和發(fā)布更容易，可用性和可操作性顯著提高。

我們將在后面的部分重新討論這個(gè)話(huà)題。

到目前為止，我們已經(jīng)總結(jié)了設(shè)計(jì)一款數(shù)據(jù)庫(kù)集群要考慮的關(guān)鍵因素。在開(kāi)始討論Milvus 2.0架構(gòu)之前，讓我先說(shuō)明一下我們是如何在Milvus中管理向量的。

數(shù)據(jù)管理和性能可預(yù)測(cè)性

Milvus將向量存儲(chǔ)在集合中?！凹稀笔且粋€(gè)邏輯概念，相當(dāng)于SQL數(shù)據(jù)庫(kù)中的“表”。一個(gè)“集合”可以有多個(gè)物理文件來(lái)保存向量，一個(gè)物理文件是一個(gè)“段”?！岸巍笔且粋€(gè)物理概念，類(lèi)似于SQL數(shù)據(jù)庫(kù)中的表空間文件。當(dāng)數(shù)據(jù)量較小時(shí)，我們可以將所有內(nèi)容保存在單個(gè)段/物理文件中。但是，現(xiàn)如今不斷面臨著海量數(shù)據(jù)的存儲(chǔ)，當(dāng)有多個(gè)段/物理文件時(shí)，應(yīng)該如何將數(shù)據(jù)分散到不同的數(shù)據(jù)分區(qū)中?

盡管數(shù)據(jù)先于索引到來(lái)，但我們必須以更適合索引算法的方式存儲(chǔ)數(shù)據(jù)，以便在大多數(shù)情況下高效地訪(fǎng)問(wèn)數(shù)據(jù)。SQL數(shù)據(jù)庫(kù)中常用的策略是以分區(qū)鍵值的范圍進(jìn)行分區(qū)。通常情況下，就是創(chuàng)建一個(gè)聚集索引來(lái)強(qiáng)制分區(qū)鍵。這對(duì)于SQL數(shù)據(jù)庫(kù)來(lái)說(shuō)是一種不錯(cuò)的方法，一方面數(shù)據(jù)存儲(chǔ)良好，另一方面針對(duì) I/O(預(yù)取)進(jìn)行了優(yōu)化，但仍然存在以下缺陷：

• 數(shù)據(jù)傾斜：某些分區(qū)可能比其他分區(qū)存儲(chǔ)了更多的數(shù)據(jù)，實(shí)際應(yīng)用中數(shù)據(jù)的分布并不像數(shù)值范圍那么簡(jiǎn)單。
• 訪(fǎng)問(wèn)熱點(diǎn)：更多工作負(fù)載可能會(huì)流向其中幾個(gè)數(shù)據(jù)分區(qū)。

當(dāng)越來(lái)越多的工作負(fù)載流向數(shù)據(jù)傾斜度高的分區(qū)時(shí)，我們需要對(duì)各個(gè)分區(qū)的數(shù)據(jù)進(jìn)行重新平衡。

向量的聚集索引

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

在Milvus中，我們采用分區(qū)自動(dòng)增長(zhǎng)的策略。當(dāng)我們將數(shù)據(jù)存入向量集合時(shí)，Milvus會(huì)將新向量追加到集合中的最新段。一旦這個(gè)段的大小達(dá)到某個(gè)閾值(閾值可配置)，Milvus將關(guān)閉該段并為關(guān)閉的段建立索引。同時(shí)，它還將創(chuàng)建一個(gè)新段來(lái)存儲(chǔ)新的數(shù)據(jù)。這種簡(jiǎn)單的策略對(duì)于向量處理來(lái)說(shuō)平衡性更友好。

向量查詢(xún)指的是在向量集合中查詢(xún)與目標(biāo)條件匹配度最相近的結(jié)果。它是一個(gè)典型的Map Reduce過(guò)程。例如，如果想從包含10個(gè)分段的向量集合中搜索前20個(gè)相似的結(jié)果，我們可以搜索每個(gè)段的前20個(gè)，然后將20 * 10個(gè)查詢(xún)合并，篩選出其中20個(gè)結(jié)果返回。 由于每個(gè)段具有相同數(shù)量的向量和相似的索引，因此每個(gè)段的處理時(shí)間幾乎相同。這樣的好處是帶來(lái)了性能可預(yù)測(cè)性的優(yōu)勢(shì)，它在規(guī)劃數(shù)據(jù)庫(kù)集群的規(guī)模時(shí)至關(guān)重要。

Milvus 2.0的新范式

在Milvus 1.0中，我們實(shí)現(xiàn)了與大多數(shù)SQL數(shù)據(jù)庫(kù)一樣的讀寫(xiě)分離分片組。這種實(shí)現(xiàn)對(duì)Milvus數(shù)據(jù)庫(kù)集群來(lái)說(shuō)是種不錯(cuò)的嘗試，但帶來(lái)的問(wèn)題也是顯而易見(jiàn)的。

Milvus 1.0：分片集群

在Milvus 1.0中，寫(xiě)節(jié)點(diǎn)必須全程維護(hù)最新的段，其中就包括在未索引的段中追加向量、搜索向量，以及建立索引等操作。由于每個(gè)集合只有一個(gè)寫(xiě)節(jié)點(diǎn)，如果數(shù)據(jù)在源源不斷地寫(xiě)入系統(tǒng)，寫(xiě)入節(jié)點(diǎn)將會(huì)成為瓶頸。寫(xiě)節(jié)點(diǎn)和其他讀節(jié)點(diǎn)之間的數(shù)據(jù)共享性能也是一個(gè)問(wèn)題。此外，我們必須依賴(lài) NFS(不穩(wěn)定)或者商用云存儲(chǔ)(太貴)來(lái)作為共享數(shù)據(jù)存儲(chǔ)。

以上問(wèn)題在Milvus 1.0架構(gòu)中很難解決。 因此，我們?cè)贛ilvus 2.0設(shè)計(jì)中引入了新的范式。

Milvus 2.0：彈性云向量數(shù)據(jù)庫(kù)

Actor模型

現(xiàn)在有兩種常用的并發(fā)計(jì)算的模型編程。

• 共享內(nèi)存：對(duì)應(yīng)的是并發(fā)控制(鎖定)和同步處理。
• Actor模型(AKA 消息傳遞)：對(duì)應(yīng)的是消息驅(qū)動(dòng)和異步處理。

我們也可以在分布式數(shù)據(jù)庫(kù)集群中應(yīng)用這兩種模型。

近年來(lái)，基于Redo-log復(fù)制的算法一直是最被高估的數(shù)據(jù)庫(kù)技術(shù),它存在兩個(gè)關(guān)鍵問(wèn)題。

• Redo-log復(fù)制更好的假設(shè)是脆弱的。
• 供應(yīng)商誤導(dǎo)了人們對(duì)共識(shí)算法能力的期望。

假設(shè)我們有兩個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)，一個(gè)是主節(jié)點(diǎn)，另一個(gè)是從節(jié)點(diǎn)。 從一開(kāi)始，兩個(gè)節(jié)點(diǎn)的數(shù)據(jù)是完全一致的。我們?cè)谥鞴?jié)點(diǎn)上有一些修改操作(新增/更新/刪除的SQL語(yǔ)句)，我們希望保持從節(jié)點(diǎn)同步更新。我們應(yīng)該做什么?最簡(jiǎn)單的方法是在從節(jié)點(diǎn)上重放更新操作，但這不是最高效的手段。

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

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

部分供應(yīng)商總是聲稱(chēng)共識(shí)算法可以為數(shù)據(jù)庫(kù)集群提供強(qiáng)一致性。雖然redo-log記錄在不同節(jié)點(diǎn)上是一致的，但這并等價(jià)于數(shù)據(jù)視圖也是一致的。沒(méi)有將redo-log記錄合并到數(shù)據(jù)庫(kù)表之前，即使使用這種同步處理，我們也只能在數(shù)據(jù)上保證最終一致性。

我們應(yīng)該在合適的場(chǎng)景下使用redo-log復(fù)制一致性算法。 Milvus 2.0中使用的元數(shù)據(jù)系統(tǒng)(etcd)和消息中間件平臺(tái)(例如 Apache Pulsar)已經(jīng)實(shí)現(xiàn)了一致性算法。但正如我之前所說(shuō)的，“對(duì)于Milvus向量數(shù)據(jù)庫(kù)，目前還沒(méi)有辦法讓它成為一個(gè)完整的狀態(tài)機(jī)復(fù)制組。

在Milvus 2.0中，我們使用Actor模型來(lái)編排工作節(jié)點(diǎn)。工作節(jié)點(diǎn)是單獨(dú)隔離的，它們只與消息中間件平臺(tái)通信，獲取命令并發(fā)送結(jié)果。

Actor模型是異步的，它適用于對(duì)擴(kuò)展性和可用性要求高的場(chǎng)景。由于工作節(jié)點(diǎn)之間是互相隔離的，加入或移除部分工作節(jié)點(diǎn)對(duì)其他工作節(jié)點(diǎn)沒(méi)有影響。

可用性和持久性的分離

在 Milvus 2.0 中，我們實(shí)現(xiàn)的是操作重放而不是日志重放。因?yàn)樵谙蛄繑?shù)據(jù)庫(kù)中，操作重放和日志重放沒(méi)有太大區(qū)別。我們沒(méi)有更新功能，也沒(méi)有查詢(xún)插入功能，并且使用Actor模型進(jìn)行操作回放要簡(jiǎn)單得多。

多個(gè)工作節(jié)點(diǎn)可能會(huì)根據(jù)各自的職責(zé)從消息中間件平臺(tái)執(zhí)行相同的操作。之前提到我們決定使用S3云存儲(chǔ)作為Milvus數(shù)據(jù)庫(kù)集群的共享存儲(chǔ)層。S3存儲(chǔ)非常可靠，那么不同的工作節(jié)點(diǎn)是否需要將相同的數(shù)據(jù)寫(xiě)入共享存儲(chǔ)呢?

因此，我們把工作節(jié)點(diǎn)分類(lèi)為以下三個(gè)角色：

• 查詢(xún)節(jié)點(diǎn)：它維護(hù)一個(gè)內(nèi)存數(shù)據(jù)視圖。查詢(xún)節(jié)點(diǎn)的工作包括提供向量搜索和對(duì)內(nèi)存中數(shù)據(jù)的更新。但它不需要向S3存儲(chǔ)寫(xiě)入任何內(nèi)容。它是組中對(duì)內(nèi)存最敏感的節(jié)點(diǎn)。
• 數(shù)據(jù)節(jié)點(diǎn)：負(fù)責(zé)將新數(shù)據(jù)寫(xiě)入S3存儲(chǔ)。數(shù)據(jù)節(jié)點(diǎn)不需要維護(hù)內(nèi)存中的數(shù)據(jù)視圖，因此數(shù)據(jù)節(jié)點(diǎn)的硬件配置與查詢(xún)節(jié)點(diǎn)有很大的不同。
• 索引節(jié)點(diǎn)：當(dāng)段的大小達(dá)到閾值時(shí)，索引節(jié)點(diǎn)為數(shù)據(jù)節(jié)點(diǎn)已關(guān)閉的段建立索引。這是該組中對(duì)CPU密集性要求最高的節(jié)點(diǎn)。

這三種類(lèi)型的節(jié)點(diǎn)分擔(dān)了不同類(lèi)型的工作負(fù)載。它們可以獨(dú)立擴(kuò)展。這里的可用性和持久性分離是從微軟Socrates云數(shù)據(jù)庫(kù)中學(xué)習(xí)衍生而來(lái)的。

總結(jié)和展望

本文回顧了Milvus向量數(shù)據(jù)庫(kù)2.0版本的幾個(gè)設(shè)計(jì)決策。讓我們?cè)谶@里快速總結(jié)一下這些要點(diǎn)。

• Milvus集群2.0版本選擇了最終一致性。
• 我們盡可能將成熟的云組件集成到Milvus 2.0中，并控制了因適用Milvus 2.0引入到用戶(hù)生產(chǎn)環(huán)境中的新組件。
• Milvus 2.0遵循Actor模型，對(duì)可用性和持久性實(shí)現(xiàn)了分離，在云環(huán)境中易于擴(kuò)展。

到目前為止，Milvus 2.0彈性云數(shù)據(jù)庫(kù)的骨架已經(jīng)定型，目前還有許多來(lái)自Milvus社區(qū)的需求需要滿(mǎn)足。如果您有相同的使命(“構(gòu)建更多開(kāi)源基礎(chǔ)設(shè)施軟件，加速AI轉(zhuǎn)型”)，歡迎加入Milvus社區(qū)。

Milvus是LF AI & Data基金會(huì)的孵化的項(xiàng)目。你無(wú)需為Milvus 簽署任何CLA!

附錄

Milvus設(shè)計(jì)文檔

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

Raft的C++實(shí)現(xiàn)

如果你對(duì)共識(shí)算法感興趣，建議你查看eBay的開(kāi)源項(xiàng)目 Gringofts。它是Raft共識(shí)算法(Paxos系列的一個(gè)變體)的C++實(shí)現(xiàn)。它是我的朋友Jacky和Elvis(我在摩根士丹利的前同事)為eBay 在線(xiàn)支付系統(tǒng)構(gòu)建的，這也正是它最適合的場(chǎng)景之一。

譯者介紹

陳林，51CTO社區(qū)編輯，某零售銀行龍頭DevOps持續(xù)集成平臺(tái)技術(shù)負(fù)責(zé)人，主導(dǎo)核心業(yè)務(wù)方案設(shè)計(jì)落地，推動(dòng)產(chǎn)品架構(gòu)持續(xù)演進(jìn)。負(fù)責(zé)安全工具接入、掃描中臺(tái)建設(shè)、構(gòu)建加速、SCM性能優(yōu)化、鏡像治理等模塊。參與微服務(wù)治理、多活構(gòu)建調(diào)度架構(gòu)、異構(gòu)存儲(chǔ)集群集成、緩存和分布式限流等架構(gòu)優(yōu)化。熱愛(ài)開(kāi)源技術(shù)和寫(xiě)文章，追求技術(shù)廣度和領(lǐng)域深度。

原文標(biāo)題：Evolution of Milvus Cloud-Scalable Vector Database，作者：Jun Gu