建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 陳林
審校 | 孫淑娟 梁策
Milvus向量型數(shù)據(jù)庫的目標(biāo)
當(dāng)我們第一次出現(xiàn)Milvus向量型數(shù)據(jù)庫的想法時(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ù)開發(fā)人員對于高速發(fā)展的AI技術(shù)和工具并不熟悉。開發(fā)人員花費(fèi)了大量的精力來尋找、訓(xùn)練和調(diào)整模型，基本沒有額外的精力來處理模型生成的大量嵌入向量，更不用說處理海量數(shù)據(jù)一直都是一項(xiàng)相當(dāng)有挑戰(zhàn)的任務(wù)。
因此，我們給“易用性”定了相當(dāng)高的優(yōu)先級，因?yàn)樗梢燥@著地降低開發(fā)成本。
低運(yùn)行成本
- AI投入實(shí)際生產(chǎn)應(yīng)用的最大阻礙之一就是合理衡量投資回報(bào)比。有了更低的運(yùn)行成本，我們將AI應(yīng)用程序投入生產(chǎn)中將有更大的可能性，這將有利于提高邊際的潛在收益。
Milvus 2.0的設(shè)計(jì)原則
我們在 Milvus 1.0 中朝著這些目標(biāo)邁出了第一步，但這還遠(yuǎn)遠(yuǎn)不夠，尤其是在可擴(kuò)展性和可用性方面。然后我們開始研發(fā)Milvus 2.0來完善這些點(diǎn)。我們?yōu)?.0新版本制定的原則包括：
- 以高可擴(kuò)展性和可用性為目標(biāo)
- 基于成熟的云基礎(chǔ)架構(gòu)和實(shí)踐
- 云端的最小性能妥協(xié)性
也就是說，我們想讓Milvus數(shù)據(jù)庫集群成為云原生。
Milvus數(shù)據(jù)庫集群的演進(jìn)
向量數(shù)據(jù)庫是一種新型數(shù)據(jù)庫，因?yàn)樗幚淼南蛄繑?shù)據(jù)是一種新的數(shù)據(jù)類型。它面臨與其他數(shù)據(jù)庫相同的挑戰(zhàn)，但也具有自身的一些場景和需求。在本文剩下的部分，我將重點(diǎn)介紹我們從現(xiàn)有的數(shù)據(jù)庫集群實(shí)現(xiàn)中能學(xué)到什么，以及我們在設(shè)計(jì)新的Milvus Group架構(gòu)時(shí)的思考旅程。
如果你對Milvus Group組件的實(shí)現(xiàn)細(xì)節(jié)感興趣，請繼續(xù)關(guān)注 Milvus文檔。我們將在Milvus GitHub倉庫、Milvus官網(wǎng)和Milvus博客上持續(xù)發(fā)布技術(shù)文章。
理想的數(shù)據(jù)庫集群
讓我們首先羅列出一個(gè)理想的數(shù)據(jù)庫集群應(yīng)該具備的關(guān)鍵能力。
- 支持并發(fā)且無單點(diǎn)故障：連接到不同組成員的用戶可以同時(shí)對同一條數(shù)據(jù)進(jìn)行讀/寫訪問。
- 一致性：不同的組成員看到的數(shù)據(jù)應(yīng)該是相同的。
- 可擴(kuò)展性：我們可以隨時(shí)隨地添加或刪除組成員。
說實(shí)在的，現(xiàn)有數(shù)據(jù)庫是無法同時(shí)提供和保障這些能力的。在現(xiàn)代數(shù)據(jù)庫集群的實(shí)現(xiàn)中，人們不得不對其中的部分功能妥協(xié)。我們并不期望一個(gè)完美的數(shù)據(jù)庫集群，只要能夠適用和滿足用戶的業(yè)務(wù)場景就行了。然而，共享 “一切” 的集群一度非常接近理想的數(shù)據(jù)庫集群。如果我們想學(xué)習(xí)一些經(jīng)驗(yàn)，我們應(yīng)該以它為基礎(chǔ)開始。
數(shù)據(jù)庫集群的主要考慮因素
與其他數(shù)據(jù)庫實(shí)現(xiàn)相比，shared-everything的數(shù)據(jù)庫集群具有更久遠(yuǎn)的歷史。DB2數(shù)據(jù)共享組和Oracle RAC是典型的shared-everything集群。許多人認(rèn)為shared-everything意味著共享磁盤，其實(shí)遠(yuǎn)不止于此。
shared-everything的數(shù)據(jù)庫集群在組中只有一種數(shù)據(jù)庫成員。用戶可以連接到這些對等成員中的任何一個(gè)實(shí)例來訪問任何數(shù)據(jù)。完成這項(xiàng)操作需要共享的 “一切” 是什么?
組內(nèi)事件序列
首先，組內(nèi)事件序列對于解決不同組成員由于并發(fā)訪問引起的潛在沖突至關(guān)重要。我們通常使用數(shù)據(jù)庫日志記錄序號來表示事件的順序。同時(shí)，日志記錄序號一般是由時(shí)間戳生成的。
因此，對組內(nèi)事件順序的要求等價(jià)于對全局定時(shí)器的需要。如果我們可以為組配備一個(gè)原子鐘，那就太棒了。然而，Milvus是一個(gè)開源軟件項(xiàng)目，這意味著我們應(yīng)該依賴常用的資源。迄今為止，原子鐘仍然是大公司的首選。
我們在Milvus 2.0數(shù)據(jù)庫集群中實(shí)現(xiàn)了時(shí)間同步組件。您可以在附錄中找到鏈接。
全局鎖
數(shù)據(jù)庫有一個(gè)鎖定機(jī)制來解決并發(fā)訪問沖突，無論是樂觀鎖還是悲觀鎖。同樣，我們需要使用全局鎖定來解決不同組成員之間同時(shí)訪問的沖突。
全局鎖定意味著不同的組成員必須相互交談以協(xié)商鎖定請求。 影響這個(gè)全局鎖定協(xié)商過程的效率主要有幾個(gè)重要的因素：
- 系統(tǒng)間連接的速度
- 需要參與協(xié)商過程的組成員數(shù)量
- 組內(nèi)發(fā)生沖突的頻率
通常的組大小不超過100。例如，DB2 DSG為32;Oracle RAC為100。這些組成員將被放置在一個(gè)通過光纖連接的服務(wù)器機(jī)房中，以最大限度地減少傳輸延遲。這就是為什么它有時(shí)被稱為集中式集群。 由于組大小的限制，人們會選擇高端服務(wù)器(大型機(jī)或小型機(jī)，在 CPU、內(nèi)存、I/O 通道等方面具有更多容量)來組成共享一切集群。
這種硬件假設(shè)在現(xiàn)代云環(huán)境中發(fā)生了巨大變化?，F(xiàn)如今，云數(shù)據(jù)中心都是由高密度服務(wù)器機(jī)房組成，集群配置了(數(shù)千臺) TCP/IP 網(wǎng)絡(luò)連通的商用 X86 服務(wù)器。如果我們依靠這些 X86 服務(wù)器來構(gòu)建數(shù)據(jù)庫集群，那么組大小應(yīng)該會增加到數(shù)百(甚至數(shù)千)臺機(jī)器。而在一些業(yè)務(wù)場景中，我們希望這數(shù)百臺X86機(jī)器分布在不同的區(qū)域。因此實(shí)現(xiàn)全局鎖定的價(jià)值和意義就不大了，因?yàn)槿宙i定性能不夠好。
在Milvus 2.0中，我們不會實(shí)現(xiàn)全局鎖定功能。一方面，向量數(shù)據(jù)不會有更新(用戶傾向于刪除后插入而不是更新)。所以我們不需要擔(dān)心基于分片編排的Milvus組內(nèi)的同一條數(shù)據(jù)的由于多次寫入造成沖突。同時(shí)，我們可以使用MVCC(多版本并發(fā)控制，一種避免鎖的并發(fā)控制方法)來解決讀寫沖突。
另一方面，向量數(shù)據(jù)處理比結(jié)構(gòu)化數(shù)據(jù)處理消耗更多的內(nèi)存占用。 人們一直在尋找具有高擴(kuò)展性的向量數(shù)據(jù)庫。
共享內(nèi)存數(shù)據(jù)緩存
我們可以簡單地將數(shù)據(jù)庫引擎分為兩部分，即存儲引擎和計(jì)算引擎。存儲引擎負(fù)責(zé)兩項(xiàng)關(guān)鍵任務(wù)：
- 將數(shù)據(jù)寫入持久化存儲永久存儲。
- 將數(shù)據(jù)從持久化存儲加載到內(nèi)存數(shù)據(jù)緩存(AKA緩沖池);這是計(jì)算引擎訪問數(shù)據(jù)的唯一地方。
在數(shù)據(jù)庫集群場景中，如果成員A更新了成員B中緩存的數(shù)據(jù)怎么辦?成員B如何知道其內(nèi)存數(shù)據(jù)已過期?對于經(jīng)典的 shared-everything集群，有一種緩沖區(qū)交叉失效機(jī)制來解決這個(gè)問題。 如果我們在組成員之間維持強(qiáng)一致性，則緩沖區(qū)交叉失效機(jī)制將類似于全局鎖。如上所述，它在現(xiàn)有的云環(huán)境中并不實(shí)用。所以我們決定將Milvus彈性云分組的一致性級別降低為最終一致性的方式。這樣，Milvus 2.0中的緩沖區(qū)交叉失效機(jī)制就可以是一個(gè)異步過程。
共享存儲
共享存儲可能是人們在討論數(shù)據(jù)庫集群時(shí)會想到的第一件事。
近年來，隨著云存儲的發(fā)展，存儲可選項(xiàng)也發(fā)生了顯著的變化。 存儲連接網(wǎng)絡(luò) (SAN) 一直是shared-everything的存儲基礎(chǔ)。但是在云環(huán)境中并沒有SAN，數(shù)據(jù)庫必須使用本地磁盤連接到云虛擬機(jī)。使用本地磁盤對于跨組成員的數(shù)據(jù)一致性帶來了新的挑戰(zhàn)，而且我們還不得不考慮組成員的高可用。
Snowflake數(shù)據(jù)倉庫為打算使用云共享存儲(S3存儲)的云數(shù)據(jù)庫樹立了一個(gè)很好的榜樣，它也啟發(fā)了Milvus 2.0。如上所述，我們打算基于成熟的云基礎(chǔ)設(shè)施實(shí)現(xiàn)Milvus 2.0，但在我們能夠利用云共享存儲之前，我們必須考慮以下問題。
首先，S3存儲便宜且可靠，但它不是為像數(shù)據(jù)庫那樣的實(shí)時(shí)讀寫的場景而設(shè)計(jì)的。我們需要?jiǎng)?chuàng)建數(shù)據(jù)組件(我們在Milvus 2.0中稱為數(shù)據(jù)節(jié)點(diǎn))來橋接本地內(nèi)存/磁盤和S3存儲。市面上有一些示例可以參考，如Alluxio、JuiceFS等。無法直接集成這些項(xiàng)目的原因是我們考慮到不同的數(shù)據(jù)粒度。Alluxio和JuiceFS是為數(shù)據(jù)集或POSIX文件設(shè)計(jì)的，而我們專注于數(shù)據(jù)記錄(向量)級別。
當(dāng)向量數(shù)據(jù)在S3存儲的問題被解決時(shí)，元數(shù)據(jù)的存儲很簡單：將它們存儲在etcd。那么日志數(shù)據(jù)呢?在傳統(tǒng)的實(shí)現(xiàn)中，日志存儲也是基于SAN。一個(gè)數(shù)據(jù)庫組成員的日志文件在數(shù)據(jù)庫集群內(nèi)共享，用于故障恢復(fù)。在進(jìn)入云環(huán)境之前這不是問題。
在Spanner論文中，Google展示了他們是如何使用Paxos共識算法實(shí)現(xiàn)全局分布式數(shù)據(jù)庫(組)的。你需要基于狀態(tài)機(jī)復(fù)制組實(shí)現(xiàn)數(shù)據(jù)庫集群，重做日志(redo log)通常就是用于整個(gè)組復(fù)制的那個(gè)“狀態(tài)”。
共識算法的重做日志(redo log)復(fù)制是一種強(qiáng)大的工具，在某些業(yè)務(wù)場景中具有相當(dāng)大的優(yōu)勢。但是，對于Milvus向量數(shù)據(jù)庫，我們沒有找到足夠的措施創(chuàng)建一個(gè)完整的狀態(tài)機(jī)復(fù)制組。我們決定使用云消息隊(duì)列/平臺(Apache Pulsar、Apache Kafka等)用于日志存儲，作為共享云存儲的替代品。通過將日志存儲委托給消息傳遞平臺，我們獲得了以下好處：
- 更加的事件驅(qū)動化，整個(gè)處理過程可以是異步的，從而提高了可擴(kuò)展性。
- 組件耦合更松散，使得在線滾動升級和發(fā)布更容易，可用性和可操作性顯著提高。
我們將在后面的部分重新討論這個(gè)話題。
到目前為止，我們已經(jīng)總結(jié)了設(shè)計(jì)一款數(shù)據(jù)庫集群要考慮的關(guān)鍵因素。在開始討論Milvus 2.0架構(gòu)之前，讓我先說明一下我們是如何在Milvus中管理向量的。
數(shù)據(jù)管理和性能可預(yù)測性
Milvus將向量存儲在集合中?！凹稀笔且粋€(gè)邏輯概念，相當(dāng)于SQL數(shù)據(jù)庫中的“表”。一個(gè)“集合”可以有多個(gè)物理文件來保存向量，一個(gè)物理文件是一個(gè)“段”?！岸巍笔且粋€(gè)物理概念，類似于SQL數(shù)據(jù)庫中的表空間文件。當(dāng)數(shù)據(jù)量較小時(shí)，我們可以將所有內(nèi)容保存在單個(gè)段/物理文件中。但是，現(xiàn)如今不斷面臨著海量數(shù)據(jù)的存儲，當(dāng)有多個(gè)段/物理文件時(shí)，應(yīng)該如何將數(shù)據(jù)分散到不同的數(shù)據(jù)分區(qū)中?
盡管數(shù)據(jù)先于索引到來，但我們必須以更適合索引算法的方式存儲數(shù)據(jù)，以便在大多數(shù)情況下高效地訪問數(shù)據(jù)。SQL數(shù)據(jù)庫中常用的策略是以分區(qū)鍵值的范圍進(jìn)行分區(qū)。通常情況下，就是創(chuàng)建一個(gè)聚集索引來強(qiáng)制分區(qū)鍵。這對于SQL數(shù)據(jù)庫來說是一種不錯(cuò)的方法，一方面數(shù)據(jù)存儲良好，另一方面針對 I/O(預(yù)取)進(jìn)行了優(yōu)化，但仍然存在以下缺陷：
- 數(shù)據(jù)傾斜：某些分區(qū)可能比其他分區(qū)存儲了更多的數(shù)據(jù)，實(shí)際應(yīng)用中數(shù)據(jù)的分布并不像數(shù)值范圍那么簡單。
- 訪問熱點(diǎn)：更多工作負(fù)載可能會流向其中幾個(gè)數(shù)據(jù)分區(qū)。
當(dāng)越來越多的工作負(fù)載流向數(shù)據(jù)傾斜度高的分區(qū)時(shí)，我們需要對各個(gè)分區(qū)的數(shù)據(jù)進(jìn)行重新平衡。
向量的聚集索引
我們還可以為向量創(chuàng)建聚集索引(倒排列表索引)，這與SQL 數(shù)據(jù)庫的索引不同。給SQL數(shù)據(jù)庫建立索引后，通過索引訪問數(shù)據(jù)非常高效，計(jì)算量少，I/O操作少。然而對于向量數(shù)據(jù)來說，即使有索引，計(jì)算和I/O操作也不會因此減少。因此，在向量數(shù)據(jù)庫集群中，數(shù)據(jù)傾斜和熱點(diǎn)數(shù)據(jù)集中的影響更為明顯。此外，由于數(shù)據(jù)量和計(jì)算復(fù)雜性因素，在不同分段對向量進(jìn)行重新平衡的成本非常高。
在Milvus中，我們采用分區(qū)自動增長的策略。當(dāng)我們將數(shù)據(jù)存入向量集合時(shí)，Milvus會將新向量追加到集合中的最新段。一旦這個(gè)段的大小達(dá)到某個(gè)閾值(閾值可配置)，Milvus將關(guān)閉該段并為關(guān)閉的段建立索引。同時(shí)，它還將創(chuàng)建一個(gè)新段來存儲新的數(shù)據(jù)。這種簡單的策略對于向量處理來說平衡性更友好。
向量查詢指的是在向量集合中查詢與目標(biāo)條件匹配度最相近的結(jié)果。它是一個(gè)典型的Map Reduce過程。例如，如果想從包含10個(gè)分段的向量集合中搜索前20個(gè)相似的結(jié)果，我們可以搜索每個(gè)段的前20個(gè)，然后將20 * 10個(gè)查詢合并，篩選出其中20個(gè)結(jié)果返回。 由于每個(gè)段具有相同數(shù)量的向量和相似的索引，因此每個(gè)段的處理時(shí)間幾乎相同。這樣的好處是帶來了性能可預(yù)測性的優(yōu)勢，它在規(guī)劃數(shù)據(jù)庫集群的規(guī)模時(shí)至關(guān)重要。
Milvus 2.0的新范式
在Milvus 1.0中，我們實(shí)現(xiàn)了與大多數(shù)SQL數(shù)據(jù)庫一樣的讀寫分離分片組。這種實(shí)現(xiàn)對Milvus數(shù)據(jù)庫集群來說是種不錯(cuò)的嘗試，但帶來的問題也是顯而易見的。
Milvus 1.0：分片集群
在Milvus 1.0中，寫節(jié)點(diǎn)必須全程維護(hù)最新的段，其中就包括在未索引的段中追加向量、搜索向量，以及建立索引等操作。由于每個(gè)集合只有一個(gè)寫節(jié)點(diǎn)，如果數(shù)據(jù)在源源不斷地寫入系統(tǒng)，寫入節(jié)點(diǎn)將會成為瓶頸。寫節(jié)點(diǎn)和其他讀節(jié)點(diǎn)之間的數(shù)據(jù)共享性能也是一個(gè)問題。此外，我們必須依賴 NFS(不穩(wěn)定)或者商用云存儲(太貴)來作為共享數(shù)據(jù)存儲。
以上問題在Milvus 1.0架構(gòu)中很難解決。 因此，我們在Milvus 2.0設(shè)計(jì)中引入了新的范式。
Milvus 2.0：彈性云向量數(shù)據(jù)庫
Actor模型
現(xiàn)在有兩種常用的并發(fā)計(jì)算的模型編程。
- 共享內(nèi)存：對應(yīng)的是并發(fā)控制(鎖定)和同步處理。
- Actor模型(AKA 消息傳遞)：對應(yīng)的是消息驅(qū)動和異步處理。
我們也可以在分布式數(shù)據(jù)庫集群中應(yīng)用這兩種模型。
近年來，基于Redo-log復(fù)制的算法一直是最被高估的數(shù)據(jù)庫技術(shù),它存在兩個(gè)關(guān)鍵問題。
- Redo-log復(fù)制更好的假設(shè)是脆弱的。
- 供應(yīng)商誤導(dǎo)了人們對共識算法能力的期望。
假設(shè)我們有兩個(gè)數(shù)據(jù)庫節(jié)點(diǎn)，一個(gè)是主節(jié)點(diǎn)，另一個(gè)是從節(jié)點(diǎn)。 從一開始，兩個(gè)節(jié)點(diǎn)的數(shù)據(jù)是完全一致的。我們在主節(jié)點(diǎn)上有一些修改操作(新增/更新/刪除的SQL語句)，我們希望保持從節(jié)點(diǎn)同步更新。我們應(yīng)該做什么?最簡單的方法是在從節(jié)點(diǎn)上重放更新操作，但這不是最高效的手段。
考慮新增/更新/刪除語句的運(yùn)行成本：我們可以將其分為執(zhí)行準(zhǔn)備和實(shí)際執(zhí)行部分。執(zhí)行準(zhǔn)備部分包括SQL解析器、SQL優(yōu)化器等工作，不管影響到了多少條數(shù)據(jù)記錄，成本都是固定的。實(shí)際執(zhí)行部分的成本取決于有多少數(shù)據(jù)記錄會受到影響，它的成本是浮動的。 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記錄?一百萬條記錄又怎么樣? redo-log復(fù)制最適合的場景是支付系統(tǒng)、元數(shù)據(jù)系統(tǒng)等。在這些場景中，每個(gè)數(shù)據(jù)庫新增/更新/刪除操作只影響少量的記錄(1或2)，它不適用于I/O密集型類的場景，例如任務(wù)批處理。
部分供應(yīng)商總是聲稱共識算法可以為數(shù)據(jù)庫集群提供強(qiáng)一致性。雖然redo-log記錄在不同節(jié)點(diǎn)上是一致的，但這并等價(jià)于數(shù)據(jù)視圖也是一致的。沒有將redo-log記錄合并到數(shù)據(jù)庫表之前，即使使用這種同步處理，我們也只能在數(shù)據(jù)上保證最終一致性。
我們應(yīng)該在合適的場景下使用redo-log復(fù)制一致性算法。 Milvus 2.0中使用的元數(shù)據(jù)系統(tǒng)(etcd)和消息中間件平臺(例如 Apache Pulsar)已經(jīng)實(shí)現(xiàn)了一致性算法。但正如我之前所說的，“對于Milvus向量數(shù)據(jù)庫，目前還沒有辦法讓它成為一個(gè)完整的狀態(tài)機(jī)復(fù)制組。
在Milvus 2.0中，我們使用Actor模型來編排工作節(jié)點(diǎn)。工作節(jié)點(diǎn)是單獨(dú)隔離的，它們只與消息中間件平臺通信，獲取命令并發(fā)送結(jié)果。
Actor模型是異步的，它適用于對擴(kuò)展性和可用性要求高的場景。由于工作節(jié)點(diǎn)之間是互相隔離的，加入或移除部分工作節(jié)點(diǎn)對其他工作節(jié)點(diǎn)沒有影響。
可用性和持久性的分離
在 Milvus 2.0 中，我們實(shí)現(xiàn)的是操作重放而不是日志重放。因?yàn)樵谙蛄繑?shù)據(jù)庫中，操作重放和日志重放沒有太大區(qū)別。我們沒有更新功能，也沒有查詢插入功能，并且使用Actor模型進(jìn)行操作回放要簡單得多。
多個(gè)工作節(jié)點(diǎn)可能會根據(jù)各自的職責(zé)從消息中間件平臺執(zhí)行相同的操作。之前提到我們決定使用S3云存儲作為Milvus數(shù)據(jù)庫集群的共享存儲層。S3存儲非?？煽浚敲床煌墓ぷ鞴?jié)點(diǎn)是否需要將相同的數(shù)據(jù)寫入共享存儲呢?
因此，我們把工作節(jié)點(diǎn)分類為以下三個(gè)角色：
- 查詢節(jié)點(diǎn)：它維護(hù)一個(gè)內(nèi)存數(shù)據(jù)視圖。查詢節(jié)點(diǎn)的工作包括提供向量搜索和對內(nèi)存中數(shù)據(jù)的更新。但它不需要向S3存儲寫入任何內(nèi)容。它是組中對內(nèi)存最敏感的節(jié)點(diǎn)。
- 數(shù)據(jù)節(jié)點(diǎn)：負(fù)責(zé)將新數(shù)據(jù)寫入S3存儲。數(shù)據(jù)節(jié)點(diǎn)不需要維護(hù)內(nèi)存中的數(shù)據(jù)視圖，因此數(shù)據(jù)節(jié)點(diǎn)的硬件配置與查詢節(jié)點(diǎn)有很大的不同。
- 索引節(jié)點(diǎn)：當(dāng)段的大小達(dá)到閾值時(shí)，索引節(jié)點(diǎn)為數(shù)據(jù)節(jié)點(diǎn)已關(guān)閉的段建立索引。這是該組中對CPU密集性要求最高的節(jié)點(diǎn)。
這三種類型的節(jié)點(diǎn)分擔(dān)了不同類型的工作負(fù)載。它們可以獨(dú)立擴(kuò)展。這里的可用性和持久性分離是從微軟Socrates云數(shù)據(jù)庫中學(xué)習(xí)衍生而來的。
總結(jié)和展望
本文回顧了Milvus向量數(shù)據(jù)庫2.0版本的幾個(gè)設(shè)計(jì)決策。讓我們在這里快速總結(jié)一下這些要點(diǎn)。
- Milvus集群2.0版本選擇了最終一致性。
- 我們盡可能將成熟的云組件集成到Milvus 2.0中，并控制了因適用Milvus 2.0引入到用戶生產(chǎn)環(huán)境中的新組件。
- Milvus 2.0遵循Actor模型，對可用性和持久性實(shí)現(xiàn)了分離，在云環(huán)境中易于擴(kuò)展。
到目前為止，Milvus 2.0彈性云數(shù)據(jù)庫的骨架已經(jīng)定型，目前還有許多來自Milvus社區(qū)的需求需要滿足。如果您有相同的使命(“構(gòu)建更多開源基礎(chǔ)設(shè)施軟件，加速AI轉(zhuǎn)型”)，歡迎加入Milvus社區(qū)。
Milvus是LF AI & Data基金會的孵化的項(xiàng)目。你無需為Milvus 簽署任何CLA!
附錄
Milvus設(shè)計(jì)文檔
??https://github.com/milvus-io/milvus/tree/master/docs/design_docs??
Raft的C++實(shí)現(xiàn)
如果你對共識算法感興趣，建議你查看eBay的開源項(xiàng)目 Gringofts。它是Raft共識算法(Paxos系列的一個(gè)變體)的C++實(shí)現(xiàn)。它是我的朋友Jacky和Elvis(我在摩根士丹利的前同事)為eBay 在線支付系統(tǒng)構(gòu)建的，這也正是它最適合的場景之一。
譯者介紹
陳林，社區(qū)編輯，某零售銀行龍頭DevOps持續(xù)集成平臺技術(shù)負(fù)責(zé)人，主導(dǎo)核心業(yè)務(wù)方案設(shè)計(jì)落地，推動產(chǎn)品架構(gòu)持續(xù)演進(jìn)。負(fù)責(zé)安全工具接入、掃描中臺建設(shè)、構(gòu)建加速、SCM性能優(yōu)化、鏡像治理等模塊。參與微服務(wù)治理、多活構(gòu)建調(diào)度架構(gòu)、異構(gòu)存儲集群集成、緩存和分布式限流等架構(gòu)優(yōu)化。熱愛開源技術(shù)和寫文章，追求技術(shù)廣度和領(lǐng)域深度。
原文標(biāo)題：Evolution of Milvus Cloud-Scalable Vector Database，作者：Jun Gu
網(wǎng)頁標(biāo)題：基于彈性云的向量型數(shù)據(jù)庫Milvus的演進(jìn)歷程
本文網(wǎng)址：http://m.fisionsoft.com.cn/article/dpocgsp.html
