Panoramica dell'architettura di Milvus
Milvus è un database vettoriale open-source e cloud-native progettato per la ricerca di similarità ad alte prestazioni su enormi insiemi di dati vettoriali. Costruito sulla base delle più diffuse librerie di ricerca vettoriale, tra cui Faiss, HNSW, DiskANN e SCANN, consente applicazioni di intelligenza artificiale e scenari di recupero di dati non strutturati. Prima di procedere, è necessario familiarizzare con i principi di base dell'embedding retrieval.
Diagramma dell'architettura
Il diagramma seguente illustra l'architettura di alto livello di Milvus, mostrando il suo design modulare, scalabile e cloud-native con livelli di archiviazione e calcolo completamente disaggregati.
Diagramma_di_architettura
Principi architettonici
Milvus segue il principio della disaggregazione del piano dati e del piano di controllo, comprendendo quattro livelli principali che sono reciprocamente indipendenti in termini di scalabilità e disaster recovery. Questa architettura di storage condiviso con livelli di storage e di calcolo completamente disaggregati consente di scalare orizzontalmente i nodi di calcolo e di implementare Woodpecker come livello WAL a zero dischi per una maggiore elasticità e una riduzione dei costi operativi.
Separando l'elaborazione dei flussi in Streaming Node e l'elaborazione batch in Query Node e Data Node, Milvus raggiunge prestazioni elevate e soddisfa contemporaneamente i requisiti di elaborazione in tempo reale.
Architettura dettagliata dei livelli
Livello 1: 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.
Livello 2: Coordinatore
Il Coordinator è il cervello di Milvus. In qualsiasi momento, nell'intero cluster è attivo esattamente un Coordinatore, responsabile di mantenere la topologia del cluster, di programmare tutti i tipi di attività e di garantire la coerenza a livello di cluster.
Di seguito sono elencati alcuni dei compiti gestiti dal Coordinatore:
- Gestione DDL/DCL/TSO: 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 timestamp Oracle (TSO) e l'emissione di time ticker.
- Gestione del servizio di streaming: Lega il Write-Ahead Log (WAL) con i nodi di streaming e fornisce il rilevamento dei servizi per il servizio di streaming.
- Gestione delle query: Gestisce la topologia e il bilanciamento del carico per i nodi di query e fornisce e gestisce le viste di query di servizio per guidare l'instradamento delle query.
- Gestione dei dati storici: Distribuisce le attività offline, come la compattazione e la creazione di indici, ai Data Nodes e gestisce la topologia dei segmenti e delle viste dei dati.
Livello 3: Nodi lavoratori
Le braccia e le gambe. I nodi worker sono esecutori muti che seguono le istruzioni del coordinatore. 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 sono distribuiti su Kubernetes. Esistono tre tipi di nodi worker:
Nodo di streaming
Lo Streaming Node funge da "mini-cervello" a livello di shard, fornendo garanzie di coerenza a livello di shard e il ripristino degli errori basato sul WAL Storage sottostante. Nel frattempo, lo Streaming Node è anche responsabile dell'interrogazione dei dati in crescita e della generazione dei piani di query. Inoltre, gestisce anche la conversione dei dati in crescita in dati sigillati (storici).
Nodo di interrogazione
Il nodo Query carica i dati storici dall'object storage e fornisce l'interrogazione dei dati storici.
Nodo dati
Il nodo Dati è responsabile dell'elaborazione offline dei dati storici, come la compattazione e la creazione di indici.
Livello 4: archiviazione
Lo storage è l'ossatura del sistema, responsabile della persistenza dei dati. Comprende il meta storage, il log broker e l'object storage.
Meta storage
Il meta storage memorizza le istantanee dei metadati, come gli schemi 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, per cui 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.
Archiviazione WAL
Lo storage WAL (Write-Ahead Log) è il fondamento della durabilità e della coerenza dei dati nei sistemi distribuiti. Prima che qualsiasi modifica venga impegnata, viene registrata in un registro, assicurando che, in caso di guasto, sia possibile recuperare esattamente il punto in cui si è lasciato.
Le implementazioni WAL più comuni includono Kafka, Pulsar e Woodpecker. A differenza delle soluzioni tradizionali basate su disco, Woodpecker adotta un design cloud-native a zero dischi che scrive direttamente sullo storage a oggetti. Questo approccio è in grado di scalare senza problemi con le vostre esigenze e semplifica le operazioni eliminando l'overhead della gestione dei dischi locali.
Registrando in anticipo ogni operazione di scrittura, il livello WAL garantisce un meccanismo affidabile a livello di sistema per il ripristino e la coerenza, indipendentemente dalla complessità dell'ambiente distribuito.
Flusso di dati e categorie di API
Le API di Milvus sono classificate in base alla loro funzione e seguono percorsi specifici attraverso l'architettura:
| Categoria API | Operazioni | Esempi di API | Flusso dell'architettura |
|---|---|---|---|
| DDL/DCL | Schema e controllo dell'accesso | createCollection, dropCollection, hasCollection, createPartition | Livello di accesso → Coordinatore |
| DML | Manipolazione dei dati | insert, delete, upsert | Livello di accesso → Nodo di lavoro in streaming |
| DQL | Interrogazione dati | search, query | Livello di accesso → Nodo di lavoro batch (nodi di interrogazione) |
Esempio di flusso di dati: operazione di ricerca
- Il client invia una richiesta di ricerca tramite SDK/API RESTful
- Il Load Balancer instrada la richiesta verso il Proxy disponibile nel livello di accesso.
- Il proxy utilizza la cache di routing per determinare i nodi di destinazione; contatta il coordinatore solo se la cache non è disponibile.
- Il proxy inoltra la richiesta ai nodi di streaming appropriati, che si coordinano con i nodi di interrogazione per la ricerca di dati sigillati mentre eseguono localmente la ricerca di dati in crescita.
- I Query Nodes caricano i segmenti sigillati dall'Object Storage secondo necessità ed eseguono la ricerca a livello di segmento.
- I risultati della ricerca vengono ridotti a più livelli: I nodi di interrogazione riducono i risultati su più segmenti, i nodi di streaming riducono i risultati dei nodi di interrogazione e il proxy riduce i risultati di tutti i nodi di streaming prima di restituirli al client.
Esempio di flusso di dati: inserimento di dati
- Il client invia una richiesta di inserimento con dati vettoriali
- Il livello di accesso convalida e inoltra la richiesta al nodo di streaming.
- Il nodo di streaming registra l'operazione nello storage WAL per garantire la durata.
- I dati vengono elaborati in tempo reale e resi disponibili per le interrogazioni.
- Quando i segmenti raggiungono la capacità, lo Streaming Node attiva la conversione in segmenti sigillati
- Il Data Node gestisce la compattazione e costruisce indici in cima ai segmenti sigillati, memorizzando i risultati nell'Object Storage.
- I nodi di interrogazione caricano gli indici appena costruiti e sostituiscono i dati in crescita corrispondenti.
Cosa c'è dopo
- Esplorare i componenti principali per conoscere le specifiche dell'implementazione
- Imparare a conoscere i flussi di lavoro dell'elaborazione dei dati e le strategie di ottimizzazione
- Comprendere il modello di consistenza e le garanzie di transazione in Milvus