Home
Blog
停止為冷資料付費：Milvus 分層儲存中的隨選冷熱資料載入功能可降低 80% 的成本

停止為冷資料付費：Milvus 分層儲存中的隨選冷熱資料載入功能可降低 80% 的成本

Engineering

December 15, 2025

Buqian Zheng

有多少人仍在為系統幾乎不碰觸的資料支付高額基礎架構帳單？老實說，大多數團隊都是如此。

如果您在生產中執行向量搜尋，您可能已經親眼看到這種情況。您提供大量的記憶體和 SSD，讓一切都能「準備好查詢」，儘管您的資料集只有一小部分實際在使用中。您並不孤單。我們也見過很多類似的案例：

多租戶 SaaS 平台：數百個已加入的租戶，但只有 10-15% 在任何特定日子活躍。其餘的閒置，但仍佔用資源。
電子商務推薦系統：數百萬個 SKU，卻只有前 8% 的產品產生大部分的推薦與搜尋流量。
AI 搜尋：龐大的嵌入式檔案，儘管 90% 的使用者查詢都是針對過去一週的項目。

各行各業的情況都是一樣：只有少於 10% 的資料會被頻繁查詢，但卻往往消耗了 80% 的儲存空間和記憶體。每個人都知道這種不平衡現象的存在 - 但直到最近，仍沒有一個乾淨的架構方式來解決這個問題。

Milvus 2.6改變了這一情況。

在這個版本之前，Milvus (就像大多數向量資料庫一樣) 依賴於全載模式：如果資料需要搜尋，就必須載入到本機節點上。無論資料是每分鐘上千次還是每季一次，都必須保持熱狀。這樣的設計選擇確保了可預測的效能，但也意味著叢集的規模過大，並且需要為冷資料支付根本不值得的資源。

分層儲存 就是我們的答案。

Milvus 2.6 引入了全新的分層儲存架構，具有真正的按需載入功能，可讓系統自動區分熱資料和冷資料：

熱段保留在靠近運算的緩存區
冷區段以低成本存放於遠端物件儲存空間
只有當查詢實際需要資料時，才會將資料擷取至本機節點

這將成本結構從「擁有多少資料」轉變為「實際使用多少資料」。在早期的生產部署中，這個簡單的轉移可降低高達 80% 的儲存和記憶體成本。

在這篇文章的其餘部分，我們將介紹分層儲存的運作方式，分享實際的效能結果，並顯示這項變更會在哪些方面產生最大的影響。

為什麼完全載入會在規模上瓦解

在深入瞭解解決方案之前，值得仔細瞭解一下 Milvus 2.5 和早期版本中使用的Full-load 模式為何會在工作負載擴充時成為限制因素。

在 Milvus 2.5 及更早版本中，當使用者發出Collection.load() 請求時，每個 QueryNode 會在本機快取整個集合，包括元資料、欄位資料和索引。這些元件會從物件儲存中下載，並完全儲存在記憶體中，或以記憶體映射 (mmap) 的方式儲存在本機磁碟中。只有在所有這些資料都在本機可用之後，資料集才會被標記為已載入，並準備好提供查詢服務。

換句話說，除非節點上有完整的資料集（無論是熱的還是冷的），否則資料集是不可查詢的。

注意：對於嵌入原始向量資料的索引類型，Milvus 只會載入索引檔案，而不會分別載入向量欄位。即使如此，索引必須完全載入才能提供查詢服務，而不論實際存取了多少資料。

要瞭解為什麼這會變成問題，請考慮一個具體的範例：

假設您有一個中等大小的向量資料集，其中有

1 億向量
768 個維度(BERT 嵌入)
float32精度 (每個維度 4 位元組)
一個HNSW 索引

在此設定中，單是 HNSW 索引 (包括內嵌的原始向量) 就佔用了約 430 GB 的記憶體。在加入使用者 ID、時間戳記或類別標籤等常見標量欄位後，本機資源總使用量很容易就超過 500 GB。

這表示，即使 80% 的資料很少或從未被查詢，系統仍必須提供並保留超過 500 GB 的本機記憶體或磁碟，才能讓資料集維持在線。

對於某些工作負載，這種行為是可以接受的：

如果幾乎所有資料都會被頻繁存取，則完全載入所有資料可提供最低的查詢延遲，但成本也最高。
如果資料可分為熱子集和暖子集，將暖資料記憶體映射到磁碟可以部分降低記憶體壓力。

但是，在 80% 或更多資料位於長尾資料的工作負載中，完全載入的缺點很快就會浮現，包括效能和成本。

效能瓶頸

實際上，完全載入所影響的不只是查詢效能，通常還會拖慢例行作業工作流程：

較長的滾動升級時間：在大型集群中，滾動升級可能需要數小時甚至一整天的時間，因為每個節點都必須重新載入整個資料集，才能再次變為可用。
故障後恢復速度較慢：當 QueryNode 重新啟動時，在重新載入所有資料之前，它無法提供流量服務，這將大幅延長復原時間，並擴大節點故障的影響。
迭代與實驗速度變慢：完全載入會減慢開發工作流程，迫使人工智能團隊在測試新資料集或索引配置時，需要等待數小時才能載入資料。

成本效率低

完全載入也會推高基礎架構成本。例如，在主流雲端記憶體最佳化的實體上，在本機儲存 1 TB 的資料大約需要 $**70, 000peryear**, basedonconservativepricing (AWSr6i :$ $,000$ on conservative $pricing (AWS r6i: ~$ $*, basedonconservativepricing (AWSr6i$ : $5.74 / GB / 月；GCP n4-highmem：~5$ $. 68 / GB / month; AzureE-series :$ 5 $.68 / GB / month; Azure E-series：~$ 5 $. 68 / GB / 月; AzureE -$ $系列$ : $5.67 / GB / 月)。$

現在考慮一個更現實的存取模式，其中 80% 的資料是冷資料，可儲存在物件儲存中取代 (價格約為 $0.023 / GB / 月)：

200 GB 熱資料 × $5.68
800 GB 冷資料 × $0.023

年度成本：(200×5.68+800×0.023)×12≈$14,000

總儲存成本降低了 80%，而在實際重要的地方卻沒有犧牲效能。

什麼是分層儲存，如何運作？

為了消除這種取捨，Milvus 2.6 引入了分層儲存，透過將本機儲存視為快取記憶體，而非整個資料集的容器，來平衡效能與成本。

在此模型中，QueryNodes 只會在啟動時載入輕量級的元資料。字段資料和索引會在查詢需要時從遠端物件儲存按需取得，如果需要經常存取，則會在本機進行快取。不活動的資料會被驅逐，以釋放空間。

因此，熱資料會留在計算層附近，以進行低延遲的查詢，而冷資料則會留在物件儲存中，直到需要為止。這可減少載入時間、提高資源效率，並允許 QueryNodes 查詢遠大於其本機記憶體或磁碟容量的資料集。

實際上，分層儲存的運作方式如下：

將熱門資料保留在本機：大約 20% 經常存取的資料會保留在本機節點上，以確保 80% 最重要查詢的低延遲。
根據需求載入冷資料：其餘 80% 很少存取的資料只會在需要時才擷取，以釋放大部分的本機記憶體和磁碟資源。
以 LRU 為基礎的驅逐動態適應：Milvus 使用 LRU（最近最少使用）驅逐策略來持續調整哪些資料被視為熱資料或冷資料。不活動的資料會被自動驅逐，為新存取的資料騰出空間。

有了這種設計，Milvus 不再受限於本機記憶體和磁碟的固定容量。取而代之的是，本機資源作為動態管理的快取記憶體，持續從非作用中的資料回收空間，並重新分配給作用中的工作負載。

在引擎蓋下，此行為由三個核心技術機制啟用：

1.懶惰載入

在初始化時，Milvus 只載入最小的區段層級元資料，讓資料集在啟動後幾乎可以立即查詢。欄位資料和索引檔案保留在遠端儲存，並在執行查詢時按需取得，以保持本機記憶體和磁碟的低使用率。

集合載入在 Milvus 2.5 中如何運作

在 Milvus 2.6 及之後的版本中，懶惰載入如何運作

初始化期間載入的元資料分為四個主要類別：

區段統計(基本資訊，例如行數、區段大小和模式元資料)
時間戳記(用於支援時間旅行查詢)
插入和刪除記錄（在查詢執行期間需要用來維持資料一致性）
Bloom 過濾器(用於快速預過濾，以快速消除不相關的區段)

2.部分載入

懶惰載入控制資料載入的時間，而部分載入則控制資料載入的數量。一旦開始查詢或搜尋，QueryNode 會執行部分載入，僅從物件儲存區擷取所需的資料區塊或索引檔案。

向量索引：租戶感知載入

Milvus 2.6+ 引入的最具影響力的功能之一，是專為多租戶工作負載而設計的向量索引的租戶感知載入。

當查詢存取來自單一租戶的資料時，Milvus 只會載入向量索引中屬於該租戶的部分，而跳過所有其他租戶的索引資料。這可讓本機資源專注於活動租戶。

這種設計提供了幾個好處：

不活動租戶的向量索引不會消耗本機記憶體或磁碟。
活動租戶的索引資料保持快取，以便進行低延遲存取
租戶層級的 LRU 驅逐政策可確保各租戶公平使用快取記憶體

標量欄位：列級部分載入

部分載入也適用於標量欄位，允許 Milvus 只載入查詢明確引用的欄位。

考慮一個有50 個模式欄位的集合，例如id,vector,title,description,category,price,stock, 和tags, 而您只需要傳回三個欄位 -id,title, 和price 。

在Milvus 2.5 中，無論查詢需求為何，都會載入所有 50 個標量字段。
在Milvus 2.6+ 中，只有三個要求的欄位會被載入。其餘 47 個欄位不被載入，僅在稍後需要存取時才被擷取。

這可以節省大量資源。如果每個標量欄位佔用 20 GB：

載入所有欄位需要1,000 GB(50 × 20 GB)
僅載入三個所需欄位需要60 GB

這表示標量資料載入減少了 94%，而不會影響查詢的正確性或結果。

注意：標量欄位和向量索引的租戶感知部分載入將在即將發佈的版本中正式推出。一旦推出，它將進一步減少負載延遲，並改善大型多租戶部署中的冷查詢效能。

3.基於 LRU 的快取驅逐

懶惰載入和部分載入可大幅減少導入本機記憶體和磁碟的資料數量。然而，在長時間運行的系統中，快取記憶體仍會隨著新資料的存取而成長。當達到本機容量時，以 LRU 為基礎的快取驅逐就會生效。

LRU (最近最少使用) 驅逐遵循一個簡單的規則：最近未被存取的資料會先被驅逐。這可為新存取的資料騰出本機空間，同時將經常使用的資料保留在快取記憶體中。

效能評估：分層儲存與完全載入

為了評估分層儲存的實際影響，我們建立了一個與生產工作負載非常接近的測試環境。我們從五個層面比較了有分層儲存與沒有分層儲存的 Milvus：載入時間、資源使用、查詢效能、有效容量和成本效益。

實驗設定

資料集

1 億個向量，共 768 個維度 (BERT 嵌入)
向量索引大小：約 430 GB
10 個標量字段，包括 ID、時間戳記和類別

硬體配置

1 個 QueryNode，配備 4 個 vCPU、32 GB 記憶體和 1 TB NVMe SSD
10 Gbps 網路
MinIO 物件儲存群集作為遠端儲存後端

存取模式

查詢遵循真實的冷熱存取分佈：

80% 的查詢以最近 30 天的資料為目標 (≈總資料的 20%)
15% 的查詢以 30-90 天內的資料為目標 (≈總資料的 30%)
5% 針對 90 天以上的資料 (≈總資料的 50%)

主要結果

1.載入時間快 33 倍

階段	Milvus 2.5	Milvus 2.6+ (分層儲存)	速度提升
資料下載	22 分鐘	28 秒	47×
索引載入	3 分鐘	17 秒	10.5×
總計	25 分鐘	45 秒	33×

在 Milvus 2.5 中，載入資料集需要25 分鐘。在 Milvus 2.6+ 中使用分層儲存後，相同的工作負載只需45 秒即可完成，代表負載效率大幅提升。

2.本機資源使用量減少 80

階段	Milvus 2.5	Milvus 2.6+ (分層儲存)	減少
負載後	430 GB	12 GB	-97%
1 小時後	430 GB	68 GB	-84%
24 小時後	430 GB	85 GB	-80%
穩定狀態	430 GB	85-95 GB	~80%

在 Milvus 2.5 中，不論工作負載或執行時間，本機資源使用量都維持在430 GB。相比之下，Milvus 2.6+ 在載入後立即以12 GB開始。

隨著查詢的執行，經常存取的資料會被緩存到本機，資源使用量也會逐漸增加。大約 24 小時後，系統穩定在85-95 GB，反映出熱資料的工作集。長期而言，這會導致本機記憶體和磁碟使用量減少約 80%，而不會犧牲查詢的可用性。

3.對熱資料效能的影響近乎零

查詢類型	Milvus 2.5 P99 延遲	Milvus 2.6+ P99 延遲	變更
熱資料查詢	15 毫秒	16 毫秒	+6.7%
熱資料查詢	15 毫秒	28 毫秒	+86%
冷資料查詢 (首次存取)	15 毫秒	120 毫秒	+700%
冷資料查詢 (快取)	15 毫秒	18 毫秒	+20%

對於約佔所有查詢 80% 的熱資料，P99 延遲僅增加 6.7%，對生產幾乎沒有影響。

冷資料查詢在首次存取時會因為按需求從物件儲存載入而顯示較高的延遲。不過，一旦快取之後，其延遲只會增加 20%。由於冷資料的存取頻率較低，因此對大多數的實際工作負載而言，這種折衷通常是可以接受的。

4.4.3 倍的有效容量

在相同的硬體預算下 (八台伺服器，每台 64 GB 記憶體 (總共 512 GB))，Milvus 2.5 最多可載入 512 GB 的資料，相當於約 1.36 億個向量。

在 Milvus 2.6+ 中啟用分層儲存後，相同的硬體可支援 2.2 TB 的資料，或大約 5.9 億向量。這代表有效容量增加了 4.3 倍，無須擴充本機記憶體即可提供更大的資料集。

5.成本降低 80.1%

以 AWS 環境中的 2 TB 向量資料集為例，假設 20% 的資料是熱資料 (400 GB)，成本比較如下：

項目	Milvus 2.5	Milvus 2.6+ (分層儲存)	節省成本
每月成本	$11,802	$2,343	$9,459
年度成本	$141,624	$28,116	$113,508
節省率	-	-	80.1%

基準摘要

在所有測試中，分層儲存提供一致且可衡量的改善：

載入時間快 33 倍：收集載入時間從25 分鐘縮短至 45 秒。
本機資源使用率降低 80%：在穩態運作中，記憶體和本機磁碟使用量減少約80%。
對熱資料效能幾近零影響：熱資料的 P99 延遲增加不到 10%，維持低延遲的查詢效能。
控制冷資料的延遲：冷資料在首次存取時會產生較高的延遲，但由於其存取頻率較低，因此是可以接受的。
4.3 倍的有效容量：相同的硬體可以提供4-5 倍的資料服務，而不需要額外的記憶體。
成本降低 80% 以上：每年基礎架構成本可降低80% 以上。

何時在 Milvus 中使用分層儲存設備

根據基準結果和實際生產案例，我們將分層儲存使用案例分為三類，以協助您決定它是否適合您的工作負載。

最適合的使用案例

1.多租戶向量搜尋平台

特性：大量租戶，活動高度不平均；向量搜尋是核心工作負載。
存取模式：少於 20% 的租戶產生超過 80% 的向量查詢。
預期效益：成本降低 70-80%；容量擴充 3-5倍。

2.電子商務推薦系統 (向量搜尋工作負載)

特性：頂尖商品與長尾商品之間有強烈的人氣傾斜。
存取模式：前 10% 的產品佔向量搜尋流量的 ~80%。
預期效益：高峰活動期間無需額外容量；成本降低 60-70

3.冷熱區分明確的大型資料集（向量主導）

特性：TB 規模或更大的資料集，存取方式偏重於最近的資料。
存取模式：典型的 80/20 分佈：20% 的資料為 80% 的查詢服務
預期效益：成本降低 75-85

適合的使用個案

1.成本敏感型工作負載

特性：預算緊縮，但可容忍輕微的效能折衷。
存取模式：向量查詢相對集中。
預期效益：成本降低 50-70%；冷資料在首次存取時可能會產生 ~500 毫秒的延遲，應根據 SLA 要求進行評估。

2.歷史資料保留與存檔搜尋

特性：大量歷史向量，查詢頻率非常低。
存取模式：約 90% 的查詢以最近的資料為目標。
預期效益：保留完整的歷史資料集；保持基礎結構成本的可預測性與可控性

不適合的使用個案

1.一致的熱資料工作負載

特徵：所有資料都以類似的頻率存取，沒有明顯的冷熱區分。
不適合的原因：快取記憶體效益有限；增加系統複雜度，卻沒有意義的增益

2.超低延遲工作負載

特性：對延遲極為敏感的系統，例如金融交易或即時競價
為什麼不適合？即使是微小的延遲變化也無法接受；完全載入可提供更可預測的效能

快速入門：在 Milvus 2.6+ 中嘗試分層儲存

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

結論

Milvus 2.6 中的分層儲存解決了向量資料的儲存方式與實際存取方式之間常見的錯配問題。在大多數生產系統中，只有一小部分資料會被頻繁查詢，但傳統的載入模型卻將所有資料視為同樣熱門的資料。Milvus 轉向按需載入，並將本機記憶體和磁碟作為快取記憶體來管理，使資源消耗符合實際查詢行為，而非最壞情況的假設。

此方法可讓系統擴充至更大的資料集，而不需按比例增加本機資源，同時保持熱查詢效能大致不變。冷資料在需要時仍可存取，並具有可預測和受限的延遲，讓權衡變得明確和可控。隨著向量搜尋深入成本敏感、多租戶及長時間運作的生產環境，分層儲存為有效率的規模運作提供了實用的基礎。

如需更多關於分層儲存的資訊，請參閱下列說明文件：