🚀 Essayez Zilliz Cloud, la version entièrement gérée de Milvus, gratuitement—découvrez des performances 10x plus rapides ! Essayez maintenant>>

milvus-logo
LFAI
  • Home
  • Blog
  • Construction d'une base de données vectorielle pour une recherche de similarité évolutive

Construction d'une base de données vectorielle pour une recherche de similarité évolutive

  • Engineering
March 14, 2022
Xiaofan Luan

Cover image Image de couverture

Cet article a été rédigé par Xiaofan Luan et traduit par Angela Ni et Claire Yu.

Selon les statistiques, environ 80 à 90 % des données mondiales ne sont pas structurées. Alimentée par la croissance rapide de l'Internet, une explosion des données non structurées est attendue dans les années à venir. Par conséquent, les entreprises ont un besoin urgent d'une base de données puissante qui puisse les aider à mieux gérer et comprendre ce type de données. Cependant, développer une base de données est toujours plus facile à dire qu'à faire. Cet article vise à partager le processus de réflexion et les principes de conception de Milvus, une base de données vectorielles open-source et cloud-native pour la recherche de similarités évolutive. Cet article explique également l'architecture de Milvus en détail.

Aller à :

Les données non structurées nécessitent une pile logicielle de base complète

Avec la croissance et l'évolution de l'internet, les données non structurées sont devenues de plus en plus courantes, notamment les courriels, les articles, les données de capteurs IoT, les photos Facebook, les structures de protéines et bien d'autres choses encore. Pour que les ordinateurs puissent comprendre et traiter les données non structurées, celles-ci sont converties en vecteurs à l'aide de techniques d'intégration.

Milvus stocke et indexe ces vecteurs et analyse la corrélation entre deux vecteurs en calculant leur distance de similarité. Si les deux vecteurs d'intégration sont très similaires, cela signifie que les sources de données d'origine le sont également.

The workflow of processing unstructured data. Le flux de travail du traitement des données non structurées.

Vecteurs et scalaires

Un scalaire est une quantité qui n'est décrite que par une seule mesure - la magnitude. Un scalaire peut être représenté par un nombre. Par exemple, une voiture roule à une vitesse de 80 km/h. Ici, la vitesse (80 km/h) est égale à la vitesse du véhicule. La vitesse (80 km/h) est un scalaire. Un vecteur, quant à lui, est une quantité décrite par au moins deux mesures : la magnitude et la direction. Si une voiture se déplace vers l'ouest à la vitesse de 80 km/h, la vitesse (80 km/h vers l'ouest) est un vecteur. L'image ci-dessous est un exemple de scalaires et de vecteurs courants.

Scalars vs. Vectors Scalaires et vecteurs

Comme la plupart des données importantes ont plus d'un attribut, nous pouvons mieux comprendre ces données si nous les convertissons en vecteurs. Une façon courante de manipuler les données vectorielles consiste à calculer la distance entre les vecteurs à l'aide de mesures telles que la distance euclidienne, le produit intérieur, la distance de Tanimoto, la distance de Hamming, etc. Plus la distance est faible, plus les vecteurs sont similaires. Pour interroger efficacement un ensemble massif de données vectorielles, nous pouvons organiser les données vectorielles en créant des index. Une fois l'ensemble de données indexé, les requêtes peuvent être acheminées vers les grappes, ou sous-ensembles de données, qui sont les plus susceptibles de contenir des vecteurs similaires à une requête d'entrée.

Pour en savoir plus sur les index, voir Index vectoriel.

Du moteur de recherche vectoriel à la base de données vectorielle

Dès le départ, Milvus 2.0 a été conçu pour servir non seulement de moteur de recherche, mais surtout de puissante base de données vectorielles.

Pour vous aider à comprendre la différence, nous pouvons faire une analogie entre InnoDB et MySQL, ou Lucene et Elasticsearch.

Tout comme MySQL et Elasticsearch, Milvus est également construit sur des bibliothèques open-source telles que Faiss, HNSW, Annoy, qui se concentrent sur la fourniture de fonctionnalités de recherche et la garantie des performances de recherche. Cependant, il serait injuste de réduire Milvus à une simple couche au-dessus de Faiss, car il stocke, récupère et analyse les vecteurs et, comme pour toute autre base de données, fournit également une interface standard pour les opérations CRUD. En outre, Milvus peut se targuer d'offrir les fonctionnalités suivantes

  • le partage et le partitionnement
  • la réplication
  • Reprise après sinistre
  • Équilibrage de la charge
  • Analyseur ou optimiseur de requêtes

Vector database Base de données vectorielle

Pour mieux comprendre ce qu'est une base de données vectorielle, lisez le blog ici.

Une première approche "cloud-native

Could-native approach Une approche "cloud-native

Du "rien partagé" au "stockage partagé", puis au "quelque chose partagé".

Les bases de données traditionnelles adoptaient une architecture "sans partage" dans laquelle les nœuds des systèmes distribués étaient indépendants mais connectés par un réseau. Aucune mémoire ni aucun espace de stockage n'est partagé entre les nœuds. Cependant, Snowflake a révolutionné le secteur en introduisant une architecture de "stockage partagé" dans laquelle le calcul (traitement des requêtes) est séparé du stockage (stockage de la base de données). Avec une architecture de stockage partagé, les bases de données peuvent bénéficier d'une plus grande disponibilité, d'une plus grande évolutivité et d'une réduction de la duplication des données. Inspirées par Snowflake, de nombreuses entreprises ont commencé à exploiter l'infrastructure en nuage pour la persistance des données tout en utilisant le stockage local pour la mise en cache. Ce type d'architecture de base de données est appelé "shared something" (quelque chose de partagé) et est devenu l'architecture la plus courante dans la plupart des applications aujourd'hui.

Outre l'architecture "shared something", Milvus prend en charge une mise à l'échelle flexible de chaque composant en utilisant Kubernetes pour gérer son moteur d'exécution et en séparant les services de lecture, d'écriture et autres avec des microservices.

Base de données en tant que service (DBaaS)

La base de données en tant que service est une tendance brûlante, car de nombreux utilisateurs ne s'intéressent pas seulement aux fonctionnalités habituelles des bases de données, mais aspirent également à des services plus variés. Cela signifie qu'en plus des opérations CRUD traditionnelles, notre base de données doit enrichir le type de services qu'elle peut fournir, tels que la gestion de base de données, le transport de données, le chargement, la visualisation, etc.

Synergie avec l'écosystème open-source au sens large

Une autre tendance dans le développement des bases de données consiste à tirer parti de la synergie entre la base de données et d'autres infrastructures natives du cloud. Dans le cas de Milvus, il s'appuie sur certains systèmes open-source. Par exemple, Milvus utilise etcd pour stocker les métadonnées. Il adopte également la file d'attente de messages, un type de communication asynchrone de service à service utilisé dans l'architecture microservices, qui peut aider à exporter des données incrémentielles.

À l'avenir, nous espérons construire Milvus au-dessus d'infrastructures d'IA telles que Spark ou Tensorflow, et intégrer Milvus avec des moteurs de streaming afin de mieux prendre en charge le traitement unifié des flux et des lots pour répondre aux différents besoins des utilisateurs de Milvus.

Les principes de conception de Milvus 2.0

En tant que base de données vectorielle cloud-native de nouvelle génération, Milvus 2.0 s'articule autour des trois principes suivants.

Le journal en tant que données

Le journal d'une base de données enregistre en série toutes les modifications apportées aux données. Comme le montre la figure ci-dessous, de gauche à droite se trouvent les "anciennes données" et les "nouvelles données". Les journaux sont classés par ordre chronologique. Milvus dispose d'un mécanisme de temporisation global qui attribue un horodatage unique et auto-incrémentiel.

Logs Journaux

Dans Milvus 2.0, le courtier en journaux sert de colonne vertébrale au système : toutes les opérations d'insertion et de mise à jour de données doivent passer par le courtier en journaux, et les nœuds de travail exécutent les opérations CRUD en s'abonnant aux journaux et en les consommant.

Dualité de la table et du journal

La table et le journal sont tous deux des données, et ils ne sont que deux formes différentes. Les tables sont des données délimitées, tandis que les journaux sont non délimités. Les journaux peuvent être convertis en tables. Dans le cas de Milvus, les journaux sont agrégés à l'aide d'une fenêtre de traitement de TimeTick. En fonction de la séquence des journaux, plusieurs journaux sont regroupés dans un petit fichier appelé instantané de journal. Ces instantanés sont ensuite combinés pour former un segment, qui peut être utilisé individuellement pour l'équilibrage de la charge.

Persistance des journaux

La persistance des journaux est l'un des problèmes délicats auxquels sont confrontées de nombreuses bases de données. Le stockage des journaux dans un système distribué dépend généralement des algorithmes de réplication.

Contrairement à des bases de données telles que Aurora, HBase, Cockroach DB et TiDB, Milvus adopte une approche novatrice et introduit un système de publication et d'abonnement (pub/sub) pour le stockage et la persistance des journaux. Un système pub/sub est analogue à la file d'attente de messages dans Kafka ou Pulsar. Tous les nœuds du système peuvent consommer les journaux. Dans Milvus, ce type de système est appelé "log broker". Grâce au courtier de journaux, les journaux sont découplés du serveur, ce qui garantit que Milvus est lui-même sans état et mieux placé pour récupérer rapidement en cas de défaillance du système.

Log broker Courtier en journaux

Construit au-dessus des bibliothèques de recherche vectorielle les plus populaires, notamment Faiss, ANNOY et HNSW, Milvus a été conçu pour la recherche de similarités sur des ensembles de données vectorielles denses contenant des millions, des milliards, voire des trillions de vecteurs.

Autonome et en grappe

Milvus offre deux modes de déploiement : autonome ou en grappe. Dans Milvus standalone, comme tous les nœuds sont déployés ensemble, nous pouvons considérer Milvus comme un seul processus. Actuellement, Milvus autonome repose sur MinIO et etcd pour la persistance des données et le stockage des métadonnées. Dans les prochaines versions, nous espérons éliminer ces deux dépendances tierces pour garantir la simplicité du système Milvus. Le cluster Milvus comprend huit composants microservices et trois dépendances tierces : MinIO, etcd et Pulsar. Pulsar sert de courtier en journaux et fournit des services de publication/souscription de journaux.

Standalone and cluster Autonome et cluster

Un squelette de base de l'architecture Milvus

Milvus sépare le flux de données du flux de contrôle et est divisé en quatre couches indépendantes en termes d'évolutivité et de reprise après sinistre.

Milvus architecture Architecture Milvus

Couche d'accès

La couche d'accès agit comme le visage du système, exposant l'extrémité de la connexion du client au monde extérieur. Elle est chargée de traiter les connexions des clients, d'effectuer des vérifications statiques, des contrôles dynamiques de base pour les demandes des utilisateurs, de transmettre les demandes et de rassembler et renvoyer les résultats au client. Le proxy lui-même est sans état et fournit des adresses d'accès et des services unifiés au monde extérieur par le biais de composants d'équilibrage de charge (Nginx, Kubernetess Ingress, NodePort et LVS). Milvus utilise une architecture de traitement massivement parallèle (MPP), dans laquelle les proxys renvoient les résultats collectés à partir des nœuds de travail après agrégation globale et post-traitement.

Service de coordination

Le service de coordination est le cerveau du système, responsable de la gestion des nœuds de la topologie de la grappe, de l'équilibrage de la charge, de la génération des horodatages, de la déclaration des données et de la gestion des données. Pour une explication détaillée de la fonction de chaque service coordinateur, consultez la documentation technique de Milvus.

Nœuds de travail

Le nœud de travailleur, ou nœud d'exécution, agit comme les membres du système, exécutant les instructions émises par le service coordinateur et les commandes de langage de manipulation de données (DML) lancées par le proxy. Un nœud de travailleur dans Milvus est similaire à un nœud de données dans Hadoop ou à un serveur de région dans HBase. Chaque type de nœud de travailleur correspond à un service de coordination. Pour une explication détaillée de la fonction de chaque nœud de travailleur, consultez la documentation technique de Milvus.

Stockage

Le stockage est la pierre angulaire de Milvus, responsable de la persistance des données. La couche de stockage est divisée en trois parties :

  • Le méta-magasin : Responsable du stockage des instantanés de métadonnées telles que le schéma de collecte, l'état des nœuds, les points de contrôle de la consommation de messages, etc. Milvus s'appuie sur etcd pour ces fonctions et Etcd assume également la responsabilité de l'enregistrement des services et des contrôles de santé.
  • Courtier en journaux : Un système pub/sub qui prend en charge la lecture et est responsable de la persistance des données en continu, de l'exécution fiable des requêtes asynchrones, des notifications d'événements et du retour des résultats des requêtes. Lorsque les nœuds effectuent une récupération en cas d'arrêt, le courtier de journaux garantit l'intégrité des données incrémentielles par le biais de la lecture du courtier de journaux. Le cluster Milvus utilise Pulsar comme courtier de journalisation, tandis que le mode autonome utilise RocksDB. Les services de stockage en continu tels que Kafka et Pravega peuvent également être utilisés comme courtiers en journaux.
  • Stockage d'objets : Stocke les fichiers d'instantanés des journaux, les fichiers d'index scalaire/vectoriel et les résultats intermédiaires du traitement des requêtes. Milvus prend en charge AWS S3 et Azure Blob, ainsi que MinIO, un service de stockage d'objets léger et open-source. En raison de la latence d'accès élevée et de la facturation par requête des services de stockage d'objets, Milvus prendra bientôt en charge les pools de cache basés sur la mémoire/SSD et la séparation des données chaudes/froides afin d'améliorer les performances et de réduire les coûts.

Modèle de données

Le modèle de données organise les données dans une base de données. Dans Milvus, toutes les données sont organisées par collection, par tesson, par partition, par segment et par entité.

Data model 1 Modèle de données 1

Collection

Une collection dans Milvus peut être comparée à une table dans un système de stockage relationnel. La collection est la plus grande unité de données dans Milvus.

Tesson

Pour tirer pleinement parti de la puissance de calcul parallèle des clusters lors de l'écriture des données, les collections dans Milvus doivent répartir les opérations d'écriture des données sur différents nœuds. Par défaut, une collection unique contient deux shards. En fonction du volume de votre jeu de données, vous pouvez avoir plus de tiroirs dans une collection. Milvus utilise une méthode de hachage par clé maîtresse pour le partage.

Partition

Il existe également plusieurs partitions dans un shard. Dans Milvus, une partition fait référence à un ensemble de données portant la même étiquette dans une collection. Les méthodes de partitionnement courantes comprennent le partitionnement par date, par sexe, par âge de l'utilisateur, etc. La création de partitions peut être bénéfique pour le processus d'interrogation, car des données considérables peuvent être filtrées par étiquette de partition.

En comparaison, le sharding est davantage axé sur les capacités de mise à l'échelle lors de l'écriture des données, tandis que le partitionnement est davantage axé sur l'amélioration des performances du système lors de la lecture des données.

Data model 2 Modèle de données 2

Segments

Au sein de chaque partition, il existe plusieurs petits segments. Un segment est la plus petite unité de planification du système dans Milvus. Il existe deux types de segments : les segments croissants et les segments scellés. Les segments croissants sont souscrits par les nœuds de requête. L'utilisateur de Milvus continue d'écrire des données dans des segments croissants. Lorsque la taille d'un segment croissant atteint une limite supérieure (512 Mo par défaut), le système n'autorise pas l'écriture de données supplémentaires dans ce segment croissant, d'où la fermeture de ce segment. Les index sont construits sur des segments scellés.

Pour accéder aux données en temps réel, le système lit les données à la fois dans les segments croissants et dans les segments scellés.

Entités

Chaque segment contient un grand nombre d'entités. Une entité dans Milvus est équivalente à une ligne dans une base de données traditionnelle. Chaque entité possède un champ de clé primaire unique, qui peut également être généré automatiquement. Les entités doivent également contenir un horodatage (ts) et un champ vectoriel - le cœur de Milvus.

À propos de la série Deep Dive

Avec l'annonce officielle de la disponibilité générale de Milvus 2.0, nous avons orchestré cette série de blogs Milvus Deep Dive afin de fournir une interprétation approfondie de l'architecture et du code source de Milvus. Les sujets abordés dans cette série de blogs sont les suivants

Like the article? Spread the word

Continuer à Lire