Frustrato dai nuovi dati? Il nostro database vettoriale può aiutarti
Nell’era dei Big Data, quali tecnologie e applicazioni di database verranno alla ribalta? Quale sarà il prossimo punto di svolta?
Con i dati non strutturati che rappresentano circa l’80-90% di tutti i dati archiviati, cosa dovremmo fare con questi data lake in crescita? Si potrebbe pensare di utilizzare metodi analitici tradizionali, ma questi non riescono a estrarre informazioni utili, se ne estraggono affatto. Per rispondere a questa domanda, i "Tre Moschettieri" del team di Ricerca e Sviluppo di Zilliz, il Dr. Rentong Guo, il Sig. Xiaofan Luan e il Dr. Xiaomeng Yi, hanno scritto insieme un articolo per discutere la progettazione e le sfide affrontate nella costruzione di un sistema di database vettoriale general-purpose.
Questo articolo è stato incluso in Programmer, una rivista prodotta da CSDN, la più grande community di sviluppatori software in Cina. Questo numero di Programmer include anche articoli di Jeffrey Ullman, destinatario del Turing Award 2020, Yann LeCun, destinatario del Turing Award 2018, Mark Porter, CTO di MongoDB, Zhenkun Yang, fondatore di OceanBase, Dongxu Huang, fondatore di PingCAP, ecc.
Di seguito condividiamo con voi l’articolo integrale:
Progettazione e pratica di sistemi di database vettoriali general-purpose orientati all’AI
Introduzione
Le applicazioni dati moderne possono gestire facilmente dati strutturati, che rappresentano circa il 20% dei dati odierni. Nella loro cassetta degli attrezzi ci sono sistemi come database relazionali, database NoSQL, ecc.; al contrario, i dati non strutturati, che rappresentano circa l’80% di tutti i dati, non dispongono di sistemi affidabili. Per risolvere questo problema, questo articolo discuterà i punti critici che l’analisi dei dati tradizionale incontra con i dati non strutturati e approfondirà ulteriormente l’architettura e le sfide che abbiamo affrontato nella costruzione del nostro sistema di database vettoriale general-purpose.
Rivoluzione dei dati nell’era dell’AI
Con il rapido sviluppo delle tecnologie 5G e IoT, le industrie cercano di moltiplicare i propri canali di raccolta dati e di proiettare ulteriormente il mondo reale nello spazio digitale. Sebbene ciò abbia portato alcune sfide enormi, ha anche portato con sé enormi benefici per l’industria in crescita. Una di queste difficili sfide è come ottenere insight più profondi da questi nuovi dati in arrivo.
Secondo le statistiche IDC, nel solo 2020 sono stati generati in tutto il mondo più di 40.000 exabyte di nuovi dati. Del totale, solo il 20% è costituito da dati strutturati - dati altamente ordinati e facili da organizzare e analizzare tramite calcoli numerici e algebra relazionale. Al contrario, i dati non strutturati (che occupano il restante 80%) sono estremamente ricchi di variazioni di tipo di dato, rendendo difficile scoprire la semantica profonda attraverso metodi tradizionali di analisi dei dati.
Fortunatamente, stiamo vivendo una rapida evoluzione concomitante dei dati non strutturati e dell’AI, con l’AI che ci consente di comprendere meglio i dati attraverso vari tipi di reti neurali, come mostrato nella Figura 1.
Figura 1: Processo di embedding
La tecnologia di embedding ha rapidamente guadagnato popolarità dopo il debutto di Word2vec, con l’idea di "embed everything" che ha raggiunto tutti i settori del machine learning. Ciò porta all’emergere di due principali livelli di dati: il livello dei dati grezzi e il livello dei dati vettoriali. Il livello dei dati grezzi è composto da dati non strutturati e da alcuni tipi di dati strutturati; il livello vettoriale è la raccolta di embedding facilmente analizzabili che ha origine dal livello grezzo passando attraverso modelli di machine learning.
Rispetto ai dati grezzi, i dati vettorializzati presentano i seguenti vantaggi:
- I vettori di embedding sono un tipo astratto di dati, il che significa che possiamo costruire un sistema algebrico unificato dedicato alla riduzione della complessità dei dati non strutturati.
- I vettori di embedding sono espressi tramite vettori densi in virgola mobile, consentendo alle applicazioni di sfruttare SIMD. Poiché SIMD è supportato dalle GPU e da quasi tutte le CPU moderne, i calcoli sui vettori possono raggiungere prestazioni elevate a un costo relativamente basso.
- I dati vettoriali codificati tramite modelli di machine learning occupano meno spazio di archiviazione rispetto ai dati non strutturati originali, consentendo una maggiore velocità di elaborazione.
- È anche possibile eseguire operazioni aritmetiche sui vettori di embedding. La Figura 2 mostra un esempio di corrispondenza approssimata semantica cross-modale - le immagini mostrate nella figura sono il risultato della corrispondenza tra embedding di parole ed embedding di immagini.
Figura 2: Visualizzazione dell'embedding semantico basato su un modello linguistico neurale cross-modale
Come mostrato nella Figura 3, combinare la semantica di immagini e parole può essere fatto con semplici addizioni e sottrazioni vettoriali tra i rispettivi embedding.
Figura 3: Visualizzazione unificata dell'embedding semantico basato su un modello linguistico neurale cross-modale
Oltre alle funzionalità sopra menzionate, questi operatori supportano istruzioni di query più complicate in scenari pratici. La raccomandazione di contenuti è un esempio ben noto. In generale, il sistema incorpora sia il contenuto sia le preferenze di visualizzazione degli utenti. Successivamente, il sistema abbina le preferenze incorporate dell'utente con i contenuti incorporati più simili tramite analisi della similarità semantica, producendo nuovi contenuti simili alle preferenze degli utenti. Questo livello di dati vettoriali non è limitato solo ai sistemi di raccomandazione; i casi d'uso includono e-commerce, analisi di malware, analisi dei dati, verifica biometrica, analisi di formule chimiche, finanza, assicurazioni, ecc.
I dati non strutturati richiedono uno stack software di base completo
Il software di sistema si trova alla base di tutte le applicazioni orientate ai dati, ma il software dei sistemi di dati costruito negli ultimi diversi decenni, ad esempio database, motori di analisi dei dati, ecc., è pensato per gestire dati strutturati. Le applicazioni moderne basate sui dati si affidano quasi esclusivamente a dati non strutturati e non traggono beneficio dai sistemi tradizionali di gestione dei database.
Per affrontare questo problema, abbiamo sviluppato e reso open source un sistema di database vettoriale general-purpose orientato all'AI chiamato Milvus (Riferimento n. 1~2). Rispetto ai sistemi di database tradizionali, Milvus opera su un diverso livello di dati. I database tradizionali, come database relazionali, database KV, database testuali, database di immagini/video, ecc... operano sul livello dei dati grezzi, mentre Milvus opera sul livello dei dati vettoriali.
Nei capitoli seguenti, discuteremo le funzionalità innovative, la progettazione architetturale e le sfide tecniche che abbiamo affrontato durante la creazione di Milvus.
Attributi principali del database vettoriale
I database vettoriali memorizzano, recuperano, analizzano vettori e, proprio come qualsiasi altro database, forniscono anche un'interfaccia standard per le operazioni CRUD. Oltre a queste funzionalità "standard", gli attributi elencati di seguito sono anche qualità importanti per un database vettoriale:
- Supporto per operatori vettoriali ad alta efficienza
Il supporto per gli operatori vettoriali in un motore di analisi si concentra su due livelli. Innanzitutto, il database vettoriale dovrebbe supportare diversi tipi di operatori, ad esempio la corrispondenza per similarità semantica e l'aritmetica semantica menzionate sopra. Oltre a ciò, dovrebbe supportare una varietà di metriche di similarità per i calcoli di similarità sottostanti. Tale similarità è solitamente quantificata come distanza spaziale tra vettori, con metriche comuni quali distanza euclidea, distanza coseno e distanza del prodotto interno.
- Supporto per l'indicizzazione vettoriale
Rispetto agli indici basati su B-tree o LSM-tree nei database tradizionali, gli indici vettoriali ad alta dimensionalità di solito consumano molte più risorse di calcolo. Raccomandiamo di utilizzare algoritmi di indicizzazione basati su clustering e grafi, e di dare priorità alle operazioni su matrici e vettori, sfruttando così appieno le capacità di accelerazione hardware del calcolo vettoriale menzionate in precedenza.
- Esperienza utente coerente in diversi ambienti di distribuzione
I database vettoriali sono solitamente sviluppati e distribuiti in ambienti diversi. Nella fase preliminare, data scientist e ingegneri algoritmici lavorano per lo più sui loro laptop e workstation, poiché prestano maggiore attenzione all'efficienza della verifica e alla velocità di iterazione. Una volta completata la verifica, possono distribuire il database a dimensione completa su un cluster privato o nel cloud. Pertanto, un sistema di database vettoriale qualificato dovrebbe offrire prestazioni ed esperienza utente coerenti in diversi ambienti di distribuzione.
- Supporto per la ricerca ibrida
Nuove applicazioni stanno emergendo man mano che i database vettoriali diventano ubiqui. Tra tutte queste esigenze, la più frequentemente menzionata è la ricerca ibrida su vettori e altri tipi di dati. Alcuni esempi sono la ricerca approssimata del vicino più prossimo (ANNS) dopo il filtraggio scalare, il recupero multicanale dalla ricerca full-text e dalla ricerca vettoriale, e la ricerca ibrida di dati spazio-temporali e dati vettoriali. Tali sfide richiedono scalabilità elastica e ottimizzazione delle query per fondere efficacemente i motori di ricerca vettoriale con motori KV, testuali e altri motori di ricerca.
- Architettura cloud-native
Il volume dei dati vettoriali cresce rapidamente con la crescita esponenziale della raccolta di dati. Dati vettoriali ad alta dimensionalità su scala di trilioni corrispondono a migliaia di TB di storage, il che è ben oltre il limite di un singolo nodo. Di conseguenza, l'estendibilità orizzontale è una capacità chiave per un database vettoriale e dovrebbe soddisfare le esigenze degli utenti in termini di elasticità e agilità di distribuzione. Inoltre, dovrebbe anche ridurre la complessità operativa e di manutenzione del sistema, migliorando al contempo l'osservabilità con l'assistenza dell'infrastruttura cloud. Alcune di queste esigenze si presentano sotto forma di isolamento multi-tenant, snapshot e backup dei dati, crittografia dei dati e visualizzazione dei dati, che sono comuni nei database tradizionali.
Architettura del sistema di database vettoriale
Milvus 2.0 segue i principi di progettazione di "log as data", "elaborazione batch e stream unificata", "stateless" e "micro-servizi". La Figura 4 illustra l'architettura complessiva di Milvus 2.0.
Figura 4: Architettura complessiva di Milvus 2.0
Log as data: Milvus 2.0 non mantiene alcuna tabella fisica. Invece, garantisce l'affidabilità dei dati tramite la persistenza dei log e gli snapshot dei log. Il broker di log (la spina dorsale del sistema) memorizza i log e disaccoppia componenti e servizi tramite il meccanismo di pubblicazione-sottoscrizione (pub-sub) dei log. Come mostrato nella Figura 5, il broker di log è composto da "sequenza di log" e "sottoscrittore di log". La sequenza di log registra tutte le operazioni che modificano lo stato di una collection (equivalente a una tabella in un database relazionale); il sottoscrittore di log si iscrive alla sequenza di log per aggiornare i propri dati locali e fornire servizi sotto forma di copie di sola lettura. Il meccanismo pub-sub lascia inoltre spazio all'estendibilità del sistema in termini di change data capture (CDC) e distribuzione distribuita globalmente.
Figura 5: Un modello semplificato per l'archiviazione dei log
Elaborazione unificata batch e stream: lo streaming dei log consente a Milvus di aggiornare i dati in tempo reale, garantendo così la deliverability in tempo reale. Inoltre, trasformando i batch di dati in snapshot dei log e costruendo indici sugli snapshot, Milvus è in grado di ottenere una maggiore efficienza delle query. Durante una query, Milvus unisce i risultati della query provenienti sia dai dati incrementali sia dai dati storici per garantire l'integrità dei dati restituiti. Questo design bilancia meglio prestazioni in tempo reale ed efficienza, riducendo l'onere di manutenzione sia dei sistemi online sia di quelli offline rispetto a quello della tradizionale architettura Lambda.
Stateless: l'infrastruttura cloud e i componenti di storage open-source liberano Milvus dalla persistenza dei dati all'interno dei propri componenti. Milvus 2.0 persiste i dati con tre tipi di storage: storage dei metadati, storage dei log e object storage. Lo storage dei metadati non solo archivia i metadati, ma gestisce anche la scoperta dei servizi e la gestione dei nodi. Lo storage dei log esegue la persistenza dei dati incrementali e la pubblicazione-sottoscrizione dei dati. L'object storage archivia snapshot dei log, indici e alcuni risultati intermedi di calcolo.
Microservizi: Milvus segue i principi di disaggregazione del data plane e del control plane, separazione lettura/scrittura e separazione dei task online/offline. È composto da quattro livelli di servizio: livello di accesso, livello dei coordinatori, livello dei worker e livello di storage. Questi livelli sono reciprocamente indipendenti quando si tratta di scalabilità e disaster recovery. In quanto livello front-facing ed endpoint utente, il livello di accesso gestisce le connessioni dei client, convalida le richieste dei client e combina i risultati delle query. In quanto "cervello" del sistema, il livello dei coordinatori si assume i compiti di gestione della topologia del cluster, bilanciamento del carico, dichiarazione dei dati e gestione dei dati. Il livello dei worker contiene gli "arti" del sistema, eseguendo aggiornamenti dei dati, query e operazioni di costruzione degli indici. Infine, il livello di storage è responsabile della persistenza e della replica dei dati. Nel complesso, questo design basato su microservizi garantisce una complessità del sistema controllabile, con ogni componente responsabile della propria funzione corrispondente. Milvus chiarisce i confini dei servizi tramite interfacce ben definite e disaccoppia i servizi sulla base di una granularità più fine, ottimizzando ulteriormente la scalabilità elastica e la distribuzione delle risorse.
Sfide tecniche affrontate dai database vettoriali
Le prime ricerche sui database vettoriali erano concentrate principalmente sulla progettazione di strutture di indice e metodi di query ad alta efficienza - ciò ha portato a una varietà di librerie di algoritmi di ricerca vettoriale (Riferimento n. 3~5). Negli ultimi anni, un numero crescente di team accademici e ingegneristici ha riesaminato le problematiche della ricerca vettoriale dalla prospettiva della progettazione di sistema e ha proposto alcune soluzioni sistematiche. Riassumendo gli studi esistenti e la domanda degli utenti, categorizziamo le principali sfide tecniche per i database vettoriali come segue:
- Ottimizzazione del rapporto costo-prestazioni relativo al carico
Rispetto a quella dei tipi di dati tradizionali, l'analisi dei dati vettoriali richiede molte più risorse di storage e di calcolo a causa della sua elevata dimensionalità. Inoltre, gli utenti hanno mostrato preferenze diverse per le caratteristiche del carico e l'ottimizzazione costo-prestazioni nelle soluzioni di ricerca vettoriale. Per esempio, gli utenti che lavorano con dataset estremamente grandi (decine o centinaia di miliardi di vettori) preferirebbero soluzioni con costi di storage dei dati più bassi e varianza nella latenza di ricerca, mentre altri potrebbero richiedere prestazioni di ricerca più elevate e una latenza media non variabile. Per soddisfare preferenze così diverse, il componente di indice principale del database vettoriale deve essere in grado di supportare strutture di indice e algoritmi di ricerca con diversi tipi di storage e hardware di calcolo.
Ad esempio, l'archiviazione dei dati vettoriali e dei corrispondenti dati di indice su supporti di memorizzazione più economici (come NVM e SSD) dovrebbe essere presa in considerazione quando si riducono i costi di archiviazione. Tuttavia, la maggior parte degli algoritmi di ricerca vettoriale esistenti opera su dati letti direttamente dalla memoria. Per evitare la perdita di prestazioni causata dall'uso di unità disco, il database vettoriale dovrebbe essere in grado di sfruttare la località dell'accesso ai dati combinata con gli algoritmi di ricerca, oltre a essere in grado di adattarsi alle soluzioni di archiviazione per i dati vettoriali e la struttura dell'indice (Riferimento n. 6~8). Ai fini del miglioramento delle prestazioni, la ricerca contemporanea si è concentrata sulle tecnologie di accelerazione hardware che coinvolgono GPU, NPU, FPGA, ecc. (Riferimento n. 9). Tuttavia, l'hardware e i chip specifici per l'accelerazione variano nella progettazione dell'architettura, e il problema dell'esecuzione più efficiente su diversi acceleratori hardware non è ancora risolto.
- Configurazione e ottimizzazione automatizzate del sistema
La maggior parte degli studi esistenti sugli algoritmi di ricerca vettoriale cerca un equilibrio flessibile tra costi di archiviazione, prestazioni computazionali e accuratezza della ricerca. In generale, sia i parametri dell'algoritmo sia le caratteristiche dei dati influenzano le prestazioni effettive di un algoritmo. Poiché le esigenze degli utenti differiscono in termini di costi e prestazioni, la selezione di un metodo di query vettoriale adatto alle loro esigenze e alle caratteristiche dei dati rappresenta una sfida significativa.
Tuttavia, i metodi manuali di analisi degli effetti della distribuzione dei dati sugli algoritmi di ricerca non sono efficaci a causa dell'elevata dimensionalità dei dati vettoriali. Per affrontare questo problema, il mondo accademico e l'industria stanno cercando soluzioni di raccomandazione degli algoritmi basate sul machine learning (Riferimento n. 10).
La progettazione di un algoritmo intelligente di ricerca vettoriale basato su ML è anch'essa un tema di ricerca molto attuale. In generale, gli algoritmi di ricerca vettoriale esistenti sono sviluppati in modo universale per dati vettoriali con varie dimensionalità e modelli di distribuzione. Di conseguenza, non supportano strutture di indice specifiche in base alle caratteristiche dei dati e quindi hanno poco spazio per l'ottimizzazione. Gli studi futuri dovrebbero anche esplorare tecnologie efficaci di machine learning in grado di adattare le strutture di indice a diverse caratteristiche dei dati (Riferimento n. 11-12).
- Supporto per semantiche di query avanzate
Le applicazioni moderne spesso si basano su query più avanzate tra vettori: le semantiche tradizionali di ricerca del vicino più prossimo non sono più applicabili alla ricerca di dati vettoriali. Inoltre, sta emergendo la domanda di ricerca combinata tra più database vettoriali o su dati vettoriali e non vettoriali (Riferimento n. 13).
In particolare, le variazioni nelle metriche di distanza per la similarità vettoriale crescono rapidamente. I punteggi di similarità tradizionali, come la distanza euclidea, la distanza del prodotto interno e la distanza del coseno, non possono soddisfare tutte le esigenze applicative. Con la diffusione della tecnologia dell'intelligenza artificiale, molti settori stanno sviluppando le proprie metriche di similarità vettoriale specifiche per il campo, come la distanza di Tanimoto, la distanza di Mahalanobis, Superstructure e Substructure. Integrare queste metriche di valutazione negli algoritmi di ricerca esistenti e progettare nuovi algoritmi che utilizzino tali metriche sono entrambi problemi di ricerca impegnativi.
Con l'aumentare della complessità dei servizi utente, le applicazioni dovranno effettuare ricerche sia su dati vettoriali sia su dati non vettoriali. Ad esempio, un sistema di raccomandazione di contenuti analizza le preferenze degli utenti, le relazioni sociali e le abbina agli argomenti di tendenza attuali per proporre contenuti adeguati agli utenti. Tali ricerche normalmente implicano query su più tipi di dati o su più sistemi di elaborazione dei dati. Supportare tali ricerche ibride in modo efficiente e flessibile è un'altra sfida di progettazione dei sistemi.
Autori
Il Dr. Rentong Guo (Ph.D. in Software e Teoria dell'Informatica, Huazhong University of Science and Technology), socio e Direttore R&S di Zilliz. È membro del Technical Committee on Distributed Computing and Processing della China Computer Federation (CCF TCDCP). La sua ricerca si concentra su database, sistemi distribuiti, sistemi di caching ed elaborazione eterogenea. I suoi lavori di ricerca sono stati pubblicati in diverse conferenze e riviste di primo livello, tra cui Usenix ATC, ICS, DATE, TPDS. In qualità di architetto di Milvus, il Dr. Guo è alla ricerca di soluzioni per sviluppare sistemi di analisi dei dati basati su IA altamente scalabili ed efficienti in termini di costi.
Xiaofan Luan, socio e Direttore Engineering di Zilliz, e membro del Technical Advisory Committee della LF AI & Data Foundation. Ha lavorato successivamente presso la sede statunitense di Oracle e Hedvig, una startup di storage software-defined. È entrato a far parte del team Alibaba Cloud Database ed è stato responsabile dello sviluppo del database NoSQL HBase e Lindorm. Luan ha conseguito il master in Electronic Computer Engineering presso Cornell University.
Il Dr. Xiaomeng Yi (Ph.D. in Architettura dei Calcolatori, Huazhong University of Science and Technology), Senior Researcher e leader del team di ricerca di Zilliz. La sua ricerca si concentra sulla gestione di dati ad alta dimensionalità, sul recupero di informazioni su larga scala e sull'allocazione delle risorse nei sistemi distribuiti. I lavori di ricerca del Dr. Yi sono stati pubblicati in riviste e conferenze internazionali di primo piano, tra cui IEEE Network Magazine, IEEE/ACM TON, ACM SIGMOD, IEEE ICDCS e ACM TOMPECS.
Filip Haltmayer, Data Engineer di Zilliz, si è laureato presso la University of California, Santa Cruz con una laurea BS in Computer Science. Dopo essere entrato in Zilliz, Filip dedica la maggior parte del suo tempo a deployment cloud, interazioni con i clienti, interventi tecnici e sviluppo di applicazioni IA.
Riferimenti
- Progetto Milvus: https://github.com/milvus-io/milvus
- Milvus: un sistema di gestione dei dati vettoriali appositamente progettato, SIGMOD'21
- Progetto Faiss: https://github.com/facebookresearch/faiss
- Progetto Annoy: https://github.com/spotify/annoy
- Progetto SPTAG: https://github.com/microsoft/SPTAG
- GRIP: ricerca del vicino più prossimo ad alte prestazioni ottimizzata per la capacità multi-store per motore di ricerca vettoriale, CIKM'19
- DiskANN: ricerca rapida e accurata del vicino più prossimo su miliardi di punti su un singolo nodo, NIPS'19
- HM-ANN: ricerca efficiente del vicino più prossimo su miliardi di punti su memoria eterogenea, NIPS'20
- SONG: ricerca approssimata del vicino più prossimo su GPU, ICDE'20
- Una dimostrazione del servizio di tuning del sistema di gestione automatica dei database ottertune, VLDB'18
- Il caso delle strutture di indice apprese, SIGMOD'18
- Migliorare la ricerca approssimata del vicino più prossimo tramite terminazione anticipata adattiva appresa, SIGMOD'20
- AnalyticDB-V: un motore analitico ibrido verso la fusione di query per dati strutturati e non strutturati, VLDB'20
Interagisci con la nostra community open-source:
Continua a leggere
From Vector Database to Vector Lakebase
Zilliz offers a fully managed Vector Lakebase powered by Milvus, unifying real-time vector search, lake-scale discovery, and Al data operations.
Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.