Un'introduzione all'architettura di Milvus
In un sondaggio condotto su oltre 1200 utenti, abbiamo individuato una sfida chiave ricorrente: la scalabilità. Come possiamo scalare le nostre operazioni vettoriali? Questa domanda porta allo sviluppo di Milvus come sistema distribuito. I database vettoriali, a differenza dei database tradizionali, hanno requisiti d’uso diversi. Tre differenze principali ci hanno motivato a costruire da zero un database vettoriale cloud-native.
Primo, i dati vettoriali non richiedono transazioni complesse.
Secondo, la diversità dei casi d’uso richiede un compromesso regolabile tra prestazioni e coerenza.
Terzo, alcune operazioni sui dati vettoriali sono computazionalmente costose, rendendo necessaria un’allocazione elastica delle risorse.
Milvus raggiunge la scalabilità orizzontale grazie alla sua progettazione deliberata come sistema distribuito. Sebbene i database a istanza singola possano scalare fino a un certo punto, presto diventano limitati dall’hardware. La capacità di scalabilità orizzontale di Milvus supera questo problema, consentendo al database di estendersi su più istanze. Esistono due modi per scalare orizzontalmente un database: integrare direttamente la funzionalità nel database o implementare manualmente i processi di scalabilità.
Con Milvus, la funzionalità di scalabilità è integrata nel sistema. Sebbene tu possa gestire la scalabilità autonomamente, non è una soluzione ideale a meno che il tuo lavoro mission-critical non riguardi la scalabilità dei database. Esaminiamo tre architetture e due scelte di progettazione della ricerca che rendono Milvus così scalabile.
Architettura di sistema cloud-native
La maggior parte dei team software non effettua più il deploy sui server nella sala server. Perché? I cloud pubblici disponibili (AWS, Azure, GCP, ecc.) consentono ai team software di muoversi più rapidamente. Milvus è costruito per sfruttare la flessibilità offerta dal lavoro sul cloud.
Milvus contiene quattro livelli: accesso, coordinamento, worker e storage. I nodi di accesso stateless danno accesso al sistema. I worker e i coordinatori sono progettati secondo un pattern serverless. I coordinatori stateful attivano e disattivano worker stateless in base alle necessità. Il livello di storage memorizza i dati vettoriali e tutte le informazioni necessarie al funzionamento del sistema.
Separazione delle responsabilità
Quando si lavora con un database vettoriale, ci sono tre principali aree di responsabilità: interrogazione, ingestione dei dati e indicizzazione. Queste tre funzionalità scaleranno sempre in misura diversa e in momenti diversi. Milvus fornisce tre diversi tipi di nodi che possono scalare indipendentemente.
I nodi di query gestiscono la funzionalità di query, il che significa che devono avere memoria sufficiente per contenere gli indici in memoria per più segmenti. I segmenti sono blocchi di dati di una dimensione predefinita che Milvus utilizza per efficienza e scalabilità. I nodi di query aiutano anche a parallelizzare la ricerca utilizzando parte della loro capacità di calcolo e memoria per delegare, aggregare ed elaborare i risultati di ricerca provenienti da più segmenti, molti dei quali possono essere contenuti su altri nodi.
Man mano che i dati arrivano, entrano sia nei nodi di query sia nei nodi dati. Questi nodi conservano i dati in segmenti in crescita che non hanno ancora raggiunto il loro limite di dimensione. Dopo che il segmento raggiunge la capacità, il nodo di query rilascia quei dati e li sostituisce con l’indice generato.
I nodi dati gestiscono l’ingestione dei dati. Dopo che un segmento raggiunge il suo limite di dimensione con un nodo dati, viene “sigillato.” I segmenti sigillati vengono quindi scaricati nello storage permanente dai nodi dati e di query. Una volta che i dati vengono scaricati nel livello di storage, i coordinatori notificano un nodo indice.
I nodi indice costruiscono gli indici. Quando un nodo indice riceve una notifica, legge il segmento di dati dal livello di storage. Questa configurazione ci consente naturalmente di lavorare con meno dati durante la creazione dell’indice. Poiché il nodo indice legge i dati dallo storage, può leggere solo gli attributi di cui ha bisogno per sviluppare gli indici.
Coerenza di scrittura su larga scala
Una parte naturale della scalabilità è imbattersi in problemi di coerenza. Una volta avviata la seconda replica o istanza di Milvus o di qualsiasi altro sistema di database, ci si trova immediatamente di fronte a un problema di coerenza dei dati. È necessario garantire un accordo a livello di sistema su quanto i dati debbano essere coerenti.
Milvus dispone di molte opzioni per regolare la coerenza dei dati integrate nel sistema. Milvus è un sistema pub/sub. Il blocco di archiviazione dei messaggi funge da sistema di pubblicazione, assegnando un timestamp a ogni elemento di dati che passa attraverso il sistema. I nodi di query e dati leggono quindi questo registro di pubblicazione come subscriber.
La scalabilità della scrittura implica scalare il numero di shard che agiscono da writer. Quando i dati entrano, il loro ID viene sottoposto a hashing, e l’hash determina quale shard scriverà quell’elemento di dati.
Segmenti di dati per la ricerca parallela
Come accennato in precedenza, Milvus crea indici individuali su quantità predefinite di dati chiamate “segmenti.” Per impostazione predefinita, Milvus crea segmenti su 512MB di dati, che puoi adattare alle tue esigenze.
Perché creiamo segmenti e costruiamo indici in questo modo? Per maggiore flessibilità, scalabilità e facilità di mutazione. Gli indici sono modi per accedere ai dati. Immagina di creare un indice su un dataset iniziale. In uno scenario reale, i tuoi dati cambiano nel tempo, quindi dovrai continuare ad aggiungere dati. Poiché l’indice iniziale è stato costruito solo sui dati iniziali, non aiuta con i nuovi dati.
La soluzione razionale a questo problema di indicizzazione sarebbe costruire continuamente nuovi indici a un intervallo predefinito (come la quantità di nuovi dati aggiunti). Milvus implementa questa soluzione su più istanze e repliche.
Questa configurazione a segmenti fornisce una soluzione efficiente all’indicizzazione inefficiente e rende le query più scalabili. Poiché gli indici costruiti su segmenti di dati separati non dipendono l’uno dall’altro, possiamo eseguire ricerche su di essi in parallelo, limitati solo dall’hardware.
Optare per una dimensione del segmento maggiore migliora l’efficienza di ogni operazione di ricerca; tuttavia, è essenziale notare che questa scelta comporta anche costi maggiori associati alla compattazione e alla ricostruzione degli indici.
Ricerca dei metadati con prefiltraggio
Il filtraggio dei metadati è una funzionalità importante per molte persone. Questa funzionalità consente di cercare solo vettori provenienti da date specifiche, da autori specifici o con valori di attributi specifici. Quando si progetta un’applicazione di ricerca vettoriale, è possibile inserire il filtraggio dei metadati prima o dopo la funzionalità di ricerca vettoriale.
Prima di eseguire una ricerca vettoriale, Milvus genera una bitmask sui metadati. Questa operazione di prefiltraggio è lineare nel tempo. Milvus esamina i dati una volta e verifica se i metadati corrispondono o meno all’espressione di filtro fornita. Il prefiltraggio dei metadati riduce il volume di dati sottoposti alla ricerca vettoriale, rendendo l’operazione di ricerca vettoriale più efficiente.
Nella prossima versione di Milvus 2.4, supporteremo l’indice invertito con tantivy, e la velocità di prefiltraggio aumenterà drasticamente.
Riepilogo
Milvus adotta un’architettura di sistema distribuito composta da quattro livelli: accesso, coordinamento, worker e archiviazione. Considerati i diversi casi d’uso dei database vettoriali, è essenziale un’infrastruttura adattabile e in evoluzione. Milvus modella il suo componente di ingestione dei dati in linea con questo requisito come un sistema pub/sub (publish-subscribe).
Modellare l’ingestione dei dati come un servizio pub/sub ci offre flessibilità consentendo un paradigma di servizio disaccoppiato e aiuta con la coerenza dei dati. Il servizio di “pubblicazione” contrassegna ogni elemento di dati con un timestamp come parte della funzionalità di coerenza.
Per quanto riguarda le tre aree di interesse (query, ingestione dei dati e indicizzazione) in un database vettoriale, Milvus le separa tutte. Ognuna delle tre operazioni ha il proprio nodo dedicato. Puoi avviare e arrestare i nodi in modo indipendente, consentendo a Milvus di scalare in base alla quantità di dati che hai e al modello di utilizzo.
Garantire la coerenza dei dati è uno dei compiti più impegnativi man mano che la quantità di dati a disposizione aumenta. Milvus affronta questa sfida attraverso l’uso degli “shard”. I dati in ingresso vengono sottoposti a hashing e poi suddivisi in uno shard in base al relativo hash. Milvus offre una consistenza configurabile con quattro livelli tra cui scegliere, per bilanciare la rapidità con cui la ricerca risponde e la velocità con cui i dati vengono replicati tra le molte istanze del database.
La scrittura dei dati su larga scala utilizza più shard. La lettura dei dati su larga scala utilizza segmenti. Gli indici vengono costruiti sui singoli segmenti. Ogni segmento può ora essere cercato in parallelo al momento della query, riducendo enormemente il tempo di ricerca per grandi quantità di dati.
Quando si cercano dati, è probabile che si voglia poterli filtrare in qualche modo. Milvus implementa il filtraggio dei metadati come operazione di pre-filtraggio. Applica quindi una bitmask al dataset durante la ricerca vettoriale e salta tutti i vettori che non corrispondono. Questo approccio può ridurre significativamente il tempo di ricerca se molti vettori vengono esclusi dal filtro.
L’architettura unica di Milvus offre molti vantaggi, soprattutto lo scaling orizzontale. È progettata meticolosamente come database vettoriale cloud-native per un rapido scaling orizzontale, mantenendo al contempo prestazioni ottimali. Il design architetturale deliberatamente disaccoppiato rende facile far evolvere Milvus nel tempo e consente flessibilità. Questa adattabilità si rivela cruciale, data la crescente importanza dei database vettoriali e la gamma in espansione di casi d’uso a cui rispondono.
Continua a leggere
Migrating from S3 Vectors to Zilliz Cloud: Unlocking the Power of Tiered Storage
Learn how Zilliz Cloud bridges cost and performance with tiered storage and enterprise-grade features, and how to migrate data from AWS S3 Vectors to Zilliz Cloud.
8 Latest RAG Advancements Every Developer Should Know
Explore eight advanced RAG variants that can solve real problems you might be facing: slow retrieval, poor context understanding, multimodal data handling, and resource optimization.
Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty
Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.