Une introduction à l’architecture de Milvus
Dans une enquête menée auprès de plus de 1200 utilisateurs, nous avons identifié un défi clé récurrent : la scalabilité. Comment pouvons-nous faire évoluer nos opérations vectorielles ? Cette question conduit au développement de Milvus en tant que système distribué. Les bases de données vectorielles, contrairement aux bases de données traditionnelles, ont des exigences d’utilisation différentes. Trois différences principales nous ont motivés à créer une base de données vectorielle cloud-native à partir de zéro.
Premièrement, les données vectorielles ne nécessitent pas de transactions complexes.
Deuxièmement, la diversité des cas d’utilisation exige un compromis ajustable entre performance et cohérence.
Troisièmement, certaines opérations sur les données vectorielles sont coûteuses en calcul, ce qui nécessite une allocation élastique des ressources.
Milvus réalise une mise à l’échelle horizontale grâce à sa conception délibérée en tant que système distribué. Si les bases de données à instance unique peuvent évoluer jusqu’à un certain point, elles deviennent rapidement limitées par le matériel. La capacité de mise à l’échelle horizontale de Milvus surmonte ce problème, permettant à la base de données de s’étendre sur plusieurs instances. Il existe deux façons de faire évoluer une base de données horizontalement : intégrer directement la fonctionnalité dans la base de données ou mettre en œuvre manuellement des processus de mise à l’échelle.
Avec Milvus, la fonctionnalité de mise à l’échelle est intégrée au système. Bien que vous puissiez gérer vous-même la mise à l’échelle, ce n’est pas une solution idéale à moins que votre travail critique ne consiste à faire évoluer des bases de données. Examinons trois architectures et deux choix de conception de recherche qui rendent Milvus si scalable.
Architecture système cloud-native
La plupart des équipes logicielles ne déploient plus sur les serveurs de la salle des serveurs. Pourquoi ? Les clouds publics disponibles (AWS, Azure, GCP, etc.) permettent aux équipes logicielles d’avancer plus vite. Milvus est conçu pour tirer parti de la flexibilité offerte par le travail dans le cloud.
Milvus contient quatre couches : accès, coordination, worker et stockage. Les nœuds d’accès sans état donnent accès au système. Les workers et les coordinateurs sont conçus selon un modèle serverless. Les coordinateurs avec état activent et désactivent les workers sans état selon les besoins. La couche de stockage stocke les données vectorielles et toutes les informations nécessaires au fonctionnement du système.
Séparation des responsabilités
Lorsque l’on travaille avec une base de données vectorielle, il existe trois principaux domaines de responsabilité : l’interrogation, l’ingestion des données et l’indexation. Ces trois fonctionnalités évolueront toujours à des degrés différents et à des moments différents. Milvus fournit trois types de nœuds différents qui peuvent évoluer indépendamment.
Les nœuds de requête gèrent la fonctionnalité de requête, ce qui signifie qu’ils doivent disposer de suffisamment de mémoire pour contenir les index en mémoire de plusieurs segments. Les segments sont des blocs de données d’une taille prédéfinie que Milvus utilise pour l’efficacité et la scalabilité. Les nœuds de requête aident également à paralléliser la recherche en utilisant une partie de leur calcul et de leur mémoire pour déléguer, agréger et traiter les résultats de recherche provenant de plusieurs segments, dont beaucoup peuvent être hébergés sur d’autres nœuds.
À mesure que les données arrivent, elles vont à la fois dans les nœuds de requête et les nœuds de données. Ces nœuds conservent les données dans des segments en croissance qui n’ont pas encore atteint leur limite de taille. Une fois que le segment atteint sa capacité, le nœud de requête libère ces données et les remplace par l’index généré.
Les nœuds de données gèrent l’ingestion des données. Une fois qu’un segment atteint sa limite de taille avec un nœud de données, il est « scellé ». Les segments scellés sont ensuite transférés vers le stockage permanent depuis les nœuds de données et de requête. Une fois les données transférées vers la couche de stockage, les coordinateurs notifient un nœud d’index.
Les nœuds d’index construisent les index. Lorsqu’un nœud d’index reçoit une notification, il lit le segment de données depuis la couche de stockage. Cette configuration nous permet naturellement de travailler avec moins de données lors de la création de l’index. Puisque le nœud d’index lit les données depuis le stockage, il peut lire uniquement les attributs dont il a besoin pour développer les index.
Cohérence des écritures à grande échelle
Une partie naturelle de la mise à l’échelle consiste à rencontrer des problèmes de cohérence. Dès que vous lancez le deuxième réplicat ou la deuxième instance de Milvus ou de tout autre système de base de données, vous êtes immédiatement confronté à un problème de cohérence des données. Vous devez garantir un accord à l’échelle du système sur le degré de cohérence que les données doivent avoir.
Milvus offre de nombreuses options pour ajuster la cohérence de vos données intégrées au système. Milvus est un système pub/sub. Le bloc de stockage des messages agit comme un système de publication, en horodatant chaque élément de données qui y transite. Les nœuds de requête et de données lisent ensuite ce journal de publication en tant qu’abonnés.
La mise à l’échelle des écritures implique d’augmenter le nombre de shards agissant comme rédacteurs. Lorsque les données arrivent, leur ID est haché, et le hachage détermine quel shard écrira cet élément de données.
Segments de données pour la recherche parallèle
Comme mentionné précédemment, Milvus crée des index individuels sur des quantités prédéfinies de données appelées « segments ». Par défaut, Milvus crée des segments sur 512 Mo de données, ce que vous pouvez ajuster en fonction de vos besoins.
Pourquoi créons-nous des segments et construisons-nous des index de cette manière ? Pour plus de flexibilité, de scalabilité et de facilité de mutation. Les index sont des moyens d’accéder aux données. Imaginez que vous construisiez un index sur un jeu de données initial. Dans un scénario réel, vos données changent au fil du temps, vous devrez donc continuer à ajouter des données. Comme l’index initial n’a été construit que sur les données initiales, il n’aide pas avec les nouvelles données.
La solution rationnelle à ce problème d’indexation consisterait à construire continuellement de nouveaux index à un intervalle prédéfini (comme la quantité de nouvelles données ajoutées). Milvus met en œuvre cette solution sur plusieurs instances et réplicats.
Cette configuration par segments fournit une solution efficace à une indexation inefficace et rend les requêtes plus scalables. Comme les index construits sur des segments de données séparés ne dépendent pas les uns des autres, nous pouvons les parcourir en parallèle, uniquement limités par le matériel.
Opter pour une taille de segment plus grande améliore l’efficacité de chaque opération de recherche ; toutefois, il est essentiel de noter que ce choix entraîne également une augmentation des coûts associés à la compaction et à la reconstruction des index.
Recherche de métadonnées avec préfiltrage
Le filtrage des métadonnées est une fonctionnalité importante pour de nombreuses personnes. Cette fonctionnalité vous permet de ne rechercher que des vecteurs provenant de dates spécifiques, d’auteurs spécifiques ou ayant des valeurs d’attribut spécifiques. Lors de la conception d’une application de recherche vectorielle, vous pouvez placer le filtrage des métadonnées soit avant, soit après la fonctionnalité de recherche vectorielle.
Avant d’effectuer une recherche vectorielle, Milvus génère un masque de bits sur les métadonnées. Cette opération de préfiltrage est linéaire dans le temps. Milvus examine les données une seule fois et vérifie si les métadonnées correspondent ou non à l’expression de filtre fournie. Le préfiltrage des métadonnées réduit le volume de données soumis à la recherche vectorielle, ce qui rend l’opération de recherche vectorielle plus efficace.
Dans la prochaine version de Milvus 2.4, nous prendrons en charge l’index inversé avec tantivy, et la vitesse de préfiltrage sera considérablement augmentée.
Résumé
Milvus adopte une architecture de système distribué comprenant quatre couches : accès, coordination, travailleur et stockage. Compte tenu des cas d’utilisation variés des bases de données vectorielles, une infrastructure adaptable et évolutive est essentielle. Milvus modélise son composant d’ingestion de données conformément à cette exigence comme un système pub/sub (publish-subscribe).
Modéliser l’ingestion de données comme un service pub/sub nous donne de la flexibilité en permettant un paradigme de service découplé et contribue à la cohérence des données. Le service de « publication » marque chaque élément de données avec un horodatage dans le cadre de la fonctionnalité de cohérence.
En ce qui concerne les trois préoccupations (requêtes, ingestion de données et indexation) dans une base de données vectorielle, Milvus les sépare toutes. Chacune des trois opérations dispose de son nœud dédié. Vous pouvez lancer et arrêter les nœuds indépendamment, ce qui permet à Milvus de s’adapter à la quantité de données dont vous disposez et au modèle d’utilisation.
Assurer la cohérence des données est l’une des tâches les plus difficiles à mesure que la quantité de données dont vous disposez augmente. Milvus relève ce défi grâce à l’utilisation de « shards ». Les données entrantes sont hachées, puis réparties dans un shard en fonction de leur hash. Milvus offre une cohérence configurable avec quatre niveaux au choix, afin d’arbitrer entre la rapidité de réponse de vos recherches et la rapidité de réplication des données entre les nombreuses instances de la base de données.
L’écriture de données à grande échelle utilise plusieurs shards. La lecture de données à grande échelle utilise des segments. Les index sont construits sur des segments individuels. Chaque segment peut désormais être recherché en parallèle au moment de la requête, ce qui réduit considérablement le temps de recherche pour de grandes quantités de données.
Lors de la recherche de données, vous voudrez probablement pouvoir les filtrer d’une manière ou d’une autre. Milvus implémente le filtrage des métadonnées comme une opération de préfiltrage. Il applique ensuite un masque de bits au jeu de données pendant la recherche vectorielle et ignore tous les vecteurs qui ne correspondent pas. Cette approche peut réduire considérablement le temps de recherche si de nombreux vecteurs sont filtrés.
L’architecture unique de Milvus offre de nombreux avantages, en particulier la mise à l’échelle horizontale. Elle est méticuleusement conçue comme une base de données vectorielle cloud-native pour une mise à l’échelle horizontale rapide tout en maintenant des performances optimales. La conception d’architecture délibérément découplée facilite l’évolution de Milvus au fil du temps et offre de la flexibilité. Cette adaptabilité s’avère cruciale compte tenu de l’importance croissante des bases de données vectorielles et de l’éventail grandissant de cas d’utilisation auxquels elles répondent.
Continuer à lire
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty
Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.
Cosmos World Foundation Model Platform for Physical AI
NVIDIA's Cosmos platform enables safe, digital twin training of GenAI models for physical applications, overcoming data scarcity and safety challenges.