MinIO nimmt keine Änderungen der Gemeinschaft mehr an: Evaluierung von RustFS als praktikables S3-kompatibles Objektspeicher-Backend für Milvus

Dieser Beitrag stammt von Min Yin, einem der aktivsten Community-Mitarbeiter von Milvus, und wird hier mit Genehmigung veröffentlicht.

MinIO ist ein quelloffenes, hochleistungsfähiges und S3-kompatibles Objektspeichersystem, das in der KI/ML, Analytik und anderen datenintensiven Workloads weit verbreitet ist. Für viele Milvus-Bereitstellungen war es auch die Standardwahl für Objektspeicher. Kürzlich hat das MinIO-Team jedoch sein GitHub README aktualisiert, um darauf hinzuweisen, dass dieses Projekt keine neuen Änderungen mehr annimmt.

Tatsächlich hat sich MinIO in den letzten Jahren allmählich auf kommerzielle Angebote verlagert, sein Lizenz- und Vertriebsmodell gestrafft und die aktive Entwicklung im Community-Repository zurückgefahren. Die Überführung des Open-Source-Projekts in den Wartungsmodus ist das natürliche Ergebnis dieses umfassenden Übergangs.

Für Milvus-Benutzer, die sich standardmäßig auf MinIO verlassen, ist diese Änderung kaum zu übersehen. Der Objektspeicher ist das Herzstück der Persistenzschicht von Milvus, und seine Zuverlässigkeit hängt nicht nur davon ab, was heute funktioniert, sondern auch davon, ob sich das System mit den von ihm unterstützten Workloads weiterentwickelt.

Vor diesem Hintergrund untersucht dieser Artikel RustFS als mögliche Alternative. RustFS ist ein auf Rust basierendes, S3-kompatibles Objektspeichersystem, das den Schwerpunkt auf Speichersicherheit und modernes Systemdesign legt. Es befindet sich noch im Versuchsstadium, und diese Diskussion stellt keine Empfehlung für die Produktion dar.

Die Milvus-Architektur und der Sitz der Objektspeicher-Komponente

Milvus 2.6 verwendet eine vollständig entkoppelte Speicher-Rechner-Architektur. In diesem Modell besteht die Speicherebene aus drei unabhängigen Komponenten, die jeweils eine bestimmte Aufgabe erfüllen.

Etcd speichert Metadaten, Pulsar oder Kafka verarbeitet Streaming-Protokolle, und Objektspeicher - typischerweise MinIO oder ein S3-kompatibler Dienst - bietet dauerhafte Persistenz für Vektordaten und Indexdateien. Da Speicherung und Berechnung getrennt sind, kann Milvus die Berechnungsknoten unabhängig skalieren und sich dabei auf ein gemeinsames, zuverlässiges Speicher-Backend verlassen.

Die Rolle des Objektspeichers in Milvus

Der Objektspeicher ist die dauerhafte Speicherebene in Milvus. Rohe Vektordaten werden als binlogs persistiert, und Indexstrukturen wie HNSW und IVF_FLAT werden ebenfalls dort gespeichert.

Dieses Design macht Rechenknoten zustandslos. Abfrageknoten speichern Daten nicht lokal, sondern laden Segmente und Indizes bei Bedarf aus dem Objektspeicher. Daher können die Knoten frei skaliert werden, sich schnell von Ausfällen erholen und einen dynamischen Lastausgleich im gesamten Cluster unterstützen, ohne dass die Daten auf der Speicherebene neu abgeglichen werden müssen.

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
│           └── ...

Warum Milvus die S3-API verwendet

Anstatt ein eigenes Speicherprotokoll zu definieren, verwendet Milvus die S3-API als Objektspeicherschnittstelle. S3 hat sich zum De-facto-Standard für Objektspeicher entwickelt: Große Cloud-Anbieter wie AWS S3, Alibaba Cloud OSS und Tencent Cloud COS unterstützen es von Haus aus, während Open-Source-Systeme wie MinIO, Ceph RGW, SeaweedFS und RustFS vollständig kompatibel sind.

Durch die Standardisierung auf die S3-API kann Milvus auf ausgereifte, gut getestete Go-SDKs zurückgreifen, anstatt separate Integrationen für jedes Speicher-Backend zu pflegen. Diese Abstraktion gibt den Benutzern auch Flexibilität bei der Bereitstellung: MinIO für die lokale Entwicklung, Cloud-Objektspeicher in der Produktion oder Ceph und RustFS für private Umgebungen. Solange ein S3-kompatibler Endpunkt verfügbar ist, muss Milvus nicht wissen - oder sich darum kümmern - welches Speichersystem darunter verwendet wird.

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

Evaluierung von RustFS als S3-kompatibles Objektspeicher-Backend für Milvus

Überblick über das Projekt

RustFS ist ein verteiltes Objektspeichersystem, das in Rust geschrieben wurde. Es befindet sich derzeit in der Alpha-Phase (Version 1.0.0-alpha.68) und zielt darauf ab, die betriebliche Einfachheit von MinIO mit den Stärken von Rust in Bezug auf Speichersicherheit und Leistung zu kombinieren. Weitere Details sind auf GitHub verfügbar.

RustFS befindet sich noch in aktiver Entwicklung, und sein verteilter Modus wurde noch nicht offiziell veröffentlicht. Aus diesem Grund wird RustFS in diesem Stadium nicht für die Produktion oder geschäftskritische Arbeitslasten empfohlen.

Architektur

RustFS folgt einem Design, das konzeptionell ähnlich wie MinIO ist. Ein HTTP-Server stellt eine S3-kompatible API bereit, während ein Objektmanager die Objektmetadaten verwaltet und eine Speicher-Engine für die Verwaltung der Datenblöcke zuständig ist. Auf der Speicherebene stützt sich RustFS auf Standard-Dateisysteme wie XFS oder ext4.

Für den geplanten verteilten Modus beabsichtigt RustFS, etcd für die Metadatenkoordination zu verwenden, wobei mehrere RustFS-Knoten einen Cluster bilden. Dieses Design ist eng an gängige Objektspeicherarchitekturen angelehnt, wodurch RustFS Benutzern mit MinIO-Erfahrung vertraut ist.

Kompatibilität mit Milvus

Bevor RustFS als alternatives Objektspeicher-Backend in Betracht gezogen wird, muss geprüft werden, ob es die zentralen Speicheranforderungen von Milvus erfüllt.

Milvus-Anforderung	S3-API	RustFS-Unterstützung
Persistenz von Vektordaten	PutObject, GetObject	✅ Vollständig unterstützt
Verwaltung von Indexdateien	ListObjects, DeleteObject	✅ Vollständig unterstützt
Segment-Zusammenführungsoperationen	Mehrteiliger Upload	✅ Vollständig unterstützt
Garantierte Konsistenz	Starkes Lesen-nach-Schreiben	✅ Starke Konsistenz (Single-Node)

Auf der Grundlage dieser Bewertung erfüllt die aktuelle S3-API-Implementierung von RustFS die grundlegenden Funktionsanforderungen von Milvus. Damit ist sie für praktische Tests in Nicht-Produktionsumgebungen geeignet.

Hands-On: Ersetzen von MinIO durch RustFS in Milvus

Ziel dieser Übung ist es, den standardmäßigen MinIO-Objektspeicherdienst zu ersetzen und Milvus 2.6.7 mit RustFS als Objektspeicher-Backend bereitzustellen.

Voraussetzungen

1. Docker und Docker Compose sind installiert (Version ≥ 20.10), und das System kann Images ziehen und Container normal ausführen.

2. Es ist ein lokales Verzeichnis für die Speicherung von Objektdaten verfügbar, z. B. /volume/data/ (oder ein benutzerdefinierter Pfad).

3. Der Host-Port 9000 ist für den externen Zugriff offen, oder ein alternativer Port ist entsprechend konfiguriert.

4. Der RustFS-Container läuft unter einem Nicht-Root-Benutzer (rustfs). Stellen Sie sicher, dass das Host-Datenverzeichnis der UID 10001 gehört.

Schritt 1: Erstellen des Datenverzeichnisses und Festlegen von Berechtigungen

# 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

Laden Sie die offizielle Docker Compose-Datei herunter

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

Schritt 2: Ändern Sie den Objektspeicherdienst

Definieren Sie den RustFS-Dienst

Hinweis: Stellen Sie sicher, dass der Zugriffsschlüssel und der geheime Schlüssel mit den im Milvus-Dienst konfigurierten Anmeldeinformationen übereinstimmen.

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

Konfiguration abschließen

Hinweis: Die Speicherkonfiguration von Milvus geht derzeit von Standardwerten im Stil von MinIO aus und erlaubt noch keine benutzerdefinierten Werte für Zugriffsschlüssel oder geheime Schlüssel. Wenn Sie RustFS als Ersatz verwenden, müssen Sie dieselben Standardanmeldeinformationen verwenden, die von Milvus erwartet werden.

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

Starten Sie die Dienste

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

Überprüfen des Dienststatus

docker-compose ps -a

Zugriff auf die RustFS-Weboberfläche

Öffnen Sie die RustFS-Webschnittstelle in Ihrem Browser: http://localhost:9001

Melden Sie sich mit den Standard-Anmeldeinformationen an: Benutzername und Passwort sind beide minioadmin.

Testen Sie den Milvus-Dienst

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 aufbauen collection.flush() collection.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...}) # Lasttest (Kaltstart + zwei Warmstarts) collection.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # Abfragetest 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

**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).