Servizio di streaming

Il servizio di streaming è un concetto per il modulo interno del sistema di streaming di Milvus, costruito attorno al registro di scrittura (WAL) per supportare varie funzioni legate allo streaming. Tra queste, l'ingestione/sottoscrizione di dati in streaming, il ripristino dello stato del cluster in caso di errore, la conversione dei dati in streaming in dati storici e le query sui dati in crescita. Dal punto di vista architetturale, il servizio di streaming è composto da tre componenti principali:

Arco distribuito di streaming

• Coordinatore di streaming: Un componente logico nel nodo coordinatore. Utilizza Etcd per la scoperta dei servizi per individuare i nodi di streaming disponibili ed è responsabile del binding del WAL ai nodi di streaming corrispondenti. Registra anche un servizio per esporre la topologia di distribuzione del WAL, consentendo ai client di streaming di conoscere il nodo di streaming appropriato per un determinato WAL.

• Cluster di nodi di streaming: Un cluster di nodi worker di streaming responsabili di tutte le attività di elaborazione dello streaming, come l'aggiunta di wal, il recupero dello stato e l'interrogazione dei dati in crescita.

• Client di streaming: Un client Milvus sviluppato internamente che incapsula funzionalità di base come la scoperta dei servizi e la verifica della disponibilità. Viene utilizzato per avviare operazioni come la scrittura di messaggi e la sottoscrizione.

Messaggio

Lo Streaming Service è un sistema di streaming guidato dai log, quindi tutte le operazioni di scrittura in Milvus (come DML e DDL) sono astratte come messaggi.

• A ogni messaggio il servizio di streaming assegna un campo Timestamp Oracle (TSO), che indica l'ordine del messaggio nel WAL. L'ordine dei messaggi determina l'ordine delle operazioni di scrittura in Milvus. In questo modo è possibile ricostruire l'ultimo stato del cluster dai log.

• Ogni messaggio appartiene a uno specifico VChannel (Virtual Channel) e mantiene alcune proprietà invarianti all'interno di quel canale per garantire la coerenza delle operazioni. Ad esempio, un'operazione di Insert deve sempre avvenire prima di un'operazione di DropCollection sullo stesso canale.

L'ordine dei messaggi in Milvus può assomigliare al seguente:

Ordine dei messaggi

Componente WAL

Per supportare la scalabilità orizzontale su larga scala, il WAL di Milvus non è un singolo file di log, ma un insieme di più log. Ciascun registro può supportare in modo indipendente la funzionalità di streaming per più canali V. In qualsiasi momento, un componente WAL può operare esattamente su un solo nodo di streaming; questo vincolo è garantito sia da un meccanismo di recinzione dello storage wal sottostante sia dal coordinatore dello streaming.

Altre caratteristiche del componente WAL sono:

• Gestione del ciclo di vita del segmento: In base a criteri quali condizioni di memoria/dimensioni del segmento/tempo di inattività del segmento, il WAL gestisce il ciclo di vita di ogni segmento.

• Supporto alle transazioni di base: Poiché ogni messaggio ha un limite di dimensione, il componente WAL supporta un semplice livello di transazione per promettere scritture atomiche a livello di VChannel.

• Scrittura di registri remoti ad alta corenza: Milvus supporta code di messaggi remote di terze parti come memoria WAL. Per mitigare la latenza di andata e ritorno (RTT) tra il nodo di streaming e l'archiviazione WAL remota e migliorare il throughput di scrittura, il servizio di streaming supporta le scritture di log simultanee. Mantiene l'ordine dei messaggi mediante sincronizzazione TSO e TSO, e i messaggi nel WAL vengono letti in ordine TSO.

• Buffer di scrittura anticipata: Dopo che i messaggi sono stati scritti nel WAL, vengono temporaneamente memorizzati in un buffer Write-Ahead. Ciò consente di leggere i registri senza dover recuperare i messaggi dal WAL remoto.

• Supporta più archivi WAL: Woodpecker, Pulsar, Kafka. Utilizzando Woodpecker con la modalità zero-disk, è possibile rimuovere la dipendenza dallo storage WAL remoto.

Archiviazione di recupero

Il componente Recovery Storage viene sempre eseguito sul nodo di streaming in cui si trova il componente WAL corrispondente.

• È responsabile della conversione dei dati di streaming in dati storici persistenti e della loro memorizzazione nell'object storage.

• Gestisce inoltre il recupero dello stato in memoria per il componente WAL sul nodo di streaming.

Storage di recupero

Delegatore di query

Il Query Delegator viene eseguito su ogni nodo di streaming ed è responsabile dell'esecuzione di query incrementali su un singolo shard. Genera piani di query, li inoltra ai nodi di query pertinenti e aggrega i risultati.

Inoltre, il Query Delegator è responsabile della trasmissione delle operazioni di cancellazione agli altri Query Nodes.

Il Query Delegator coesiste sempre con il componente WAL sullo stesso nodo di streaming. Tuttavia, se la collezione è configurata con multi-replica, allora N-1 delegatori saranno distribuiti sugli altri nodi di streaming.

Durata del WAL e attesa del pronto

Separando i nodi di calcolo dallo storage, Milvus può trasferire facilmente il WAL da un nodo di streaming a un altro, ottenendo un'elevata disponibilità del servizio di streaming.

durata del wal

Attesa per il pronto

Quando il WAL viene trasferito a un nuovo nodo di streaming, il client scoprirà che il vecchio nodo di streaming rifiuta alcune richieste. Nel frattempo, il WAL verrà recuperato nel nuovo nodo di streaming e il client attenderà che il wal sul nuovo nodo di streaming sia pronto per essere servito.

attendere che sia pronto