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 client 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 coordinatore: il coordinatore radice (root coord), il coordinatore dati (data coord) e il coordinatore delle 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

Le braccia e le gambe. I nodi di lavoro 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 di 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

Il nodo Query recupera i dati di log incrementali e li trasforma in segmenti crescenti abbonandosi al broker di log, carica i dati storici dallo storage a oggetti ed esegue ricerche ibride tra dati vettoriali e scalari.

Nodo dati

Il nodo dati recupera i dati di log incrementali iscrivendosi al log broker, elabora le richieste di mutazione e impacchetta i dati di log in snapshot di log e li memorizza nell'object storage.

Nodo indice

Il nodo indice costruisce gli indici. I nodi indice non devono essere 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. La memorizzazione dei metadati richiede una disponibilità estremamente elevata, una forte coerenza e il supporto delle transazioni, quindi Milvus ha scelto etcd per il meta storage. Milvus utilizza etcd anche per la registrazione dei servizi e il controllo dello stato di salute.

Archiviazione a oggetti

Lo storage 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 cluster utilizza Pulsar come log broker; Milvus standalone utilizza RocksDB come log broker. Inoltre, il log broker può essere facilmente sostituito con piattaforme di archiviazione di dati in streaming come Kafka.

Milvus è costruito intorno al log broker e 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.