Elaborazione dei dati

Questo articolo fornisce una descrizione dettagliata dell'implementazione dell'inserimento dei dati, della costruzione degli indici e dell'interrogazione dei dati in Milvus.

Inserimento dei dati

In Milvus è possibile specificare un numero di shard per ogni raccolta, ogni shard corrisponde a un canale virtuale(vchannel). Come mostra la figura seguente, Milvus assegna a ogni vchannel del log broker un canale fisico(pchannel). Qualsiasi richiesta di inserimento/cancellazione in arrivo viene indirizzata agli shard in base al valore hash della chiave primaria.

La convalida delle richieste DML viene spostata al proxy perché Milvus non ha transazioni complicate. Il proxy richiede un timestamp per ogni richiesta di inserimento/cancellazione da TSO (Timestamp Oracle), che è il modulo di temporizzazione che si collega al coordinatore principale. Poiché il timestamp più vecchio viene sovrascritto da quello più recente, i timestamp vengono utilizzati per determinare la sequenza delle richieste di dati in corso di elaborazione. Il proxy recupera le informazioni in batch dal coordinatore dei dati, compresi i segmenti delle entità e le chiavi primarie, per aumentare il throughput complessivo ed evitare di sovraccaricare il nodo centrale.

Canali 1

Sia le operazioni DML (data manipulation language) che le operazioni DDL (data definition language) vengono scritte nella sequenza di log, ma alle operazioni DDL viene assegnato un solo canale a causa della loro bassa frequenza.

Canali 2

Icanali sono mantenuti nei nodi di log broker sottostanti. Ogni canale è fisicamente indivisibile e disponibile per un solo nodo. Quando la velocità di ingestione dei dati raggiunge il collo di bottiglia, bisogna considerare due cose: Se il nodo log broker è sovraccarico e deve essere scalato e se ci sono shard sufficienti per garantire il bilanciamento del carico per ogni nodo.

Sequenza di scrittura dei log

Il diagramma precedente racchiude i quattro componenti coinvolti nel processo di scrittura della sequenza di log: proxy, log broker, nodo dati e storage degli oggetti. Il processo prevede quattro attività: convalida delle richieste DML, pubblicazione-sottoscrizione della sequenza di log, conversione da log in streaming a snapshot di log e persistenza degli snapshot di log. I quattro compiti sono disaccoppiati l'uno dall'altro per assicurarsi che ogni compito sia gestito dal tipo di nodo corrispondente. I nodi dello stesso tipo sono resi uguali e possono essere scalati in modo elastico e indipendente per adattarsi a vari carichi di dati, in particolare a dati di streaming massicci e altamente fluttuanti.

Costruzione dell'indice

La costruzione dell'indice viene eseguita dal nodo indice. Per evitare la creazione frequente di indici per gli aggiornamenti dei dati, una raccolta in Milvus è ulteriormente suddivisa in segmenti, ciascuno con il proprio indice.

Costruzione dell'indice

Milvus supporta la costruzione di indici per ogni campo vettoriale, scalare e primario. Sia l'input che l'output della costruzione dell'indice sono collegati alla memorizzazione degli oggetti: Il nodo indice carica le istantanee del registro da indicizzare da un segmento (che si trova nella memoria degli oggetti) alla memoria, deserializza i dati e i metadati corrispondenti per costruire l'indice, serializza l'indice al termine della costruzione e lo scrive nuovamente nella memoria degli oggetti.

La costruzione dell'indice coinvolge principalmente operazioni vettoriali e matriciali e quindi richiede molto calcolo e memoria. I vettori non possono essere indicizzati in modo efficiente con i tradizionali indici ad albero, a causa della loro natura altamente dimensionale, ma possono essere indicizzati con tecniche più mature in questo campo, come gli indici a grafo o a cluster. Indipendentemente dal tipo, la costruzione di un indice comporta calcoli iterativi massicci per vettori di grandi dimensioni, come Kmeans o graph traverse.

A differenza dell'indicizzazione per i dati scalari, la costruzione di indici vettoriali deve sfruttare appieno l'accelerazione SIMD (istruzione singola, dati multipli). Milvus ha un supporto innato per i set di istruzioni SIMD, ad esempio SSE, AVX2 e AVX512. Data la natura "a singhiozzo" e ad alta intensità di risorse della creazione di indici vettoriali, l'elasticità diventa fondamentale per Milvus in termini economici. Le future versioni di Milvus esploreranno ulteriormente l'elaborazione eterogenea e il calcolo senza server per ridurre i relativi costi.

Inoltre, Milvus supporta anche il filtraggio scalare e l'interrogazione di campi primari. Ha indici incorporati per migliorare l'efficienza delle query, come gli indici del filtro Bloom, gli indici hash, gli indici ad albero e gli indici invertiti, e prevede di introdurre altri indici esterni, come gli indici bitmap e gli indici grezzi.

Interrogazione dei dati

L'interrogazione dei dati si riferisce al processo di ricerca in una collezione specifica del numero k di vettori più vicini a un vettore di destinazione o di tutti i vettori entro un intervallo di distanza specificato dal vettore. I vettori vengono restituiti insieme alla loro chiave primaria e ai campi corrispondenti.

Interrogazione dei dati

Una collezione in Milvus è suddivisa in più segmenti e i nodi di interrogazione caricano gli indici per segmento. Quando arriva una richiesta di ricerca, questa viene trasmessa a tutti i nodi di interrogazione per una ricerca simultanea. Ciascun nodo esegue una selezione dei segmenti locali, cerca i vettori che soddisfano i criteri e riduce e restituisce i risultati della ricerca.

I nodi di interrogazione sono indipendenti l'uno dall'altro in una ricerca di dati. Ogni nodo è responsabile solo di due compiti: caricare o rilasciare i segmenti seguendo le istruzioni della query coord; condurre una ricerca all'interno dei segmenti locali. Il proxy è responsabile della riduzione dei risultati della ricerca da ciascun nodo di query e della restituzione dei risultati finali al client.

Passaggio di consegne

Esistono due tipi di segmenti: segmenti in crescita (per i dati incrementali) e segmenti sigillati (per i dati storici). I nodi di interrogazione si iscrivono a vchannel per ricevere gli aggiornamenti recenti (dati incrementali) come segmenti in crescita. Quando un segmento in crescita raggiunge una soglia predefinita, il data coord lo sigilla e inizia la costruzione dell'indice. Successivamente, un'operazione di handoff avviata dal query coord trasforma i dati incrementali in dati storici. Query coord distribuisce i segmenti sigillati in modo uniforme tra tutti i nodi di query in base all'utilizzo della memoria, al sovraccarico della CPU e al numero di segmenti.

Il prossimo passo

• Imparare a usare il database vettoriale Milvus per le interrogazioni in tempo reale.
• Conoscere l'inserimento e la persistenza dei dati in Milvus.
• Imparare come vengono elaborati i dati in Milvus.