Comprendere i modelli di consistenza per i database vettoriali
I sistemi distribuiti per le tue applicazioni di ricerca vettoriale stanno diventando indispensabili, dalla scalabilità e tolleranza ai guasti fino a prestazioni migliorate e accessibilità globale. I principi fondamentali che rendono i sistemi distribuiti la spina dorsale di applicazioni resilienti e ad alte prestazioni ci impongono di considerare i compromessi tra coerenza, disponibilità e latenza.
Ad esempio, la coerenza è fondamentale per alcuni casi d’uso della ricerca vettoriale nella tua applicazione distribuita. Non sarebbe un problema se interrogassi dati che ti aspettavi fossero presenti ma che invece non ci fossero? Succederebbe se i tuoi dati non fossero coerenti tra tutte le repliche presenti nei tuoi sistemi distribuiti. In superficie, sembra semplice. Certo, i miei dati dovrebbero essere lì dopo che li ho inseriti e replicati su più nodi. Ma quando dovrebbero essere lì? Come fai a garantirlo?
In risposta al problema della coerenza, il database vettoriale completamente distribuito Milvus offre la Coerenza Regolabile. Milvus ha un’architettura unica che ti consente di scalare orizzontalmente il modo in cui scrivi i tuoi dati e garantire la coerenza senza dover usare strumenti aggiuntivi. Sfruttando un’infrastruttura distribuita, Milvus è un sistema pub-sub debolmente accoppiato, il che significa che la coerenza può essere facilmente gestita e regolata tramite timestamp.
In questo articolo, esamineremo:
Che cos’è la coerenza?
- Requisiti di coerenza dei database vettoriali
Coerenza, disponibilità e partizioni
Quali livelli di coerenza offre Milvus?
Coerenza eventuale
Coerenza di sessione
Coerenza limitata
Coerenza forte
Riepilogo della comprensione della coerenza per i database vettoriali
Che cos’è la coerenza?
Una delle definizioni di coerenza è “il raggiungimento di un livello di prestazioni che non varia molto in qualità nel tempo.” Per quanto riguarda la coerenza del tuo database distribuito, ti fornisce i dati più accurati e aggiornati che richiedi. Ecco perché Milvus offre la possibilità di “regolare” la coerenza in base a quanto devono essere recenti i dati a cui vuoi accedere.
Diversi tipi di database hanno requisiti di coerenza aggiuntivi. Ad esempio, i database non relazionali hanno spesso requisiti ACID (atomicità, coerenza, isolamento e durabilità) “eventuali” o rilassati. Potresti ottenere dati parzialmente aggiornati quando lavori con database NoSQL.
D’altra parte, i database SQL conformi ad ACID come Postgres hanno requisiti di coerenza diversi. Questi database garantiscono che non riceverai dati parzialmente aggiornati imponendo la coerenza a livello di modifica. Quindi, quando esegui una query, devi attendere che l’intera modifica venga completata per ottenere i dati derivanti da quella modifica.
Requisiti di coerenza dei database vettoriali
Nel frattempo, i database vettoriali hanno requisiti di coerenza diversi rispetto ai database relazionali o non relazionali. Puoi avere dati validi anche prima che una modifica in batch sia completamente terminata. Tuttavia, non puoi avere dati parzialmente aggiornati. I database vettoriali operano secondo il teorema PACELC. È esattamente ciò che fa Milvus tramite la sua configurazione pub-sub. Ogni riga viene “pubblicata” attraverso la pipeline di scrittura e “sottoscritta” dai nodi necessari. Questa configurazione ti consente di cercare o interrogare Milvus e ottenere risultati basati sulle differenze nei timestamp.
Coerenza, disponibilità e partizioni (CAP)
Il teorema CAP è un concetto di informatica che afferma l’esistenza di un compromesso tra coerenza, disponibilità e tolleranza alle partizioni. Puoi scegliere solo due dei tre elementi. Quando si verifica una partizione di rete, devi scegliere tra disponibilità e coerenza. Un sistema che richiede un’elevata disponibilità dei dati richiede repliche, il che rende la coerenza più difficile.
Il teorema PACELC è un’estensione del teorema CAP. È il teorema CAP + else + latenza + consistenza. Afferma che non è necessario preoccuparsi dei compromessi tra disponibilità e consistenza in un sistema senza partizioni di rete. Tuttavia, devi comunque scegliere tra latenza e consistenza, poiché devi attendere che i dati si sincronizzino.
Quali livelli di consistenza offre Milvus?
Milvus offre quattro diversi livelli di consistenza. In ordine dal meno al più consistente, sono: Eventual, Session, Bounded e Strong. La consistenza eventuale significa che sei disposto ad aspettare fino a “... quando sarà”. La consistenza forte significa che vuoi includere tutti i dati nel momento in cui invii la query. Session e Bounded sono intermedi. Approfondiamo.
Riesci a indovinare quali emoji rappresentano quali livelli?
Consistenza eventuale
La consistenza eventuale (o “Eventually”) significa che i dati saranno alla fine consistenti su tutte le repliche. Usiamo la consistenza eventuale quando ci interessa più la velocità di un’applicazione che avere i dati più aggiornati o query ripetibili. Per Milvus, questo tipo di consistenza significa che implementiamo il requisito di consistenza saltando il controllo del timestamp durante la lettura.
Un esempio di caso d’uso di questo tipo di livello di consistenza potrebbe essere il recupero delle recensioni dei prodotti. La maggior parte degli utenti non leggerà tutte le recensioni di un prodotto, quindi ottenere le recensioni più aggiornate non è di grande importanza. Se vuoi creare una collection con questo livello di consistenza, il codice seguente mostra come creare una collection con consistenza di livello “Eventually” in Milvus. È importante notare che consistency_level si aspetta la parola chiave “Eventually.”
Consistenza di sessione
La consistenza di sessione significa che ogni sessione è almeno aggiornata in base alle proprie scritture. Una sessione può avere più repliche, quindi questo è il primo compromesso latenza-consistenza. Usiamo la consistenza di sessione quando dobbiamo salvare il nostro stato solo una volta per sessione. Milvus implementa questo tipo di consistenza impostando il timestamp richiesto sull’ora dell’ultima scrittura.
In pratica, puoi usare la consistenza di sessione quando hai bisogno che ogni istanza client-server abbia consistenza dei dati. Un esempio è un server di videogiochi. Non vuoi permettere ai giocatori di fare glitch infiniti, quindi devi garantire la consistenza all’interno di ogni istanza o sessione. Il codice seguente mostra come eseguire una ricerca vettoriale usando un livello di consistenza “Session.”
Consistenza limitata
La consistenza limitata (o bounded staleness) è un passo “più consistente” rispetto alla consistenza di sessione. Con la consistenza di livello “Session”, le altre istanze, o sessioni, sono trattate come eventualmente consistenti. La bounded staleness obbliga ogni istanza e replica a sincronizzarsi entro un certo periodo.
Un esempio di bounded staleness potrebbe essere un motore di raccomandazione video. Gli utenti non avranno bisogno degli ultimi video immediatamente, ma dovrebbero vederli presto. Anche le modifiche di un utente dovrebbero diffondersi prontamente al di fuori della sua sessione. Il codice seguente mostra come cercare in Milvus con un requisito di consistenza limitata.
Consistenza forte
La consistenza forte rende i dati disponibili nel momento in cui li inserisci. Naturalmente, questa consistenza comporta un compromesso in termini di latenza: dobbiamo attendere che il sistema cambi. In pratica, Milvus implementa questa consistenza impostando il timestamp di lettura richiesto sull’ultimo aggiornamento nel sistema. Questo aumenta la nostra latenza di ricerca a un minimo di 200 ms.
Un esempio di consistenza forte potrebbe essere il rilevamento delle frodi. Se qualcuno usa il tuo conto bancario per una frode, devi saperlo e bloccarlo immediatamente. Le applicazioni che necessitano di una configurazione di tipo read-after-write richiedono una consistenza forte. Il codice seguente mostra come interrogare una collection (ricerca filtrata senza vettori) con un requisito di consistenza Strong.
Riepilogo della comprensione della consistenza per i database vettoriali
La consistenza dei dati è una delle cose più importanti da considerare quando si crea un’applicazione distribuita. Ogni applicazione ha bisogno di dati, e tutti i dati necessitano di alcuni requisiti di consistenza. Per quanto riguarda i dati vettoriali, dobbiamo valutare la consistenza dei dati rispetto ai requisiti di consistenza basati su righe.
In linea con questi requisiti, Milvus offre quattro livelli di consistenza basati sull’apposizione di timestamp ai dati. Nota che questo è possibile solo per la consistenza basata su righe e non è implementato nei database SQL o NoSQL. I quattro livelli di consistenza, dal più al meno consistente, sono strong, bound, session ed eventually.
La consistenza forte garantisce di avere tutti i dati più aggiornati disponibili in tutto il sistema (quasi) immediatamente. Questo livello di consistenza si ottiene aggiornando il timestamp al timestamp di inserimento più recente, assicurando di poter interrogare tutti i dati inseriti fino al momento della richiesta.
La consistenza limitata garantisce di avere tutti i dati più aggiornati in tutto il sistema entro un periodo fisso. La consistenza limitata imposta il timestamp da controllare entro un certo periodo dalla richiesta. In questo modo, abbiamo tutti i dati entro un periodo limitato. La consistenza limitata è l’impostazione predefinita in Milvus.
La consistenza di sessione garantisce di avere tutti i dati più aggiornati nella sessione corrente su cui stiamo lavorando. Milvus raggiunge questo livello di consistenza impostando il timestamp per ogni istanza all’ultima volta in cui quell’istanza ha inserito dati. In questo modo, abbiamo tutti i dati inseriti in (almeno) l’istanza che usiamo.
Infine, la consistenza eventuale (con keyword “Eventually”) garantisce che, prima o poi, i dati in tutto il sistema saranno tutti consistenti. I dati possono proliferare e vengono sincronizzati con le repliche alla velocità che ha senso. Sebbene si rinunci a una parte della consistenza dei dati, in cambio si ottengono maggiore disponibilità e prestazioni. In pratica, questo livello di consistenza non richiede molto tempo. Milvus implementa la consistenza eventuale saltando il controllo del timestamp ed eseguendo immediatamente ricerche o query.
Continua a leggere
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Expanding Our Global Reach: Zilliz Cloud Launches in Azure Central India
Zilliz Cloud expands to Azure Central India. This new region helps customers meet compliance, reduce latency, and optimize cloud costs when building AI applications.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.