Frustré par les nouvelles données ? Notre base de données vectorielle peut vous aider
À l’ère du Big Data, quelles technologies et applications de bases de données seront mises sur le devant de la scène ? Quel sera le prochain bouleversement majeur ?
Les données non structurées représentant environ 80 à 90 % de toutes les données stockées ; que sommes-nous censés faire de ces lacs de données en pleine croissance ? On pourrait penser à utiliser des méthodes analytiques traditionnelles, mais celles-ci échouent à en extraire des informations utiles, voire la moindre information. Pour répondre à cette question, les « Trois Mousquetaires » de l’équipe Recherche et Développement de Zilliz, le Dr Rentong Guo, M. Xiaofan Luan et le Dr Xiaomeng Yi, ont coécrit un article afin de discuter de la conception et des défis rencontrés lors de la construction d’un système de base de données vectorielle polyvalent.
Cet article a été inclus dans Programmer, une revue produite par CSDN, la plus grande communauté de développeurs logiciels en Chine. Ce numéro de Programmer comprend également des articles de Jeffrey Ullman, lauréat du prix Turing 2020, Yann LeCun, lauréat du prix Turing 2018, Mark Porter, CTO de MongoDB, Zhenkun Yang, fondateur d’OceanBase, Dongxu Huang, fondateur de PingCAP, etc.
Ci-dessous, nous partageons avec vous l’article complet :
Conception et pratique des systèmes de bases de données vectorielles polyvalents orientés IA
Introduction
Les applications de données modernes peuvent facilement traiter les données structurées, qui représentent environ 20 % des données actuelles. Leur boîte à outils comprend des systèmes tels que les bases de données relationnelles, les bases de données NoSQL, etc. ; en revanche, les données non structurées, qui représentent environ 80 % de toutes les données, ne disposent d’aucun système fiable en place. Pour résoudre ce problème, cet article abordera les points de friction que l’analytique de données traditionnelle rencontre avec les données non structurées et discutera en outre de l’architecture et des défis auxquels nous avons été confrontés lors de la construction de notre propre système de base de données vectorielle polyvalent.
Révolution des données à l’ère de l’IA
Avec le développement rapide des technologies 5G et IoT, les industries cherchent à multiplier leurs canaux de collecte de données et à projeter davantage le monde réel dans l’espace numérique. Bien que cela ait engendré des défis considérables, cela a également apporté d’immenses avantages à une industrie en pleine croissance. L’un de ces défis difficiles consiste à obtenir des informations plus approfondies à partir de ces nouvelles données entrantes.
Selon les statistiques d’IDC, plus de 40 000 exaoctets de nouvelles données ont été générés dans le monde rien qu’en 2020. Sur ce total, seules 20 % sont des données structurées - des données hautement ordonnées et faciles à organiser et à analyser via des calculs numériques et l’algèbre relationnelle. En revanche, les données non structurées (qui occupent les 80 % restants) présentent une diversité extrêmement riche de types de données, ce qui rend difficile la découverte de la sémantique profonde par les méthodes traditionnelles d’analyse de données.
Heureusement, nous connaissons une évolution rapide et concomitante des données non structurées et de l’IA, l’IA nous permettant de mieux comprendre les données grâce à divers types de réseaux neuronaux, comme le montre la Figure 1.
Figure 1 : Processus d’embedding
La technologie d’embedding a rapidement gagné en popularité après les débuts de Word2vec, l’idée de « tout embedder » atteignant tous les secteurs du machine learning. Cela conduit à l’émergence de deux grandes couches de données : la couche de données brutes et la couche de données vectorielles. La couche de données brutes est composée de données non structurées et de certains types de données structurées ; la couche vectorielle est l’ensemble des embeddings facilement analysables qui proviennent de la couche brute après passage par des modèles de machine learning.
Comparées aux données brutes, les données vectorisées présentent les avantages suivants :
- Les vecteurs d'embedding sont un type abstrait de données, ce qui signifie que nous pouvons construire un système d’algèbre unifié dédié à la réduction de la complexité des données non structurées.
- Les vecteurs d'embedding sont exprimés au moyen de vecteurs denses à virgule flottante, permettant aux applications de tirer parti du SIMD. Le SIMD étant pris en charge par les GPU et presque tous les CPU modernes, les calculs sur les vecteurs peuvent atteindre de hautes performances à un coût relativement faible.
- Les données vectorielles encodées via des modèles d’apprentissage automatique occupent moins d’espace de stockage que les données non structurées originales, permettant un débit plus élevé.
- Des opérations arithmétiques peuvent également être effectuées sur les vecteurs d'embedding. La Figure 2 montre un exemple de correspondance approximative sémantique multimodale - les images présentées dans la figure sont le résultat de la mise en correspondance d’embeddings de mots avec des embeddings d’images.
Figure 2: Visualisation de l’embedding sémantique basé sur un modèle de langage neuronal multimodal
Comme le montre la Figure 3, la combinaison de la sémantique des images et des mots peut se faire par simple addition et soustraction de vecteurs sur leurs embeddings correspondants.
Figure 3: Visualisation unifiée de l’embedding sémantique basé sur un modèle de langage neuronal multimodal
Outre les fonctionnalités ci-dessus, ces opérateurs prennent en charge des instructions de requête plus complexes dans des scénarios pratiques. La recommandation de contenu en est un exemple bien connu. Généralement, le système intègre à la fois le contenu et les préférences de visionnage des utilisateurs. Ensuite, le système met en correspondance les préférences intégrées de l’utilisateur avec le contenu intégré le plus similaire via une analyse de similarité sémantique, ce qui aboutit à un nouveau contenu similaire aux préférences des utilisateurs. Cette couche de données vectorielles ne se limite pas aux systèmes de recommandation, les cas d’utilisation incluent le commerce électronique, l’analyse de logiciels malveillants, l’analyse de données, la vérification biométrique, l’analyse de formules chimiques, la finance, l’assurance, etc.
Les données non structurées nécessitent une pile logicielle de base complète
Le logiciel système constitue la base de toutes les applications orientées données, mais les logiciels de systèmes de données développés au cours des dernières décennies, par exemple les bases de données, les moteurs d’analyse de données, etc., sont destinés à traiter des données structurées. Les applications de données modernes reposent presque exclusivement sur des données non structurées et ne bénéficient pas des systèmes traditionnels de gestion de bases de données.
Pour résoudre ce problème, nous avons développé et rendu open source un système de base de données vectorielle polyvalent orienté IA nommé Milvus (Référence n° 1~2). Par rapport aux systèmes de bases de données traditionnels, Milvus fonctionne sur une couche de données différente. Les bases de données traditionnelles, telles que les bases de données relationnelles, les bases de données KV, les bases de données textuelles, les bases de données d’images/vidéos, etc... fonctionnent sur la couche de données brutes, tandis que Milvus fonctionne sur la couche de données vectorielles.
Dans les chapitres suivants, nous aborderons les nouvelles fonctionnalités, la conception architecturale et les défis techniques auxquels nous avons été confrontés lors de la création de Milvus.
Principaux attributs d’une base de données vectorielle
Les bases de données vectorielles stockent, récupèrent, analysent les vecteurs et, comme toute autre base de données, fournissent également une interface standard pour les opérations CRUD. Outre ces fonctionnalités « standard », les attributs énumérés ci-dessous sont également des qualités importantes pour une base de données vectorielle :
- Prise en charge d’opérateurs vectoriels à haute efficacité
La prise en charge des opérateurs vectoriels dans un moteur d’analyse se concentre sur deux niveaux. Premièrement, la base de données vectorielle doit prendre en charge différents types d’opérateurs, par exemple la correspondance de similarité sémantique et l’arithmétique sémantique mentionnées ci-dessus. En plus de cela, elle doit prendre en charge une variété de métriques de similarité pour les calculs de similarité sous-jacents. Une telle similarité est généralement quantifiée comme une distance spatiale entre les vecteurs, les métriques courantes étant la distance euclidienne, la distance cosinus et la distance par produit scalaire.
- Prise en charge de l’indexation vectorielle
Comparés aux index basés sur les B-tree ou les LSM-tree dans les bases de données traditionnelles, les index vectoriels à haute dimension consomment généralement beaucoup plus de ressources de calcul. Nous recommandons d’utiliser des algorithmes d’indexation par clustering et par graphe, et de donner la priorité aux opérations matricielles et vectorielles, afin de tirer pleinement parti des capacités d’accélération du calcul vectoriel matériel mentionnées précédemment.
- Expérience utilisateur cohérente dans différents environnements de déploiement
Les bases de données vectorielles sont généralement développées et déployées dans différents environnements. Au stade préliminaire, les data scientists et les ingénieurs en algorithmes travaillent principalement sur leurs ordinateurs portables et stations de travail, car ils accordent davantage d’importance à l’efficacité de la vérification et à la vitesse d’itération. Une fois la vérification terminée, ils peuvent déployer la base de données complète sur un cluster privé ou dans le cloud. Par conséquent, un système de base de données vectorielle qualifié doit offrir des performances et une expérience utilisateur cohérentes dans différents environnements de déploiement.
- Prise en charge de la recherche hybride
De nouvelles applications émergent à mesure que les bases de données vectorielles deviennent omniprésentes. Parmi toutes ces demandes, la plus fréquemment mentionnée est la recherche hybride sur les vecteurs et d’autres types de données. Quelques exemples de cela sont la recherche approximative du plus proche voisin (ANNS) après filtrage scalaire, le rappel multicanal à partir de la recherche en texte intégral et de la recherche vectorielle, ainsi que la recherche hybride de données spatio-temporelles et de données vectorielles. De tels défis exigent une évolutivité élastique et une optimisation des requêtes afin de fusionner efficacement les moteurs de recherche vectorielle avec les moteurs de recherche KV, textuels et autres.
- Architecture cloud-native
Le volume de données vectorielles prolifère avec la croissance exponentielle de la collecte de données. Les données vectorielles à haute dimension à l’échelle du trillion correspondent à des milliers de To de stockage, ce qui dépasse largement la limite d’un seul nœud. Par conséquent, l’extensibilité horizontale est une capacité clé pour une base de données vectorielle, et doit répondre aux exigences des utilisateurs en matière d’élasticité et d’agilité de déploiement. En outre, elle doit également réduire la complexité d’exploitation et de maintenance du système tout en améliorant l’observabilité avec l’aide de l’infrastructure cloud. Certains de ces besoins prennent la forme d’isolation multi-locataire, d’instantanés et de sauvegardes de données, de chiffrement des données et de visualisation des données, qui sont courants dans les bases de données traditionnelles.
Architecture du système de base de données vectorielle
Milvus 2.0 suit les principes de conception de "log as data", "unified batch and stream processing", "stateless" et "micro-services". La Figure 4 illustre l’architecture globale de Milvus 2.0.
Figure 4 : Architecture globale de Milvus 2.0
Log as data : Milvus 2.0 ne maintient aucune table physique. À la place, il garantit la fiabilité des données via la persistance des journaux et les instantanés de journaux. Le courtier de journaux (l’épine dorsale du système) stocke les journaux et découple les composants et services grâce au mécanisme de publication-abonnement (pub-sub) des journaux. Comme le montre la Figure 5, le courtier de journaux est composé de "log sequence" et de "log subscriber". La séquence de journaux enregistre toutes les opérations qui modifient l’état d’une collection (équivalente à une table dans une base de données relationnelle ) ; l’abonné aux journaux s’abonne à la séquence de journaux pour mettre à jour ses données locales et fournir des services sous forme de copies en lecture seule. Le mécanisme pub-sub laisse également de la place à l’extensibilité du système en matière de capture des données modifiées (CDC) et de déploiement distribué à l’échelle mondiale.
Figure 5 : Un modèle simplifié pour le stockage des journaux
Traitement unifié par lots et en flux : le streaming de journaux permet à Milvus de mettre à jour les données en temps réel, garantissant ainsi une livrabilité en temps réel. De plus, en transformant les lots de données en instantanés de journaux et en construisant des index sur les instantanés, Milvus est en mesure d’atteindre une plus grande efficacité des requêtes. Lors d’une requête, Milvus fusionne les résultats de requête provenant à la fois des données incrémentales et des données historiques afin de garantir l’intégralité des données renvoyées. Une telle conception équilibre mieux les performances en temps réel et l’efficacité, allégeant la charge de maintenance des systèmes en ligne et hors ligne par rapport à celle de l’architecture Lambda traditionnelle.
Sans état : l’infrastructure cloud et les composants de stockage open source libèrent Milvus de la persistance des données au sein de ses propres composants. Milvus 2.0 persiste les données avec trois types de stockage : stockage des métadonnées, stockage des journaux et stockage objet. Le stockage des métadonnées ne stocke pas seulement les métadonnées, mais gère également la découverte des services et la gestion des nœuds. Le stockage des journaux exécute la persistance des données incrémentales et la publication-abonnement des données. Le stockage objet stocke les instantanés de journaux, les index et certains résultats de calcul intermédiaires.
Microservices : Milvus suit les principes de dissociation du plan de données et du plan de contrôle, de séparation lecture/écriture, et de séparation des tâches en ligne/hors ligne. Il est composé de quatre couches de service : la couche d’accès, la couche de coordination, la couche de travail et la couche de stockage. Ces couches sont mutuellement indépendantes en matière de mise à l’échelle et de reprise après sinistre. En tant que couche orientée vers l’extérieur et point d’accès utilisateur, la couche d’accès gère les connexions client, valide les requêtes client et combine les résultats des requêtes. En tant que « cerveau » du système, la couche de coordination prend en charge les tâches de gestion de la topologie du cluster, d’équilibrage de charge, de déclaration des données et de gestion des données. La couche de travail contient les « membres » du système, exécutant les mises à jour des données, les requêtes et les opérations de construction d’index. Enfin, la couche de stockage est chargée de la persistance et de la réplication des données. Globalement, cette conception basée sur les microservices garantit une complexité système contrôlable, chaque composant étant responsable de sa fonction correspondante. Milvus clarifie les limites des services grâce à des interfaces bien définies et découple les services selon une granularité plus fine, ce qui optimise davantage l’évolutivité élastique et la distribution des ressources.
Défis techniques rencontrés par les bases de données vectorielles
Les premières recherches sur les bases de données vectorielles se concentraient principalement sur la conception de structures d’index à haute efficacité et de méthodes de requête — ce qui a donné lieu à une variété de bibliothèques d’algorithmes de recherche vectorielle (références n° 3 à 5). Au cours des dernières années, un nombre croissant d’équipes académiques et d’ingénierie ont porté un regard nouveau sur les problématiques de recherche vectorielle du point de vue de la conception système, et ont proposé certaines solutions systématiques. En résumant les études existantes et la demande des utilisateurs, nous catégorisons les principaux défis techniques des bases de données vectorielles comme suit :
- Optimisation du rapport coût-performance par rapport à la charge
Comparée à celle des types de données traditionnels, l’analyse des données vectorielles nécessite beaucoup plus de ressources de stockage et de calcul en raison de leur grande dimensionnalité. De plus, les utilisateurs ont montré des préférences diverses en matière de caractéristiques de charge et d’optimisation du rapport coût-performance pour les solutions de recherche vectorielle. Par exemple, les utilisateurs qui travaillent avec des ensembles de données extrêmement volumineux (des dizaines ou des centaines de milliards de vecteurs) préféreraient des solutions présentant des coûts de stockage des données plus faibles et une variance de la latence de recherche, tandis que d’autres peuvent exiger des performances de recherche plus élevées et une latence moyenne non variable. Pour satisfaire de telles préférences diverses, le composant d’index central de la base de données vectorielle doit être capable de prendre en charge des structures d’index et des algorithmes de recherche avec différents types de matériel de stockage et de calcul.
Par exemple, le stockage des données vectorielles et des données d’index correspondantes sur des supports de stockage moins coûteux (tels que la NVM et les SSD) devrait être pris en considération lors de la réduction des coûts de stockage. Cependant, la plupart des algorithmes de recherche vectorielle existants fonctionnent sur des données lues directement depuis la mémoire. Pour éviter la perte de performance induite par l’utilisation de disques, la base de données vectorielle devrait être capable d’exploiter la localité de l’accès aux données combinée aux algorithmes de recherche, en plus de pouvoir s’adapter aux solutions de stockage pour les données vectorielles et la structure d’index (Référence n° 6~8). Dans un souci d’amélioration des performances, la recherche contemporaine s’est concentrée sur les technologies d’accélération matérielle impliquant les GPU, NPU, FPGA, etc. (Référence n° 9). Cependant, le matériel et les puces spécifiques à l’accélération varient dans leur conception architecturale, et le problème de l’exécution la plus efficace sur différents accélérateurs matériels n’est pas encore résolu.
- Configuration et réglage automatisés du système
La plupart des études existantes sur les algorithmes de recherche vectorielle cherchent un équilibre flexible entre les coûts de stockage, les performances de calcul et la précision de la recherche. En général, les paramètres de l’algorithme comme les caractéristiques des données influencent les performances réelles d’un algorithme. Comme les exigences des utilisateurs diffèrent en matière de coûts et de performances, sélectionner une méthode de requête vectorielle adaptée à leurs besoins et aux caractéristiques de leurs données constitue un défi majeur.
Néanmoins, les méthodes manuelles d’analyse des effets de la distribution des données sur les algorithmes de recherche ne sont pas efficaces en raison de la forte dimensionnalité des données vectorielles. Pour résoudre ce problème, le monde universitaire et l’industrie recherchent des solutions de recommandation d’algorithmes fondées sur l’apprentissage automatique (Référence n° 10).
La conception d’un algorithme intelligent de recherche vectorielle alimenté par le ML est également un sujet de recherche très actif. De manière générale, les algorithmes de recherche vectorielle existants sont développés de façon universelle pour des données vectorielles présentant diverses dimensionnalités et divers schémas de distribution. Par conséquent, ils ne prennent pas en charge de structures d’index spécifiques selon les caractéristiques des données, et disposent donc de peu de marge d’optimisation. Les études futures devraient également explorer des technologies efficaces d’apprentissage automatique capables d’adapter les structures d’index à différentes caractéristiques de données (Référence n° 11-12).
- Prise en charge de sémantiques de requête avancées
Les applications modernes reposent souvent sur des requêtes plus avancées à travers les vecteurs - la sémantique traditionnelle de recherche du plus proche voisin n’est plus applicable à la recherche de données vectorielles. De plus, la demande de recherche combinée à travers plusieurs bases de données vectorielles ou sur des données vectorielles et non vectorielles émerge (Référence n° 13).
Plus précisément, les variations des métriques de distance pour la similarité vectorielle augmentent rapidement. Les scores de similarité traditionnels, tels que la distance euclidienne, la distance du produit interne et la distance cosinus, ne peuvent pas satisfaire toutes les exigences applicatives. Avec la popularisation de la technologie de l’intelligence artificielle, de nombreux secteurs développent leurs propres métriques de similarité vectorielle propres à leur domaine, telles que la distance de Tanimoto, la distance de Mahalanobis, la superstructure et la sous-structure. L’intégration de ces métriques d’évaluation dans les algorithmes de recherche existants et la conception de nouveaux algorithmes utilisant lesdites métriques constituent toutes deux des problèmes de recherche difficiles.
À mesure que la complexité des services utilisateur augmente, les applications devront effectuer des recherches à la fois dans des données vectorielles et non vectorielles. Par exemple, un système de recommandation de contenu analyse les préférences des utilisateurs, leurs relations sociales, et les met en correspondance avec les sujets d’actualité afin de proposer du contenu approprié aux utilisateurs. De telles recherches impliquent normalement des requêtes sur plusieurs types de données ou à travers plusieurs systèmes de traitement de données. Prendre en charge ces recherches hybrides de manière efficace et flexible constitue un autre défi de conception système.
Auteurs
Dr Rentong Guo (Ph.D. en logiciel informatique et théorie, Huazhong University of Science and Technology), partenaire et directeur R&D de Zilliz. Il est membre du comité technique sur le calcul et le traitement distribués de la China Computer Federation (CCF TCDCP). Ses recherches portent sur les bases de données, les systèmes distribués, les systèmes de cache et le calcul hétérogène. Ses travaux de recherche ont été publiés dans plusieurs conférences et revues de premier plan, notamment Usenix ATC, ICS, DATE, TPDS. En tant qu’architecte de Milvus, Dr Guo recherche des solutions pour développer des systèmes d’analyse de données basés sur l’IA hautement évolutifs et rentables.
Xiaofan Luan, partenaire et directeur de l’ingénierie de Zilliz, et membre du comité consultatif technique de la LF AI & Data Foundation. Il a travaillé successivement au siège américain d’Oracle et chez Hedvig, une startup de stockage défini par logiciel. Il a rejoint l’équipe Alibaba Cloud Database et était responsable du développement de la base de données NoSQL HBase et de Lindorm. Luan a obtenu son master en génie informatique électronique à Cornell University.
Dr Xiaomeng Yi (Ph.D. en architecture informatique, Huazhong University of Science and Technology), chercheur principal et responsable de l’équipe de recherche de Zilliz. Ses recherches se concentrent sur la gestion des données de grande dimension, la recherche d’informations à grande échelle et l’allocation des ressources dans les systèmes distribués. Les travaux de recherche du Dr Yi ont été publiés dans des revues de premier plan et des conférences internationales, notamment IEEE Network Magazine, IEEE/ACM TON, ACM SIGMOD, IEEE ICDCS et ACM TOMPECS.
Filip Haltmayer, ingénieur données chez Zilliz, est diplômé de University of California, Santa Cruz avec un BS en informatique. Depuis qu’il a rejoint Zilliz, Filip consacre la majeure partie de son temps aux déploiements cloud, aux interactions avec les clients, aux présentations techniques et au développement d’applications d’IA.
Références
- Projet Milvus : https://github.com/milvus-io/milvus
- Milvus : un système de gestion de données vectorielles conçu à cet effet, SIGMOD'21
- Projet Faiss : https://github.com/facebookresearch/faiss
- Projet Annoy : https://github.com/spotify/annoy
- Projet SPTAG : https://github.com/microsoft/SPTAG
- GRIP : recherche du plus proche voisin haute performance, optimisée en capacité et multi-stockage, pour moteur de recherche vectorielle, CIKM'19
- DiskANN : recherche rapide et précise du plus proche voisin sur un milliard de points sur un seul nœud, NIPS'19
- HM-ANN : recherche efficace du plus proche voisin sur un milliard de points sur mémoire hétérogène, NIPS'20
- SONG : recherche approximative du plus proche voisin sur GPU, ICDE'20
- Une démonstration du service de réglage automatique du système de gestion de base de données ottertune, VLDB'18
- Plaidoyer pour les structures d’index apprises, SIGMOD'18
- Amélioration de la recherche approximative du plus proche voisin grâce à une terminaison anticipée adaptative apprise, SIGMOD'20
- AnalyticDB-V : un moteur analytique hybride vers la fusion de requêtes pour données structurées et non structurées, VLDB'20
Interagissez avec notre communauté open source :
Continuer à lire
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.