• 關於 Milvus
  • 開始使用
  • 概念
  • 使用者指南
  • 資料匯入
  • AI 工具
  • 管理指南
  • 工具
  • 整合
  • 教學
  • 常見問題
  • API Reference

一致性

本主題介紹 Milvus 的四種一致性等級及其最適合的情況。本主題也涵蓋 Milvus 確保一致性背後的機制。

概述

分佈式資料庫的一致性特指確保每個節點或副本在特定時間寫入或讀取資料時擁有相同資料視圖的屬性。

Milvus 支援四個一致性層級:強、有界線僵化、會話和最終。Milvus 的預設一致性等級是有界的僵化。 在進行單向量搜尋混合搜尋或 查詢時,您可以輕鬆調整一致性層級,使其最適合您的應用程式。

一致性等級

根據PACELC理論的定義,分散式資料庫必須在一致性、可用性和延遲之間進行權衡。高一致性意味著高準確性,但也意味著高搜尋延遲,而低一致性會導致快速的搜尋速度,但卻會損失一定的資料可視性。因此,不同等級的一致性適用於不同的情況。

以下說明 Milvus 支援的四種一致性等級的差異,以及它們各自適合的情境。

強是最高和最嚴格的一致性等級。它確保使用者能讀取最新版本的資料。

Strong consistency 強一致性

根據 PACELC 理論,如果一致性等級設定為強,延遲會增加。因此,我們建議在功能測試時選擇強一致性,以確保測試結果的準確性。強一致性也最適合那些以搜尋速度為代價,但對資料一致性有嚴格要求的應用程式。例如,處理訂單付款和帳單的線上財務系統。

有限制的陳舊性

有界僵化,顧名思義,允許資料在某段時間內不一致。但是,一般而言,在該期間外的資料總是全局一致的。

Bounded staleness consistency 有界僵化一致性

有限制的不一致適用於需要控制搜尋延遲,並且可以接受零星資料不存在的情況。例如,在視訊推薦引擎等推薦系統中,資料不可見有時對整體召回率的影響較小,但卻能大幅提升推薦系統的效能。

會話

Session 可確保在同一會話中,所有資料寫入都能立即被讀取。換句話說,當您透過一個用戶端寫入資料時,新插入的資料會立即成為可搜尋資料。

Session consistency 會話一致性

我們建議在對同一會話中的資料一致性要求較高的情況下,選擇會話作為一致性層級。舉例來說,從圖書館系統中刪除某個書籍項目的資料,在確認刪除並重 新刷新頁面(不同的會話)後,搜尋結果中應不再顯示該書籍。

最終

讀取與寫入的順序並無保證,只要不再進行寫入作業,副本最終都會收斂到相同的狀態。在「最終」的一致性下,副本會以最新更新的值開始處理讀取要求。最終一致性是四種一致性中最弱的一種。

Eventual consistency 最終一致性

然而,根據 PACELC 理論,犧牲一致性可以大幅縮短搜尋延遲。因此,最終一致性最適合對資料一致性要求不高,但需要極快搜尋效能的情況。例如,使用最終一致的層級檢索 Amazon 產品的評論和評分。

保證時間戳

Milvus 透過引入保證時間戳(GuaranteeTs) 來實現不同的一致性等級。

GuaranteeTs 的作用是通知查詢節點,在查詢節點可以看到 GuaranteeTs 之前的所有資料之前,不會執行搜尋或查詢請求。當您指定一致性層級時,一致性層級會對應到特定的 GuaranteeTs 值。不同的 GuaranteeTs 值對應不同的一致性等級:

  • :GuaranteeTs 設定為與最新的系統時間戳完全相同,查詢節點要等到可以看到最新的系統時間戳之前的所有資料,才會處理搜尋或查詢請求。

  • 有限制的僵化:GuaranteeTs 設定為相對小於最新的系統時間戳,查詢節點在可容忍、更新較少的資料檢視上進行搜尋。

  • 會話:用戶端使用最新寫入操作的時間戳作為 GuaranteeTs,這樣每個用戶端至少可以檢索到同一用戶端插入的資料。

  • 最終:GuaranteeTs 設定為非常小的值,以跳過一致性檢查。查詢節點會立即在現有的資料檢視上進行搜尋。

請參閱GuaranteeTs 如何運作,以獲得更多關於在 Milvus 中確保不同層級一致性背後的機制的資訊。

下一步

免費嘗試托管的 Milvus

Zilliz Cloud 無縫接入,由 Milvus 提供動力,速度提升 10 倍。

開始使用
反饋

這個頁面有幫助嗎?