Home
Blog
MinIO 停止接受社群變更：評估 RustFS 作為 Milvus 的 S3 相容物件儲存後端是否可行

MinIO 停止接受社群變更：評估 RustFS 作為 Milvus 的 S3 相容物件儲存後端是否可行

Tutorials

January 14, 2026

Min Yin

本文章由 Milvus 最活躍的社群貢獻者之一 Min Yin 撰寫，並經允許在此發表。

MinIO是一套開放原始碼、高效能且相容於 S3 的物件儲存系統，廣泛應用於 AI/ML、分析及其他資料密集型工作負載。對於許多Milvus部署而言，它也是物件儲存的預設選擇。但最近，MinIO 團隊更新了GitHub README，聲明此專案不再接受新的變更。

事實上，在過去幾年中，MinIO 已逐漸將其注意力轉向商業產品，收緊其授權與發行模式，並縮減社群儲存庫中的主動開發規模。將開源專案轉移到維護模式，是這個更廣泛轉型的自然結果。

對於預設依賴 MinIO 的 Milvus 使用者來說，這個改變是難以忽視的。物件儲存是 Milvus 持久層的核心，隨著時間的推移，它的可靠性不僅取決於目前的運作狀況，也取決於系統是否能隨著其支援的工作負載持續演進。

在此背景下，本文探討RustFS作為潛在替代方案的可能性。RustFS 是一個以 Rust 為基礎、與 S3 相容的物件儲存系統，強調記憶體安全與現代系統設計。它仍處於實驗階段，本討論並非生產推薦。

Milvus 架構與物件儲存元件的位置

Milvus 2.6 採用完全解耦的儲存-運算架構。在這個模型中，儲存層由三個獨立的元件組成，每個元件都扮演不同的角色。

Etcd 會儲存元資料，Pulsar 或 Kafka 會處理串流日誌，而物件儲存 - 通常是 MinIO 或 S3 相容的服務 - 則會提供向量資料和索引檔案的持久性。由於儲存與運算是分開的，因此 Milvus 可以獨立擴充運算節點，同時依賴共享、可靠的儲存後端。

物件儲存在 Milvus 中的角色

物件儲存是 Milvus 的持久儲存層。原始向量資料以 binlog 的形式持久化，而 HNSW 和 IVF_FLAT 等索引結構也儲存在此。

這種設計使得計算節點無狀態。查詢節點不在本機儲存資料，而是按需求從物件儲存載入區段和索引。因此，節點可以自由增減、從故障中快速恢復，並支援整個群集的動態負載平衡，而無需在儲存層重新平衡資料。

my-milvus-bucket/
├── files/                          # rootPath (default)
│   ├── insert_log/                 # insert binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}     # Per-field binlog files
│   │
│   ├── delta_log/                  # Delete binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Log_ID}        
│   │
│   ├── stats_log/                  # Statistical data (e.g., Bloom filters)
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}
│   │
│   └── index_files/                # Index files
│       └── {Build_ID}_{Index_Version}_{Segment_ID}_{Field_ID}/
│           ├── index_file_0
│           ├── index_file_1
│           └── ...

Milvus 為何使用 S3 API

Milvus 並未定義自訂儲存通訊協定，而是使用 S3 API 作為其物件儲存介面。S3 已經成為物件儲存的實際標準：AWS S3、阿里巴巴雲 OSS 及騰訊雲 COS 等主要雲供應商都原生支援 S3，而 MinIO、Ceph RGW、SeaweedFS 及 RustFS 等開放原始碼系統也完全相容。

透過將 S3 API 標準化，Milvus 可以依賴成熟、經過良好測試的 Go SDK，而無需為每個儲存後端維護獨立的整合。這種抽象化也為使用者提供了部署上的彈性：MinIO 用於本機開發，雲端物件儲存用於生產，或 Ceph 和 RustFS 用於私有環境。只要有 S3 相容的端點可用，Milvus 就不需要知道或關心底下使用的是哪一種儲存系統。

# Milvus configuration file milvus.yaml
minio:
 address: localhost
 port: 9000
 accessKeyID: minioadmin
 secretAccessKey: minioadmin
 useSSL: false
 bucketName: milvus-bucket

評估 RustFS 作為 Milvus 的 S3 相容物件儲存後端

專案概述

RustFS 是用 Rust 寫成的分散式物件儲存系統。它目前處於 alpha 階段 (版本 1.0.0-alpha.68)，目標是結合 MinIO 的操作簡易性與 Rust 在記憶體安全與效能上的優勢。更多詳細資訊請參閱GitHub。

RustFS 仍在積極開發中，其散佈式模式尚未正式發行。因此，現階段不建議使用 RustFS 來處理生產或關鍵任務的工作負載。

架構設計

RustFS 遵循的設計概念與 MinIO 相似。HTTP 伺服器會揭露與 S3 相容的 API，而物件管理員會處理物件的元資料，儲存引擎則負責資料區塊的管理。在儲存層，RustFS 依賴 XFS 或 ext4 等標準檔案系統。

對於計劃中的分散式模式，RustFS 打算使用 etcd 來協調元資料，由多個 RustFS 節點組成一個叢集。此設計與一般物件儲存架構緊密結合，讓有 MinIO 經驗的使用者熟悉 RustFS。

與 Milvus 的相容性

在考慮 RustFS 作為另一個物件儲存後端之前，有必要評估它是否符合 Milvus 的核心儲存需求。

Milvus 要求	S3 API	RustFS 支援
向量資料持久化	`PutObject`,`GetObject`	✅完全支援
索引檔案管理	`ListObjects`,`DeleteObject`	✅ 完全支援
分割合併作業	多部分上傳	✅ 完全支援
一致性保證	強讀後寫	✅ 強一致性（單節點）

根據這項評估，RustFS 目前的 S3 API 實作滿足 Milvus 的基線功能需求。這使得它適合在非生產環境中進行實際測試。

實作：在 Milvus 中以 RustFS 取代 MinIO

本練習的目標是取代預設的 MinIO 物件儲存服務，並使用 RustFS 作為物件儲存的後端來部署 Milvus 2.6.7。

先決條件

已安裝 Docker 和 Docker Compose (版本 ≥ 20.10)，系統可以正常拉取映像檔和執行容器。
本機目錄可用於物件資料儲存，例如/volume/data/ (或自訂路徑)。
主機連接埠 9000 開放給外部存取，或依此設定其他連接埠。
RustFS 容器以非 root 使用者 (rustfs) 身份執行。確保主機資料目錄為 UID 10001 所有。

步驟 1：建立資料目錄並設定權限

# Create the project directory
mkdir -p milvus-rustfs && cd milvus-rustfs
# Create the data directory
mkdir -p volumes/{rustfs, etcd, milvus}
# Update permissions for the RustFS directory
sudo chown -R 10001:10001 volumes/rustfs

下載官方 Docker Compose 檔案

wget https://github.com/milvus-io/milvus/releases/download/v2.6.7/milvus-standalone-docker-compose.yml -O docker-compose.yml

步驟 2：修改物件儲存服務

定義 RustFS 服務

注意：請確認存取金鑰和秘密金鑰與 Milvus 服務中設定的憑證相符。

rustfs:
 container_name: milvus-rustfs
 image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs: latest
 environment:
 RUSTFS_ACCESS_KEY: minioadmin
 RUSTFS_SECRET_KEY: minioadmin
 RUSTFS_CONSOLE_ENABLE: “true”
 RUSTFS_REGION: us-east-1
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3

完成設定

注意：Milvus 的儲存組態目前假設 MinIO 風格的預設值，尚未允許自訂存取金鑰或秘密金鑰值。當使用 RustFS 作為替代時，它必須使用 Milvus 期望的相同預設憑證。

version: ‘3.5’
services:
 etcd:
 container_name: milvus-etcd
 image: registry.cn-hangzhou.aliyuncs.com/etcd/etcd: v3.5.25
 environment:
 - ETCD_AUTO_COMPACTION_MODE=revision
 - ETCD_AUTO_COMPACTION_RETENTION=1000
 - ETCD_QUOTA_BACKEND_BYTES=4294967296
 - ETCD_SNAPSHOT_COUNT=50000
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
 command: etcd -advertise-client-urls=http://etcd:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd
 healthcheck:
 test: [“CMD”, “etcdctl”, “endpoint”, “health”]
 interval: 30s
 timeout: 20s
 retries: 3
 rustfs:
 container_name: milvus-rustfs
 image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs: latest
 environment:
 RUSTFS_ACCESS_KEY: minioadmin
 RUSTFS_SECRET_KEY: minioadmin
 RUSTFS_CONSOLE_ENABLE: “true”
 RUSTFS_REGION: us-east-1
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3
 standalone:
 container_name: milvus-standalone
 image: registry.cn-hangzhou.aliyuncs.com/milvus/milvus: v2.6.7
 command: [”milvus“, ”run“, ”standalone“]
 security_opt:
 - seccomp: unconfined
 environment:
 MINIO_REGION: us-east-1
 ETCD_ENDPOINTS: etcd:2379
 MINIO_ADDRESS: rustfs:9000
 MINIO_ACCESS_KEY: minioadmin
 MINIO_SECRET_KEY: minioadmin
 MINIO_USE_SSL: ”false“
 MQ_TYPE: rocksmq
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
 healthcheck:
 test: [”CMD“, ”curl“, ”-f“, ”http://localhost:9091/healthz"]
 interval: 30s
 start_period: 90s
 timeout: 20s
 retries: 3
 ports:
 - “19530:19530”
 - “9091:9091”
 depends_on:
 - “etcd”
 - “rustfs”
networks:
 default:
 name: milvus

啟動服務

docker-compose -f docker-compose.yaml up -d

檢查服務狀態

docker-compose ps -a

存取 RustFS Web UI

在瀏覽器中開啟 RustFS 網頁介面：http://localhost:9001

使用預設憑證登入：使用者名稱和密碼都是 minioadmin。

測試 Milvus 服務

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
# connect to Milvus
connections.connect(
 alias="default",
 host='localhost',
 port='19530'
)
print("✓ Successfully connected to Milvus!")
# create test collection
fields = [
 FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
 FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=128)
]
schema = CollectionSchema(fields=fields, description="test collection")
collection = Collection(name="test_collection", schema=schema)
print("✓ Test collection created!")
print("✓ RustFS verified as the S3 storage backend!")
### Step 3: Storage Performance Testing (Experimental)
Test Design
Two Milvus deployments were set up on identical hardware (16 cores / 32 GB memory / NVMe SSD), using RustFS and MinIO respectively as the object storage backend. The test dataset consisted of 1,000,000 vectors with 768 dimensions, using an HNSW index with parameters M = 16 and efConstruction = 200. Data was inserted in batches of 5,000.
The following metrics were evaluated: Insert throughput, Index build time, Cold and warm load time, Search latency, Storage footprint.
Test Code
Note: Only the core parts of the test code are shown below.

def milvus_load_bench(dim=768, rows=1_000_000, batch=5000): collection = Collection(...) # Insert test t0 = time.perf_counter() for i in range(0, rows, batch): collection.insert([rng.random((batch, dim), dtype=np.float32).tolist()]) insert_time = time.perf_counter() - t0 # Index build collection.flush() collection.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...})#負載測試 (冷啟動 + 兩次暖啟動) collection.load_times =[**] - t0release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # 查詢測試 search_times = [] for _ in range(3): collection.search(queries, limit=10, ...)


**Test Command**

python bench.py milvus-load-bench --dim 768 --rows 1000000 --batch 5000
--索引類型 HNSW --repeat-load 3 --release-before-load --do-search --drop-after

Metric	RustFS	MinIO	Difference
Insert Throughput	4,472 rows/s	2,845 rows/s	0.57
Index Build Time	803 s	562 s	-43%
Load (Cold Start)	22.7 s	18.3 s	-24%
Load (Warm Start)	0.009 s	0.027 s	0.67
Search Latency	7.96 ms	1.85 ms	-330%
Storage Usage	7.8 GB	18.0 GB	0.57

**Performance Results** RustFS Faster writes (+57%), lower storage usage (–57%), and faster warm loads (+67%), making it suitable for write-heavy, cost-sensitive workloads. Much slower queries (7.96 ms vs. 1.85 ms, ~+330% latency) with noticeable variance (up to 17.14 ms), and 43% slower index builds. Not suitable for query-intensive applications. MinIO Excellent query performance (1.85 ms average latency), mature small-file and random I/O optimizations, and a well-established ecosystem. Metric RustFS MinIO Difference Insert Throughput 4,472 rows/s 2,845 rows/s 0.57 Index Build Time 803 s 562 s -43% Load (Cold Start) 22.7 s 18.3 s -24% Load (Warm Start) 0.009 s 0.027 s 0.67 Search Latency 7.96 ms 1.85 ms -330% Storage Usage 7.8 GB 18.0 GB 0.57 RustFS significantly outperforms MinIO in write performance and storage efficiency, with both showing roughly 57% improvement. This demonstrates the system-level advantages of the Rust ecosystem. However, the 330% gap in query latency limits RustFS’s suitability for query-intensive workloads. For production environments, cloud-managed object storage services like AWS S3 are recommended first, as they are mature, stable, and require no operational effort. Self-hosted solutions are better suited to specific scenarios: RustFS for cost-sensitive or write-intensive workloads, MinIO for query-intensive use cases, and Ceph for data sovereignty. With further optimization in random read performance, RustFS has the potential to become a strong self-hosted option. Conclusion MinIO’s decision to stop accepting new community contributions is disappointing for many developers, but it won’t disrupt Milvus users. Milvus depends on the S3 API—not any specific vendor implementation—so swapping storage backends is straightforward. This S3-compatibility layer is intentional: it ensures Milvus stays flexible, portable, and decoupled from vendor lock-in. For production deployments, cloud-managed services such as AWS S3 and Alibaba Cloud OSS remain the most reliable options. They’re mature, highly available, and drastically reduce the operational load compared to running your own object storage. Self-hosted systems like MinIO or Ceph still make sense in cost-sensitive environments or where data sovereignty is non-negotiable, but they require significantly more engineering overhead to operate safely at scale. RustFS is interesting—Apache 2.0-licensed, Rust-based, and community-driven—but it’s still early. The performance gap is noticeable, and the distributed mode hasn’t shipped yet. It’s not production-ready today, but it’s a project worth watching as it matures. If you’re comparing object storage options for Milvus, evaluating MinIO replacements, or weighing the operational trade-offs of different backends, we’d love to hear from you.

Join our[ Discord channel](https://discord.com/invite/8uyFbECzPX) and share your thoughts. You can also book a 20-minute one-on-one session to get insights, guidance, and answers to your questions through[ Milvus Office Hours](https://milvus.io/blog/join-milvus-office-hours-to-get-support-from-vectordb-experts.md).