MinIO smette di accettare le modifiche della comunità: Valutazione di RustFS come backend di archiviazione degli oggetti compatibile con S3 per Milvus

Questo post è stato scritto da Min Yin, uno dei più attivi collaboratori della comunità di Milvus, e viene pubblicato qui con l'autorizzazione.

MinIO è un sistema di archiviazione a oggetti open-source, ad alte prestazioni e compatibile con S3, ampiamente utilizzato in AI/ML, analisi e altri carichi di lavoro ad alta intensità di dati. Per molte implementazioni di Milvus, è stato anche la scelta predefinita per lo storage di oggetti. Recentemente, tuttavia, il team di MinIO ha aggiornato il suo README su GitHub per dichiarare che questo progetto non accetta più nuove modifiche.

In realtà, nel corso degli ultimi anni, MinIO ha gradualmente spostato la sua attenzione verso le offerte commerciali, rafforzando il suo modello di licenza e distribuzione e riducendo lo sviluppo attivo nel repository della comunità. Il passaggio del progetto open-source alla modalità di manutenzione è il risultato naturale di questa transizione più ampia.

Per gli utenti di Milvus che si affidano a MinIO di default, questo cambiamento è difficile da ignorare. Lo storage di oggetti è il cuore del livello di persistenza di Milvus e la sua affidabilità nel tempo dipende non solo da ciò che funziona oggi, ma anche dal fatto che il sistema continui a evolversi insieme ai carichi di lavoro che supporta.

In questo contesto, questo articolo esplora RustFS come potenziale alternativa. RustFS è un sistema di archiviazione di oggetti compatibile con S3 e basato su Rust che enfatizza la sicurezza della memoria e la progettazione di sistemi moderni. È ancora sperimentale e questa discussione non è una raccomandazione per la produzione.

L'architettura di Milvus e la posizione del componente di archiviazione degli oggetti

Milvus 2.6 adotta un'architettura storage-compute completamente disaccoppiata. In questo modello, il livello di archiviazione è composto da tre componenti indipendenti, ognuno dei quali svolge un ruolo distinto.

Etcd memorizza i metadati, Pulsar o Kafka gestisce i log in streaming e lo storage degli oggetti, tipicamente MinIO o un servizio compatibile con S3, fornisce una persistenza duratura per i dati vettoriali e i file di indice. Poiché lo storage e l'elaborazione sono separati, Milvus può scalare i nodi di elaborazione in modo indipendente, pur facendo affidamento su un backend di storage condiviso e affidabile.

Il ruolo dello storage a oggetti in Milvus

L'archiviazione a oggetti è il livello di archiviazione durevole di Milvus. I dati vettoriali grezzi sono conservati come binlog e le strutture di indice, come HNSW e IVF_FLAT, sono anch'esse memorizzate.

Questo design rende i nodi di calcolo senza stato. I nodi di interrogazione non memorizzano i dati localmente, ma caricano segmenti e indici dallo storage degli oggetti su richiesta. Di conseguenza, i nodi possono aumentare o diminuire liberamente, riprendersi rapidamente dai guasti e supportare il bilanciamento dinamico del carico in tutto il cluster senza riequilibrare i dati a livello di storage.

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

Perché Milvus utilizza l'API S3

Invece di definire un protocollo di archiviazione personalizzato, Milvus utilizza l'API S3 come interfaccia di archiviazione degli oggetti. S3 è diventato lo standard di fatto per l'archiviazione degli oggetti: i principali fornitori di cloud come AWS S3, Alibaba Cloud OSS e Tencent Cloud COS lo supportano in modo nativo, mentre i sistemi open-source come MinIO, Ceph RGW, SeaweedFS e RustFS sono pienamente compatibili.

Standardizzando l'API S3, Milvus può contare su SDK Go maturi e ben collaudati, invece di mantenere integrazioni separate per ogni backend di storage. Questa astrazione offre agli utenti anche flessibilità di distribuzione: MinIO per lo sviluppo locale, cloud object storage in produzione o Ceph e RustFS per gli ambienti privati. Finché è disponibile un endpoint compatibile con S3, Milvus non ha bisogno di sapere, o di interessarsi, a quale sistema di archiviazione viene utilizzato.

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

Valutazione di RustFS come backend di archiviazione a oggetti compatibile con S3 per Milvus

Panoramica del progetto

RustFS è un sistema di archiviazione distribuita di oggetti scritto in Rust. Attualmente è in fase alfa (versione 1.0.0-alpha.68) e mira a combinare la semplicità operativa di MinIO con i punti di forza di Rust in termini di sicurezza della memoria e prestazioni. Maggiori dettagli sono disponibili su GitHub.

RustFS è ancora in fase di sviluppo attivo e la sua modalità distribuita non è ancora stata rilasciata ufficialmente. Di conseguenza, RustFS non è raccomandato per la produzione o per carichi di lavoro mission-critical in questa fase.

Design dell'architettura

RustFS segue un design concettualmente simile a MinIO. Un server HTTP espone un'API compatibile con S3, mentre un Object Manager gestisce i metadati degli oggetti e uno Storage Engine è responsabile della gestione dei blocchi di dati. A livello di storage, RustFS si basa su file system standard come XFS o ext4.

Per la modalità distribuita prevista, RustFS intende utilizzare etcd per il coordinamento dei metadati, con più nodi RustFS che formano un cluster. Questo design si allinea strettamente alle comuni architetture di archiviazione di oggetti, rendendo RustFS familiare agli utenti con esperienza MinIO.

Compatibilità con Milvus

Prima di considerare RustFS come backend alternativo per l'archiviazione degli oggetti, è necessario valutare se soddisfa i requisiti di archiviazione fondamentali di Milvus.

Requisiti di Milvus	API S3	Supporto RustFS
Persistenza dei dati vettoriali	PutObject, GetObject	Completamente supportato
Gestione dei file indice	ListObjects, DeleteObject	✅ Completamente supportato
Operazioni di unione dei segmenti	Caricamento multiparte	✅ Completamente supportato
Garanzie di coerenza	Forte lettura-dopo-scrittura	Forte coerenza (singolo nodo)

Sulla base di questa valutazione, l'attuale implementazione dell'API S3 di RustFS soddisfa i requisiti funzionali di base di Milvus. Ciò la rende adatta a test pratici in ambienti non di produzione.

Esercitazione pratica: sostituzione di MinIO con RustFS in Milvus

L'obiettivo di questo esercizio è quello di sostituire il servizio predefinito di archiviazione degli oggetti MinIO e distribuire Milvus 2.6.7 utilizzando RustFS come backend di archiviazione degli oggetti.

Prerequisiti

1. Docker e Docker Compose sono installati (versione ≥ 20.10) e il sistema può estrarre le immagini ed eseguire normalmente i container.

2. È disponibile una directory locale per l'archiviazione dei dati degli oggetti, come /volume/data/ (o un percorso personalizzato).

3. La porta 9000 dell'host è aperta per l'accesso esterno o una porta alternativa è configurata di conseguenza.

4. Il contenitore RustFS viene eseguito come utente non root (rustfs). Assicurarsi che la directory dei dati dell'host sia di proprietà dell'UID 10001.

Passo 1: Creare la directory dei dati e impostare i permessi

# 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

Scaricare il file Docker Compose ufficiale

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

Passo 2: modificare il servizio di archiviazione a oggetti

Definire il servizio RustFS

Nota: Assicurarsi che la chiave di accesso e la chiave segreta corrispondano alle credenziali configurate nel servizio 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

Completare la configurazione

Nota: la configurazione dello storage di Milvus assume attualmente valori predefiniti di tipo MinIO e non consente ancora valori personalizzati per la chiave di accesso o la chiave segreta. Quando si usa RustFS come sostituto, si devono usare le stesse credenziali predefinite previste da 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

Avviare i servizi

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

Controllare lo stato del servizio

docker-compose ps -a

Accedere all'interfaccia web di RustFS

Aprire l'interfaccia web di RustFS nel browser: http://localhost:9001.

Accedere utilizzando le credenziali predefinite: nome utente e password sono entrambi minioadmin.

Testare il servizio 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(...) # Test di inserimento 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 # Costruzione indice collection.flush() collection.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...}) # Test di carico (avvio a freddo + due avvii a caldo) collection.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # Query test 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).