Utilizzo del database vettoriale Milvus per le interrogazioni in tempo reale
Immagine di copertina
Questo articolo è stato scritto da Xi Ge e trascritto da Angela Ni.
Nel post precedente abbiamo parlato dell'inserimento e della persistenza dei dati in Milvus. In questo articolo continueremo a spiegare come i diversi componenti di Milvus interagiscono tra loro per completare l'interrogazione dei dati in tempo reale.
Di seguito sono elencate alcune risorse utili prima di iniziare. Si consiglia di leggerle prima per comprendere meglio l'argomento di questo post.
- Approfondimento sull'architettura di Milvus
- Modello di dati Milvus
- Il ruolo e la funzione di ciascun componente di Milvus
- Elaborazione dei dati in Milvus
- Inserimento e persistenza dei dati in Milvus
Caricare i dati sul nodo di interrogazione
Prima di eseguire una query, i dati devono essere caricati nei nodi di query.
Ci sono due tipi di dati che vengono caricati sul nodo di query: i dati in streaming dal log broker e i dati storici dall'object storage (chiamato anche storage persistente).
Diagramma di flusso
Il Data Coord è responsabile della gestione dei dati in streaming che vengono continuamente inseriti in Milvus. Quando un utente di Milvus chiama collection.load()
per caricare una collezione, il query coord interroga il data coord per sapere quali segmenti sono stati conservati nello storage e i loro checkpoint corrispondenti. Un checkpoint è un segno che indica che i segmenti persistiti prima del checkpoint sono consumati, mentre quelli dopo il checkpoint non lo sono.
Quindi, la query coord produce una strategia di allocazione basata sulle informazioni della data coord: per segmento o per canale. L'allocatore di segmenti è responsabile dell'allocazione dei segmenti nello storage persistente (dati batch) ai diversi nodi di interrogazione. Ad esempio, nell'immagine precedente, l'allocatore di segmenti assegna i segmenti 1 e 3 (S1, S3) al nodo di interrogazione 1, e i segmenti 2 e 4 (S2, S4) al nodo di interrogazione 2. L'allocatore di canali assegna diversi nodi di interrogazione per guardare più canali di manipolazione dei dati (DMChannels) nel log broker. Ad esempio, nell'immagine precedente, l'allocatore di canali assegna al nodo di query 1 il canale 1 (Ch1) e al nodo di query 2 il canale 2 (Ch2).
Con la strategia di allocazione, ogni nodo di query carica i dati del segmento e guarda i canali di conseguenza. Nel nodo di interrogazione 1 dell'immagine, i dati storici (dati batch) vengono caricati tramite gli allocati S1 e S3 dalla memoria persistente. Nel frattempo, il nodo di query 1 carica i dati incrementali (dati in streaming) abbonandosi al canale 1 del log broker.
Gestione dei dati nel nodo di interrogazione
Un nodo di interrogazione deve gestire sia i dati storici che quelli incrementali. I dati storici sono memorizzati in segmenti sigillati, mentre i dati incrementali sono memorizzati in segmenti crescenti.
Gestione dei dati storici
Le considerazioni da fare per la gestione dei dati storici sono principalmente due: bilanciamento del carico e failover del nodo di query.
Bilanciamento del carico
Ad esempio, come mostrato nell'illustrazione, al nodo di query 4 sono stati assegnati più segmenti sigillati rispetto agli altri nodi di query. È molto probabile che il nodo di query 4 diventi il collo di bottiglia che rallenta l'intero processo di interrogazione. Per risolvere questo problema, il sistema deve assegnare diversi segmenti del nodo di query 4 ad altri nodi di query. Questa operazione è chiamata bilanciamento del carico.
Failover del nodo di query
Un'altra situazione possibile è illustrata nell'immagine precedente. Uno dei nodi, il nodo di query 4, è improvvisamente inattivo. In questo caso, il carico (segmenti allocati al nodo di query 4) deve essere trasferito ad altri nodi di query funzionanti per garantire l'accuratezza dei risultati della query.
Gestione incrementale dei dati
Il nodo di interrogazione guarda i canali DMC per ricevere dati incrementali. In questo processo viene introdotto il diagramma di flusso. Per prima cosa filtra tutti i messaggi di inserimento dei dati. Questo per garantire che vengano caricati solo i dati di una determinata partizione. Ogni collezione in Milvus ha un canale corrispondente, che è condiviso da tutte le partizioni di quella collezione. Pertanto, è necessario un diagramma di flusso per filtrare i dati inseriti se un utente di Milvus ha bisogno di caricare solo i dati di una determinata partizione. Altrimenti, i dati di tutte le partizioni della collezione saranno caricati sul nodo di interrogazione.
Dopo essere stati filtrati, i dati incrementali vengono inseriti in segmenti crescenti e poi passati ai nodi temporali del server.
Diagramma di flusso
Durante l'inserimento dei dati, a ogni messaggio di inserimento viene assegnato un timestamp. Nel canale DMC mostrato nell'immagine precedente, i dati vengono inseriti in ordine, da sinistra a destra. Il timestamp per il primo messaggio di inserimento è 1; il secondo, 2; e il terzo, 6. Il quarto messaggio segnato in rosso non è un messaggio di inserimento, ma piuttosto un messaggio di timetick. Ciò significa che i dati inseriti i cui timestamp sono inferiori a questo timetick sono già presenti nel log broker. In altre parole, i dati inseriti dopo questo messaggio timetick dovrebbero avere tutti timestamp il cui valore è maggiore di questo timetick. Ad esempio, nell'immagine precedente, quando il nodo di interrogazione percepisce che il timetick corrente è 5, significa che tutti i messaggi di inserimento il cui valore di timestamp è inferiore a 5 sono tutti caricati sul nodo di interrogazione.
Il nodo temporale del server fornisce un valore tsafe
aggiornato ogni volta che riceve un timetick dal nodo di inserimento. tsafe
significa tempo di sicurezza e tutti i dati inseriti prima di questo momento possono essere interrogati. Ad esempio, se tsafe
= 9, tutti i dati inseriti con timestamp inferiori a 9 possono essere interrogati.
Interrogazione in tempo reale in Milvus
L'interrogazione in tempo reale in Milvus è abilitata dai messaggi di interrogazione. I messaggi di query vengono inseriti nel log broker tramite proxy. I nodi di interrogazione ottengono i messaggi di interrogazione osservando il canale di interrogazione nel log broker.
Messaggio di interrogazione
Messaggio di query
Un messaggio di query include le seguenti informazioni cruciali su una query:
msgID
: ID messaggio, l'ID del messaggio di query assegnato dal sistema.collectionID
: L'ID della collezione da interrogare (se specificato dall'utente).execPlan
: Il piano di esecuzione è utilizzato principalmente per il filtraggio degli attributi in una query.service_ts
: Il timestamp del servizio sarà aggiornato insieme atsafe
di cui sopra. Il timestamp del servizio indica il momento in cui il servizio è attivo. Tutti i dati inseriti prima diservice_ts
sono disponibili per la query.travel_ts
: Il timestamp del viaggio specifica un intervallo di tempo nel passato. L'interrogazione sarà condotta sui dati esistenti nel periodo di tempo specificato datravel_ts
.guarantee_ts
: Il timestamp di garanzia specifica un periodo di tempo dopo il quale la query deve essere condotta. La query verrà eseguita solo quandoservice_ts
>guarantee_ts
.
Interrogazione in tempo reale
Processo di interrogazione
Quando riceve un messaggio di interrogazione, Milvus valuta innanzitutto se il tempo di servizio corrente, service_ts
, è maggiore del timestamp di garanzia, guarantee_ts
, contenuto nel messaggio di interrogazione. In caso affermativo, la query viene eseguita. La query sarà condotta in parallelo sia sui dati storici che su quelli incrementali. Poiché può esserci una sovrapposizione di dati tra i dati in streaming e i dati batch, è necessaria un'azione chiamata "riduzione locale" per filtrare i risultati ridondanti della query.
Tuttavia, se il tempo di servizio corrente è inferiore al timestamp di garanzia in un messaggio di query appena inserito, il messaggio di query diventerà un messaggio irrisolto e attenderà di essere elaborato finché il tempo di servizio non diventerà maggiore del timestamp di garanzia.
I risultati delle query vengono infine inviati al canale dei risultati. Il proxy ottiene i risultati della query da quel canale. Allo stesso modo, il proxy effettuerà una "riduzione globale" perché riceve i risultati da più nodi di interrogazione e i risultati delle interrogazioni potrebbero essere ripetitivi.
Per garantire che il proxy abbia ricevuto tutti i risultati della query prima di restituirli all'SDK, il messaggio di risultato terrà anche un registro delle informazioni, compresi i segmenti sigillati ricercati, i canali DMC ricercati e i segmenti sigillati globali (tutti i segmenti su tutti i nodi di query). Il sistema può concludere che il proxy ha ricevuto tutti i risultati della query solo se sono soddisfatte entrambe le condizioni seguenti:
- L'unione di tutti i segmenti sigillati ricercati registrati in tutti i messaggi di risultato è maggiore dei segmenti sigillati globali,
- Tutti i canali DMC della collezione sono stati interrogati.
Infine, il proxy restituisce i risultati finali dopo la "riduzione globale" all'SDK Milvus.
Informazioni sulla serie Deep Dive
Con l'annuncio ufficiale della disponibilità generale di Milvus 2.0, abbiamo organizzato questa serie di blog Milvus Deep Dive per fornire un'interpretazione approfondita dell'architettura e del codice sorgente di Milvus. Gli argomenti trattati in questa serie di blog includono:
- Caricare i dati sul nodo di interrogazione
- Gestione dei dati nel nodo di interrogazione
- Interrogazione in tempo reale in Milvus
- Informazioni sulla serie Deep Dive
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word