Disaggregazione storage/computing

Seguendo il principio della disaggregazione del piano dati e del piano di controllo, Milvus comprende quattro livelli che sono reciprocamente indipendenti in termini di scalabilità e disaster recovery.

Livello di accesso

Composto da un gruppo di proxy stateless, il livello di accesso è il livello frontale del sistema e l'endpoint per gli utenti. Convalida le richieste dei clienti e riduce i risultati restituiti:

• Il proxy è di per sé stateless. Fornisce un indirizzo di servizio unificato utilizzando componenti di bilanciamento del carico come Nginx, Kubernetes Ingress, NodePort e LVS.
• Poiché Milvus impiega un'architettura di elaborazione massicciamente parallela (MPP), il proxy aggrega e post-elabora i risultati intermedi prima di restituire i risultati finali al cliente.

Servizio coordinatore

Il servizio di coordinamento assegna i compiti ai nodi worker e funziona come cervello del sistema. Tra i compiti che si assume ci sono la gestione della topologia del cluster, il bilanciamento del carico, la generazione dei timestamp, la dichiarazione dei dati e la gestione dei dati.

Esistono tre tipi di coordinatori: il coordinatore radice (root coord), il coordinatore dati (data coord) e il coordinatore di query (query coord).

Coordinatore radice (root coord)

Il root coord gestisce le richieste del linguaggio di definizione dei dati (DDL) e del linguaggio di controllo dei dati (DCL), come la creazione o l'eliminazione di collezioni, partizioni o indici, nonché la gestione di TSO (timestamp Oracle) e l'emissione di ticker temporali.

Coordinatore di query (query coord)

Query coord gestisce la topologia e il bilanciamento del carico per i nodi di interrogazione e il passaggio da segmenti in crescita a segmenti chiusi.

Coordinatore dei dati (data coord)

Il coordinatore dei dati gestisce la topologia dei nodi dati e dei nodi indice, mantiene i metadati e attiva le operazioni di flush, compattazione e creazione di indici e altre operazioni in background sui dati.

Nodi lavoratori

I nodi worker sono esecutori "muti" che seguono le istruzioni del servizio coordinatore ed eseguono i comandi del linguaggio di manipolazione dei dati (DML) dal proxy. I nodi worker sono stateless grazie alla separazione tra storage e calcolo e possono facilitare lo scale-out del sistema e il disaster recovery quando vengono distribuiti su Kubernetes. Esistono tre tipi di nodi worker:

Nodo di interrogazione

I nodi di interrogazione recuperano i dati di log incrementali e li trasformano in segmenti crescenti abbonandosi al broker di log, caricano i dati storici dallo storage a oggetti ed eseguono ricerche ibride tra dati vettoriali e scalari.

Nodo dati

I nodi dati recuperano i dati di log incrementali iscrivendosi al log broker, elaborano le richieste di mutazione e impacchettano i dati di log in snapshot di log e li archiviano nell'object storage.

Nodo indice

I nodi indice costruiscono gli indici. Non è necessario che siano residenti in memoria e possono essere implementati con il framework serverless.

Archiviazione

Lo storage è l'ossatura del sistema, responsabile della persistenza dei dati. Comprende il meta storage, il log broker e l'object storage.

Meta-archiviazione

Il meta storage memorizza le istantanee dei metadati, come lo schema di raccolta e i checkpoint di consumo dei messaggi. L'archiviazione dei metadati richiede una disponibilità estremamente elevata, una forte coerenza e il supporto delle transazioni, quindi Milvus ha scelto etcd per questo scopo. Milvus utilizza etcd anche per la registrazione dei servizi e i controlli sullo stato di salute.

Archiviazione a oggetti

L'archiviazione a oggetti memorizza i file snapshot dei log, i file indice per i dati scalari e vettoriali e i risultati intermedi delle query. Milvus utilizza MinIO come storage a oggetti e può essere facilmente distribuito su AWS S3 e Azure Blob, due dei servizi di storage più popolari ed economici al mondo. Tuttavia, lo storage a oggetti ha un'elevata latenza di accesso e si fa pagare in base al numero di query. Per migliorare le prestazioni e ridurre i costi, Milvus intende implementare la separazione dei dati cold-hot su un pool di cache basato su memoria o SSD.

Broker di log

Il log broker è un sistema pub-sub che supporta la riproduzione. È responsabile della persistenza dei dati in streaming e della notifica degli eventi. Inoltre, garantisce l'integrità dei dati incrementali quando i nodi worker si riprendono da un guasto del sistema. Milvus Distributed utilizza Pulsar come log broker, mentre Milvus Standalone utilizza RocksDB. Il log broker può essere facilmente sostituito con piattaforme di archiviazione di dati in streaming come Kafka.

Milvus segue il principio "log as data", quindi Milvus non mantiene una tabella fisica ma garantisce l'affidabilità dei dati attraverso la persistenza dei log e gli snapshot dei log.

Meccanismo di log

Il log broker è la spina dorsale di Milvus. È responsabile della persistenza dei dati e della disaggregazione in lettura e scrittura, grazie al suo meccanismo innato pub-sub. L'illustrazione precedente mostra una rappresentazione semplificata del meccanismo, in cui il sistema è diviso in due ruoli, il log broker (per mantenere la sequenza dei log) e il log subscriber. Il primo registra tutte le operazioni che modificano gli stati della collezione; il secondo sottoscrive la sequenza di log per aggiornare i dati locali e fornisce servizi sotto forma di copie in sola lettura. Il meccanismo pub-sub lascia spazio anche all'estendibilità del sistema in termini di acquisizione dei dati di modifica (CDC) e di distribuzione distribuita a livello globale.

Cosa c'è dopo

• Per maggiori dettagli sull'architettura di Milvus, leggere Componenti principali.