Introduzione
Nell'era dei Big Data, quali tecnologie e applicazioni di database saliranno alla ribalta? Quale sarà il prossimo cambiamento?
Con i dati non strutturati che rappresentano circa l'80-90% di tutti i dati archiviati, cosa dovremmo fare con questi laghi di dati in crescita? Si potrebbe pensare di utilizzare i metodi analitici tradizionali, ma questi non riescono a ricavare informazioni utili, se non addirittura informazioni. Per rispondere a questa domanda, i "tre moschettieri" del team di ricerca e sviluppo di Zilliz, il dottor Rentong Guo, il signor Xiaofan Luan e il dottor Xiaomeng Yi, hanno collaborato alla stesura di un articolo che illustra la progettazione e le sfide affrontate nella costruzione di un sistema di database vettoriale di uso generale.
L'articolo è stato pubblicato su Programmer, una rivista prodotta da CSDN, la più grande comunità di sviluppatori di software in Cina. Questo numero di Programmer include anche articoli di Jeffrey Ullman, vincitore del Turing Award 2020, Yann LeCun, vincitore 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 completo:
Introduzione
Le moderne applicazioni di dati possono facilmente gestire i dati strutturati, che rappresentano circa il 20% dei dati odierni. Nella sua cassetta degli attrezzi ci sono sistemi come i database relazionali, i database NoSQL e così via; 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 dolenti che la tradizionale analisi dei dati ha con i dati non strutturati e discuterà ulteriormente l'architettura e le sfide che abbiamo affrontato per costruire il nostro sistema di database vettoriale di uso generale.
La rivoluzione dei dati nell'era dell'intelligenza artificiale
Con il rapido sviluppo delle tecnologie 5G e IoT, le industrie stanno cercando di moltiplicare i canali di raccolta dei dati e di proiettare ulteriormente il mondo reale nello spazio digitale. Sebbene ciò abbia comportato alcune sfide enormi, ha anche portato con sé enormi vantaggi per l'industria in crescita. Una di queste sfide difficili è come ottenere approfondimenti su questi nuovi dati in arrivo.
Secondo le statistiche di IDC, solo nel 2020 verranno generati oltre 40.000 exabyte di nuovi dati in tutto il mondo. Del totale, solo il 20% è costituito da dati strutturati, ovvero dati altamente ordinati e facili da organizzare e analizzare tramite calcoli numerici e algebra relazionale. Al contrario, i dati non strutturati (che costituiscono il restante 80%) sono estremamente ricchi di variazioni di tipo di dati, il che rende difficile scoprire la semantica profonda attraverso i metodi tradizionali di analisi dei dati.
Fortunatamente, stiamo assistendo a una rapida evoluzione dei dati non strutturati e dell'intelligenza artificiale, che ci permette di comprendere meglio i dati attraverso vari tipi di reti neurali, come illustrato nella Figura 1.
newdata1.jpeg
La tecnologia di incorporazione ha rapidamente guadagnato popolarità dopo il debutto di Word2vec, con l'idea di "incorporare tutto" che ha raggiunto tutti i settori dell'apprendimento automatico. Questo 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 incorporazioni facilmente analizzabili che provengono dal livello grezzo e passano attraverso i modelli di apprendimento automatico.
Rispetto ai dati grezzi, i dati vettoriali 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 incorporamento sono espressi attraverso vettori densi in virgola mobile, consentendo alle applicazioni di sfruttare la SIMD. Poiché la SIMD è supportata dalle GPU e da quasi tutte le CPU moderne, le computazioni attraverso i vettori possono raggiungere prestazioni elevate a un costo relativamente basso.
- I dati vettoriali codificati tramite modelli di apprendimento automatico occupano meno spazio di archiviazione rispetto ai dati non strutturati originali, consentendo un throughput più elevato.
- Anche l'aritmetica può essere eseguita attraverso i vettori incorporati. La Figura 2 mostra un esempio di corrispondenza semantica approssimativa cross-modale: le immagini mostrate nella figura sono il risultato della corrispondenza tra embedding di parole e embedding di immagini.
newdata2.png
Come mostrato nella Figura 3, la combinazione della semantica delle immagini e delle parole può essere effettuata con una semplice addizione e sottrazione vettoriale tra le rispettive incorporazioni.
newdata3.png
Oltre a queste caratteristiche, questi operatori supportano query più complesse in scenari pratici. La raccomandazione di contenuti è un esempio ben noto. In genere, il sistema incorpora sia i contenuti sia le preferenze di visualizzazione degli utenti. Successivamente, il sistema abbina le preferenze dell'utente incorporato con i contenuti incorporati più simili tramite l'analisi della somiglianza semantica, ottenendo nuovi contenuti simili alle preferenze degli utenti. Questo strato di dati vettoriali non è limitato ai sistemi di raccomandazione, ma i casi d'uso includono l'e-commerce, l'analisi del malware, l'analisi dei dati, la verifica biometrica, l'analisi delle formule chimiche, la finanza, le assicurazioni, ecc.
I dati non strutturati richiedono uno stack software completo di base
Il software di sistema è alla base di tutte le applicazioni orientate ai dati, ma il software di sistema costruito negli ultimi decenni, ad esempio i database, i motori di analisi dei dati e così via, è stato concepito per trattare dati strutturati. Le moderne applicazioni di dati si basano quasi esclusivamente su dati non strutturati e non beneficiano dei tradizionali sistemi di gestione dei database.
Per affrontare questo problema, abbiamo sviluppato e reso open-source un sistema di database vettoriale generale orientato all'intelligenza artificiale, chiamato Milvus (riferimento n. 1~2). Rispetto ai sistemi di database tradizionali, Milvus lavora su un diverso livello di dati. I database tradizionali, come i database relazionali, i database KV, i database di testo, i database di immagini/video, ecc... lavorano sul livello dei dati grezzi, mentre Milvus lavora sul livello dei dati vettoriali.
Nei capitoli seguenti, discuteremo le nuove caratteristiche, il progetto architettonico e le sfide tecniche che abbiamo affrontato durante la costruzione di Milvus.
Attributi principali dei database vettoriali
I database vettoriali memorizzano, recuperano e analizzano i vettori e, come qualsiasi altro database, forniscono anche un'interfaccia standard per le operazioni CRUD. Oltre a queste caratteristiche "standard", gli attributi elencati di seguito sono 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. In primo luogo, il database vettoriale deve supportare diversi tipi di operatori, ad esempio la corrispondenza di similarità semantica e l'aritmetica semantica di cui sopra. Inoltre, deve supportare una varietà di metriche di similarità per i calcoli di similarità sottostanti. La somiglianza è solitamente quantificata come distanza spaziale tra vettori, con metriche comuni come la distanza euclidea, la distanza coseno e la distanza del prodotto interno.
- Supporto per l'indicizzazione dei vettori
Rispetto agli indici basati su B-tree o LSM-tree dei database tradizionali, gli indici vettoriali ad alta dimensionalità consumano solitamente molte più risorse di calcolo. Si consiglia di utilizzare algoritmi di clustering e indici a grafo e di dare priorità alle operazioni matriciali e vettoriali, sfruttando così appieno le capacità di accelerazione hardware del calcolo vettoriale già menzionate.
- Esperienza utente coerente in diversi ambienti di distribuzione
I database vettoriali vengono solitamente sviluppati e distribuiti in ambienti diversi. Nella fase preliminare, gli scienziati dei dati e gli ingegneri degli algoritmi lavorano principalmente sui loro computer portatili e sulle loro stazioni di lavoro, prestando maggiore attenzione all'efficienza della verifica e alla velocità di iterazione. Una volta completata la verifica, possono distribuire il database completo su un cluster privato o sul cloud. Pertanto, un sistema di database vettoriale qualificato deve offrire prestazioni e un'esperienza utente coerenti in diversi ambienti di distribuzione.
- Supporto per la ricerca ibrida
Con la diffusione dei database vettoriali, stanno emergendo nuove applicazioni. Tra tutte queste richieste, la più frequentemente citata è la ricerca ibrida su vettori e altri tipi di dati. Alcuni esempi sono la ricerca approssimata del vicino (ANNS) dopo il filtraggio scalare, il richiamo multicanale dalla ricerca full-text e dalla ricerca vettoriale e la ricerca ibrida di dati spazio-temporali e vettoriali. Queste sfide richiedono una scalabilità elastica e l'ottimizzazione delle query per fondere efficacemente i motori di ricerca vettoriale con KV, testo e altri motori di ricerca.
- Architettura cloud-nativa
Il volume dei dati vettoriali cresce a dismisura con la crescita esponenziale della raccolta dati. I dati vettoriali ad alta dimensionalità su scala trilione corrispondono a migliaia di TB di spazio di archiviazione, il che va ben oltre il limite di un singolo nodo. Di conseguenza, l'estensibilità orizzontale è una capacità fondamentale per un database vettoriale e dovrebbe soddisfare le richieste di elasticità e agilità di implementazione degli utenti. Inoltre, dovrebbe anche ridurre la complessità del funzionamento e della manutenzione del sistema, migliorando al contempo l'osservabilità con l'aiuto 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 "log as data", "unified batch and stream processing", "stateless" e "micro-services". La Figura 4 illustra l'architettura complessiva di Milvus 2.0.
newdata4.png
Log come dati: Milvus 2.0 non mantiene tabelle fisiche. Al contrario, garantisce l'affidabilità dei dati attraverso la persistenza dei log e le istantanee dei log. Il log broker (la spina dorsale del sistema) archivia i log e disaccoppia componenti e servizi attraverso il meccanismo di pubblicazione-sottoscrizione dei log (pub-sub). Come mostrato nella Figura 5, il log broker è composto da "log sequence" e "log subscriber". Il log sequence registra tutte le operazioni che modificano lo stato di una collezione (equivalente a una tabella in un database relazionale); il log subscriber si abbona al log sequence per aggiornare i propri dati locali e fornire servizi sotto forma di copie in sola lettura. Il meccanismo pub-sub lascia spazio anche all'estendibilità del sistema in termini di acquisizione dei dati di modifica (CDC) e di distribuzione distribuita a livello globale.
newdata5.png
Elaborazione batch e stream unificata: 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 di log e costruendo indici sugli snapshot, Milvus è in grado di ottenere una maggiore efficienza delle query. Durante un'interrogazione, Milvus fonde i risultati della query sia dai dati incrementali che da quelli storici per garantire l'integrità dei dati restituiti. Questo design bilancia meglio le prestazioni in tempo reale e l'efficienza, alleggerendo il carico di manutenzione dei sistemi online e offline rispetto all'architettura Lambda tradizionale.
Senza stato: L'infrastruttura cloud e i componenti di storage open-source liberano Milvus dalla persistenza dei dati all'interno dei suoi stessi componenti. Milvus 2.0 conserva i dati con tre tipi di storage: storage dei metadati, storage dei log e storage degli oggetti. L'archiviazione dei metadati non solo memorizza i metadati, ma gestisce anche la scoperta dei servizi e la gestione dei nodi. Lo storage dei log esegue la persistenza incrementale dei dati e la pubblicazione-sottoscrizione dei dati. Lo storage a oggetti memorizza le istantanee dei log, gli indici e alcuni risultati di calcolo intermedi.
Microservizi: Milvus segue i principi della disaggregazione del piano dati e del piano di controllo, della separazione lettura/scrittura e della separazione dei compiti online/offline. È composto da quattro livelli di servizio: il livello di accesso, il livello del coordinatore, il livello del lavoratore e il livello di archiviazione. Questi livelli sono indipendenti l'uno dall'altro per quanto riguarda lo scaling e il disaster recovery. Il livello di accesso, che è il livello frontale e l'endpoint dell'utente, gestisce le connessioni dei clienti, convalida le richieste dei clienti e combina i risultati delle query. Come "cervello" del sistema, il livello coordinatore si occupa della gestione della topologia del cluster, del bilanciamento del carico, della dichiarazione dei dati e della gestione dei dati. Il livello worker contiene gli "arti" del sistema, eseguendo gli aggiornamenti dei dati, le query e le operazioni di creazione degli indici. Infine, il livello di storage è responsabile della persistenza e della replica dei dati. Nel complesso, questo design basato su microservizi assicura una complessità del sistema controllabile, con ogni componente responsabile della sua funzione corrispondente. Milvus chiarisce i confini dei servizi attraverso interfacce ben definite e disaccoppia i servizi in base a una granularità più fine, ottimizzando ulteriormente la scalabilità elastica e la distribuzione delle risorse.
Le sfide tecniche dei database vettoriali
Le prime ricerche sui database vettoriali si sono concentrate principalmente sulla progettazione di strutture di indici e di metodi di interrogazione ad alta efficienza, dando vita a una serie di librerie di algoritmi di ricerca vettoriale (riferimento n. 3~5). Negli ultimi anni, un numero sempre maggiore di team accademici e di ingegneri ha affrontato i problemi della ricerca vettoriale dal punto di vista della progettazione del sistema e ha proposto alcune soluzioni sistematiche. Riassumendo gli studi esistenti e le richieste degli utenti, abbiamo classificato le principali sfide tecniche per i database vettoriali come segue:
- Ottimizzazione del rapporto costo-prestazioni in relazione al carico
Rispetto ai tipi di dati tradizionali, l'analisi dei dati vettoriali richiede molte più risorse di archiviazione e di calcolo a causa della loro elevata dimensionalità . Inoltre, gli utenti hanno mostrato preferenze diverse per quanto riguarda le caratteristiche di carico e l'ottimizzazione dei costi e delle prestazioni delle soluzioni di ricerca vettoriale. Ad esempio, gli utenti che lavorano con insiemi di dati estremamente grandi (decine o centinaia di miliardi di vettori) preferirebbero soluzioni con costi di archiviazione dei dati più bassi e una latenza di ricerca variabile, mentre altri potrebbero richiedere prestazioni di ricerca più elevate e una latenza media non variabile. Per soddisfare queste diverse preferenze, la componente principale dell'indice del database vettoriale deve essere in grado di supportare strutture di indice e algoritmi di ricerca con diversi tipi di hardware di archiviazione e di calcolo.
Ad esempio, la memorizzazione dei dati vettoriali e dei corrispondenti dati di indice su supporti di memorizzazione più economici (come NVM e SSD) deve essere presa in considerazione per ridurre i costi di memorizzazione. Tuttavia, la maggior parte degli algoritmi di ricerca vettoriale esistenti lavora su dati letti direttamente dalla memoria. Per evitare la perdita di prestazioni dovuta all'uso delle 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 potersi adattare alle soluzioni di archiviazione per i dati vettoriali e la struttura degli indici (riferimento n. 6~8). Per migliorare le prestazioni, la ricerca contemporanea si è concentrata sulle tecnologie di accelerazione hardware che coinvolgono GPU, NPU, FPGA e così via (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 tra i diversi acceleratori hardware non è ancora stato risolto.
- Configurazione e messa a punto automatica del sistema
La maggior parte degli studi esistenti sugli algoritmi di ricerca vettoriale cerca un equilibrio flessibile tra i costi di memorizzazione, le prestazioni di calcolo e l'accuratezza della ricerca. In generale, sia i parametri dell'algoritmo sia le caratteristiche dei dati influenzano le prestazioni effettive di un algoritmo. Poiché le richieste degli utenti differiscono in termini di costi e prestazioni, la scelta di un metodo di interrogazione vettoriale che si adatti alle loro esigenze e alle caratteristiche dei dati rappresenta una sfida significativa.
Tuttavia, i metodi manuali per analizzare gli effetti della distribuzione dei dati sugli algoritmi di ricerca non sono efficaci a causa dell'elevata dimensionalità dei dati vettoriali. Per risolvere questo problema, il mondo accademico e l'industria stanno cercando soluzioni di raccomandazione degli algoritmi basate sull'apprendimento automatico (riferimento n. 10).
Anche la progettazione di un algoritmo di ricerca vettoriale intelligente alimentato da ML è un punto caldo della ricerca. In generale, gli algoritmi di ricerca vettoriale esistenti sono stati sviluppati universalmente per dati vettoriali con vari modelli di dimensionalità e distribuzione. Di conseguenza, non supportano strutture di indici specifiche in base alle caratteristiche dei dati e hanno quindi poco spazio per l'ottimizzazione. Gli studi futuri dovrebbero anche esplorare tecnologie efficaci di apprendimento automatico in grado di adattare le strutture degli indici alle diverse caratteristiche dei dati (riferimento n. 11-12).
- Supporto per la semantica avanzata delle query
Le applicazioni moderne si basano spesso su query più avanzate tra i vettori: le tradizionali semantiche di ricerca nearest neighbour non sono più applicabili alla ricerca di dati vettoriali. Inoltre, sta emergendo la richiesta di ricerche combinate su 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 sono in rapida crescita. I punteggi di somiglianza 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, molte industrie stanno sviluppando le proprie metriche di similarità vettoriale specifiche per il settore, come la distanza di Tanimoto, la distanza di Mahalanobis, la sovrastruttura e la sottostruttura. L'integrazione di queste metriche di valutazione negli algoritmi di ricerca esistenti e la progettazione di nuovi algoritmi che utilizzano tali metriche sono entrambi problemi di ricerca impegnativi.
Con l'aumento della complessità dei servizi agli utenti, le applicazioni dovranno effettuare ricerche sia su dati vettoriali che su dati non vettoriali. Ad esempio, un content recommender analizza le preferenze degli utenti, le relazioni sociali e le abbina ai temi caldi del momento per proporre agli utenti i contenuti adeguati. Tali ricerche comportano normalmente interrogazioni su più tipi di dati o su più sistemi di elaborazione dei dati. Supportare queste ricerche ibride in modo efficiente e flessibile è un'altra sfida per la progettazione del sistema.
Gli autori
Rentong Guo (Ph.D. in Computer Software and Theory, Huazhong University of Science and Technology), socio e direttore della ricerca e sviluppo di Zilliz. È membro del China Computer Federation Technical Committee on Distributed Computing and Processing (CCF TCDCP). La sua ricerca si concentra su database, sistemi distribuiti, sistemi di caching e informatica eterogenea. I suoi lavori di ricerca sono stati pubblicati in diverse conferenze e riviste di alto 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 sull'intelligenza artificiale altamente scalabili ed efficienti dal punto di vista dei costi.
Xiaofan Luan, partner e direttore tecnico di Zilliz e membro del comitato consultivo tecnico della LF AI & Data Foundation. Ha lavorato successivamente nella sede centrale di Oracle US e in Hedvig, una startup di software defined storage. È entrato a far parte del team di Alibaba Cloud Database e si è occupato dello sviluppo dei database NoSQL HBase e Lindorm. Luan ha conseguito un master in Ingegneria elettronica informatica presso la Cornell University.
Dr. Xiaomeng Yi (dottorato di ricerca in architettura informatica, Huazhong University of Science and Technology), ricercatore senior e responsabile del team di ricerca di Zilliz. La sua ricerca si concentra sulla gestione dei dati ad alta dimensione, sul reperimento di informazioni su larga scala e sull'allocazione delle risorse nei sistemi distribuiti. I lavori di ricerca del Dr. Yi sono stati pubblicati su importanti riviste e conferenze internazionali, tra cui IEEE Network Magazine, IEEE/ACM TON, ACM SIGMOD, IEEE ICDCS e ACM TOMPECS.
Filip Haltmayer, Data Engineer di Zilliz, si è laureato in Informatica presso la University of California, Santa Cruz. Dopo essere entrato a far parte di Zilliz, Filip trascorre la maggior parte del suo tempo lavorando su implementazioni cloud, interazioni con i clienti, conferenze tecniche e sviluppo di applicazioni AI.
Riferimenti
- Progetto Milvus: https://github.com/milvus-io/milvus
- Milvus: A Purpose-Built Vector Data Management System, SIGMOD'21
- Progetto Faiss: https://github.com/facebookresearch/faiss
- Progetto Annoy: https://github.com/spotify/annoy
- Progetto SPTAG: https://github.com/microsoft/SPTAG
- GRIP: Multi-Store Capacity-Optimized High-Performance Nearest Neighbor Search for Vector Search Engine, CIKM'19
- DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node, NIPS'19
- HM-ANN: ricerca efficiente dei vicini di casa in miliardi di punti su memoria eterogenea, NIPS'20
- SONG: ricerca approssimativa dei vicini su GPU, ICDE'20
- Una dimostrazione del servizio di messa a punto automatica del sistema di gestione di database ottertune, VLDB'18
- Il caso delle strutture di indice apprese, SIGMOD'18
- Miglioramento della ricerca approssimativa dei vicini attraverso la terminazione anticipata adattiva appresa, SIGMOD'20
- AnalyticDB-V: A Hybrid Analytical Engine Towards Query Fusion for Structured and Unstructured Data, VLDB'20
Impegnatevi con la nostra comunità open-source:
- La rivoluzione dei dati nell'era dell'intelligenza artificiale
- I dati non strutturati richiedono uno stack software completo di base
- Attributi principali dei database vettoriali
- Architettura del sistema di database vettoriale
- Le sfide tecniche dei database vettoriali
- Gli autori
- Riferimenti
- Impegnatevi con la nostra comunità open-source:
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word