Home
Blog
MinIO、コミュニティによる変更の受付を停止：MilvusのS3互換オブジェクトストレージバックエンドとしてのRustFSの評価

MinIO、コミュニティによる変更の受付を停止：MilvusのS3互換オブジェクトストレージバックエンドとしてのRustFSの評価

Tutorials

January 14, 2026

Min Yin

この投稿は、Milvusの最も積極的なコミュニティ貢献者の一人であるMin Yinによって書かれ、許可を得てここに掲載されています。

MinIOは、AI/ML、アナリティクス、その他のデータ集約型ワークロードで広く使用されている、オープンソースの高性能なS3互換オブジェクトストレージシステムである。Milvusの多くのデプロイメントでは、MinIOはオブジェクト・ストレージのデフォルトの選択肢にもなっている。しかし最近、MinIOチームはGitHubのREADMEを更新し、このプロジェクトはもう新しい変更を受け付けていないと述べた。

実際、過去数年間、MinIOは徐々に商用製品に目を向け、ライセンスと配布モデルを強化し、コミュニティ・リポジトリでの活発な開発を縮小してきた。オープンソース・プロジェクトをメンテナンス・モードに移行することは、そのような広範な移行の自然な結果である。

デフォルトでMinIOに依存しているMilvusユーザーにとって、この変化は無視できない。オブジェクト・ストレージはMilvusの永続化レイヤーの中心に位置し、その長期的な信頼性は、現在機能していることだけでなく、システムがサポートするワークロードとともに進化し続けるかどうかにかかっている。

このような背景から、本稿では代替となり得るRustFSについて検討する。RustFSはRustベースのS3互換オブジェクト・ストレージ・システムであり、メモリ安全性と最新のシステム設計を重視している。RustFSはまだ実験的なものであり、この議論は本番での推奨ではない。

Milvusアーキテクチャとオブジェクトストレージコンポーネントの位置づけ

Milvus 2.6は、完全に分離されたストレージ-コンピュートアーキテクチャを採用しています。このモデルでは、ストレージ層は3つの独立したコンポーネントで構成され、それぞれが明確な役割を果たします。

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、Alibaba Cloud OSS、Tencent Cloud COSなどの主要なクラウドプロバイダーがネイティブにサポートしているほか、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

MilvusのS3互換オブジェクトストレージバックエンドとしてのRustFSの評価

プロジェクトの概要

RustFSはRustで書かれた分散オブジェクトストレージシステムである。現在アルファ版（バージョン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を代替のオブジェクトストレージバックエンドとして検討する前に、RustFSがMilvusのコアストレージ要件を満たしているかどうかを評価する必要があります。

Milvusの要件	S3 API	RustFSのサポート
ベクトルデータの永続化	`PutObject`,`GetObject`	完全サポート
インデックスファイル管理	`ListObjects`,`DeleteObject`	完全サポート
セグメントマージ操作	マルチパートのアップロード	完全サポート
一貫性の保証	強力なリード・アフター・ライト	強力な一貫性（シングルノード）

この評価に基づき、RustFSの現在のS3 API実装はMilvusの基本機能要件を満たしています。このため、非生産環境での実用的なテストに適しています。

ハンズオン: MilvusでMinIOをRustFSに置き換える

この演習の目的は、デフォルトの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(...) # 挿入テスト 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 # インデックスの構築 collection.flush() collection.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...}) # ロードテスト（コールドスタート＋2回のウォームスタート） collection.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
-index-type 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).