Blog
Una panoramica del sistema di archiviazione di Milvus e delle tecniche per valutarne e ottimizzarne le prestazioni

Una panoramica del sistema di archiviazione di Milvus e delle tecniche per valutarne e ottimizzarne le prestazioni

Apr 24, 20247 min read

Benvenuti nella nostra esplorazione di Milvus, il database vettoriale open-source noto per la sua impressionante scalabilità orizzontale e le sue prestazioni fulminee. Al cuore di Milvus si trova il suo robusto sistema di archiviazione, una base fondamentale per una persistenza e un'archiviazione dei dati affidabili. Questo sistema comprende diversi componenti essenziali: meta storage, log broker e object storage.

Questa guida approfondirà l'architettura di Milvus, analizzerà i suoi principali componenti di archiviazione ed esplorerà tecniche efficaci per valutarne le prestazioni.

Una panoramica dell'architettura di Milvus

Milvus adotta un'architettura distribuita che garantisce la separazione tra archiviazione e calcolo e supporta la scalabilità orizzontale per i suoi nodi di calcolo. Questa configurazione è organizzata in quattro livelli chiave: il livello di accesso, il servizio coordinatore, i nodi worker e l'archiviazione, ciascuno scalabile in modo indipendente e ottimizzato per il disaster recovery.

Milvus Architecture Overview.png

Livello di accesso: Questo livello front-end consiste in proxy stateless che gestiscono le richieste degli utenti e ottimizzano le risposte, fungendo da interfaccia utente principale del sistema.
Livello coordinatore: Agendo come il comando centrale del sistema, il servizio coordinatore gestisce la distribuzione delle attività, la topologia del cluster, il bilanciamento del carico e la gestione dei dati tra i nodi worker.
Nodi worker: Questi sono gli esecutori che elaborano i comandi Data Manipulation Language (DML) sotto la direzione del servizio coordinatore.
Archiviazione: Fondamentale per la persistenza dei dati, questo livello include meta storage, un log broker e object storage, garantendo integrità e disponibilità dei dati.

Componenti di archiviazione di Milvus

Milvus utilizza tre componenti principali di archiviazione per garantire integrità e disponibilità dei dati: meta storage, object storage e un log broker.

Meta storage

Il meta storage in Milvus archivia snapshot dei metadati, come gli schemi delle collection, gli stati dei nodi e i checkpoint di consumo dei messaggi. Data la necessità di alta disponibilità, forte coerenza e supporto alle transazioni, Milvus utilizza etcd come soluzione di meta-storage. Etcd è un archivio chiave-valore robusto e distribuito, cruciale per i sistemi distribuiti all'interno di Milvus. Gestisce attività come la registrazione dei servizi e i controlli di integrità, oltre alla preservazione dei metadati.

Object storage

L'object storage in Milvus gestisce l'archiviazione dei file di snapshot dei log, dei file di indice per dati scalari e vettoriali e dei risultati intermedi delle query. Milvus integra MinIO per l'object storage grazie alle sue alte prestazioni e alla compatibilità con Kubernetes, facilitando un funzionamento senza interruzioni in ambienti cloud come AWS S3 e Azure Blob Storage.

Log broker

Il log broker in Milvus adotta un sistema pub-sub con capacità di playback. È essenziale per la persistenza dei dati in streaming, l'esecuzione di query asincrone affidabili, le notifiche degli eventi e la restituzione dei risultati delle query. Garantisce inoltre l'integrità dei dati incrementali durante il ripristino dei nodi worker da guasti del sistema. A seconda del deployment, Milvus utilizza diversi strumenti di log broker. Le configurazioni Milvus Cluster utilizzano Pulsar o Kafka, mentre le versioni standalone di Milvus utilizzano in genere RocksDB.

Come valutare e ottimizzare le prestazioni dello storage di Milvus

Valutare e migliorare costantemente le prestazioni dello storage è cruciale.

Etcd: il Metadata Store di Milvus

Etcd è un archivio chiave-valore robusto e distribuito, progettato per sistemi distribuiti. In Milvus, etcd è un metadata store che archivia dati essenziali come gli schemi delle collection, gli stati dei nodi e i checkpoint di consumo dei messaggi.

La latenza di scrittura su disco è critica per le prestazioni di etcd; una velocità del disco lenta può aumentare significativamente la latenza delle richieste e mettere a rischio la stabilità del sistema. Raccomandiamo di sostenere almeno 500 IOPS sequenziali (operazioni di input/output al secondo) per prestazioni ottimali negli ambienti di produzione, assicurando che il 99% delle durate di fdatasync rimanga al di sotto di dieci millisecondi. Sebbene etcd richieda in genere solo una larghezza di banda del disco moderata, aumentare questa larghezza di banda può ridurre notevolmente i tempi di ripristino. Di conseguenza, raccomandiamo una larghezza di banda del disco di base di almeno 100MB/s per gli ambienti di produzione.

Per verificare se la tua soluzione di storage soddisfa questi criteri, considera di condurre valutazioni delle prestazioni utilizzando Fio, uno strumento di benchmarking del disco. Di seguito è riportata una guida su come utilizzare Fio per valutare le prestazioni del tuo storage.

Per prima cosa, assicurati che Fio sia installato sul tuo sistema. Quindi, esegui il seguente comando, specificando la directory in cui il tuo storage è montato come directory test-data. Questa directory dovrebbe trovarsi sotto il punto di connessione del tuo storage.

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Esamina i risultati per assicurarti che il 99% della durata di fdatasync sia inferiore a 10ms e che gli IOPS di scrittura siano superiori a 500. Se queste condizioni sono soddisfatte, il tuo storage offre prestazioni adeguate.

Di seguito è riportato un esempio dei risultati di output:

Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022
 write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
   clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
    lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
   clat percentiles (usec):
    |  1.00th=[    3],  5.00th=[    4], 10.00th=[    4], 20.00th=[    5],
    | 30.00th=[    6], 40.00th=[    9], 50.00th=[  233], 60.00th=[  343],
    | 70.00th=[  437], 80.00th=[  553], 90.00th=[  701], 95.00th=[  742],
    | 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],
    | 99.99th=[15533]
  bw (  KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207
  iops        : min=  726, max= 1106, avg=968.37, stdev=86.19, samples=207
 lat (usec)   : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%
 lat (usec)   : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%
 lat (msec)   : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%
 fsync/fdatasync/sync_file_range:
   sync (usec): min=309, max=21848, avg=741.93, stdev=489.64
   sync percentiles (usec):
    |  1.00th=[  392],  5.00th=[  437], 10.00th=[  474], 20.00th=[  529],
    | 30.00th=[  578], 40.00th=[  619], 50.00th=[  660], 60.00th=[  709],
    | 70.00th=[  742], 80.00th=[  791], 90.00th=[  988], 95.00th=[ 1369],
    | 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],
    | 99.99th=[11994]

Quando si distribuisce un cluster Milvus in ambienti cloud, selezionare il tipo appropriato di storage a blocchi per etcd è fondamentale a causa della sua sensibilità alle prestazioni del disco. I provider cloud offrono varie opzioni di storage a blocchi, ciascuna con caratteristiche prestazionali distinte adatte a carichi di lavoro diversi.

Di seguito sono riportati i tipi di volume e le metriche di prestazione raccomandati da vari provider cloud.


Provider cloud	Tipo di volume	DIMENSIONE	IOPS	Sync P99
AWS	gp3	20Gi	660	4.3ms
GCP	pd-ssd	20Gi	1262	1.3ms
Azure	PremiumV2	20Gi	705	2.6ms
Aliyun	cloud_essd	20Gi	1137	3.5ms

Puoi anche usare Fio per confermare che lo storage a blocchi scelto soddisfi i benchmark prestazionali necessari per il funzionamento ottimale di etcd all'interno del tuo deployment Milvus.

MinIO: strumento di Object Storage di Milvus

MinIO è una soluzione di object storage ad alte prestazioni, nativa per Kubernetes, ottimizzata per carichi di lavoro cloud-native. Milvus utilizza MinIO per archiviare file snapshot dei log, file di indice sia per dati scalari sia vettoriali, e risultati intermedi delle query.

Le prestazioni per l'object storage come MinIO sono valutate principalmente in base al throughput I/O piuttosto che agli IOPS. Questa metrica influisce in modo significativo su varie operazioni in Milvus, come il caricamento delle collection, la creazione degli indici e l'inserimento dei dati. Molti fattori influenzano le prestazioni di throughput di MinIO, tra cui la larghezza di banda di rete, l'ottimizzazione delle prestazioni del kernel Linux e le prestazioni delle singole unità disco. Le prestazioni del disco sono particolarmente cruciali.

Possiamo usare il comando dd per misurare le prestazioni di una singola unità. DD è uno strumento Unix che copia i dati da un file a un altro bit per bit. Offre varie opzioni per controllare la dimensione del blocco di ogni lettura e scrittura.

Nell'esempio seguente, quando si testa una singola unità NVMe con una dimensione del blocco di 16MB, l'opzione O_DIRECT per 64 conteggi genera prestazioni di scrittura superiori a 2GB al secondo per unità.

$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s

Nello stesso esempio, quando si testa una singola unità NVMe con una dimensione del blocco di 16MB, l'opzione O_DIRECT per 64 conteggi genera prestazioni di lettura superiori a 5GB al secondo per unità.

$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s

Quanto più elevate sono le prestazioni di lettura e scrittura dell'unità disco, tanto migliori saranno le prestazioni complessive di throughput di MinIO. Consigliamo di utilizzare unità di tipo SSD o NVMe come dischi di storage in una configurazione MinIO per risultati ottimali. Queste unità possono supportare efficacemente i requisiti di throughput elevato delle operazioni di MinIO. Evita di utilizzare appliance SAN/NAS per lo storage MinIO. Tali configurazioni spesso introducono problemi di concorrenza e colli di bottiglia prestazionali che possono degradare l'efficienza e la reattività del sistema.

Pulsar/Kafka: strumenti Log Broker di Milvus

Come menzionato sopra, Milvus utilizza diversi strumenti log broker adattati a modalità di deployment specifiche. Le configurazioni Milvus Cluster utilizzano Pulsar o Kafka, mentre le versioni standalone di Milvus utilizzano in genere RocksDB.

Sia Pulsar sia Kafka sono progettati per supportare lo storage persistente dei messaggi e fornire throughput elevato ai consumer di messaggi. Le loro prestazioni dipendono in modo critico dal tipo di storage su disco utilizzato, poiché si basano su operazioni di I/O su disco sequenziali.

Per Pulsar, dischi ad alte prestazioni sono essenziali per i file journal di BookKeeper al fine di garantire l'integrità e la durabilità dei dati, con SSD a bassa latenza particolarmente vantaggiosi a questo scopo. Sia Pulsar Ledgers sia Kafka sono ottimizzati per l'efficienza del disco, utilizzando la cache del file system e offrendo buone prestazioni con HDD e SSD. Tuttavia, per applicazioni sensibili alla latenza o deployment su larga scala, gli SSD offrono significativi vantaggi prestazionali.

Per ottimizzare le prestazioni, utilizza più dispositivi disco per Pulsar e Kafka. In particolare, per Pulsar, l'uso di dischi separati per il journal e lo storage generale consente ai bookie di isolare la latenza delle operazioni di scrittura da quella delle operazioni di lettura. Per garantire una latenza ottimale, non utilizzare le stesse unità per archiviare dati, log applicativi o altre attività del filesystem del sistema operativo. Queste unità possono essere configurate come un singolo volume usando RAID, oppure ogni unità può essere formattata e montata come directory propria. Lo storage collegato in rete (NAS) dovrebbe essere evitato a causa delle sue prestazioni inferiori, latenze più elevate e più variabili, e del potenziale di rappresentare un single point of failure.

Riepilogo

La nostra esplorazione approfondita del sistema di archiviazione Milvus offre una panoramica completa della sua architettura e dei suoi componenti, evidenziando i loro ruoli nel supportare la gestione e l’analisi dei dati su larga scala. Abbiamo analizzato i tre componenti principali di archiviazione di Milvus—meta storage, object storage e log broker—e fornito strategie per valutarne e migliorarne le prestazioni.

Aggiornato il Jul 13, 2026

Continua a leggere

A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again

James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.

Zilliz Cloud Now Available in AWS Europe (Ireland)

Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.

Vector Databases vs. Object-Relational Databases

Use a vector database for AI-powered similarity search; use an object-relational database for complex data modeling with both relational integrity and object-oriented features.