Aperçu de l'architecture de Milvus
Milvus est une base de données vectorielles open-source et cloud-native conçue pour la recherche de similarités haute performance sur des ensembles de données vectorielles massifs. Construite au-dessus des bibliothèques de recherche vectorielle populaires, notamment Faiss, HNSW, DiskANN et SCANN, elle renforce les applications d'IA et les scénarios de recherche de données non structurées. Avant de poursuivre, familiarisez-vous avec les principes de base de la recherche par incorporation.
Diagramme de l'architecture
Le diagramme suivant illustre l'architecture de haut niveau de Milvus, mettant en évidence sa conception modulaire, évolutive et cloud-native avec des couches de stockage et de calcul entièrement désagrégées.
Schéma de l'architecture
Principes architecturaux
Milvus suit le principe de la désagrégation du plan de données et du plan de contrôle, comprenant quatre couches principales qui sont mutuellement indépendantes en termes d'évolutivité et de reprise après sinistre. Cette architecture de stockage partagé avec des couches de stockage et de calcul entièrement désagrégées permet une mise à l'échelle horizontale des nœuds de calcul tout en mettant en œuvre Woodpecker en tant que couche WAL sans disque pour une élasticité accrue et une réduction des frais généraux d'exploitation.
En séparant le traitement en flux dans le nœud de flux et le traitement par lots dans le nœud de requête et le nœud de données, Milvus atteint des performances élevées tout en répondant simultanément aux exigences de traitement en temps réel.
Architecture détaillée des couches
Couche 1 : Couche d'accès
Composée d'un groupe de proxys sans état, la couche d'accès est la couche frontale du système et le point d'accès aux utilisateurs. Elle valide les demandes des clients et réduit les résultats renvoyés :
- Le proxy est lui-même sans état. Il fournit une adresse de service unifiée à l'aide de composants d'équilibrage de charge tels que Nginx, Kubernetes Ingress, NodePort et LVS.
- Comme Milvus utilise une architecture de traitement massivement parallèle (MPP), le proxy agrège et post-traite les résultats intermédiaires avant de renvoyer les résultats finaux au client.
Couche 2 : Coordinateur
Le coordinateur est le cerveau de Milvus. À tout moment, un seul coordinateur est actif dans l'ensemble de la grappe, chargé de maintenir la topologie de la grappe, de planifier tous les types de tâches et de garantir la cohérence au niveau de la grappe.
Voici quelques-unes des tâches gérées par le coordinateur:
- Gestion du DDL/DCL/TSO: Il gère les requêtes du langage de définition des données (DDL) et du langage de contrôle des données (DCL), telles que la création ou la suppression de collections, de partitions ou d'index, ainsi que la gestion de l'Oracle d'horodatage (TSO) et de l'émission de tickers temporels.
- Gestion des services de streaming: Lie le Write-Ahead Log (WAL) aux nœuds de diffusion en continu et assure la découverte du service de diffusion en continu.
- Gestion des requêtes: Gère la topologie et l'équilibrage des charges pour les nœuds de requête, et fournit et gère les vues de requête de service pour guider l'acheminement des requêtes.
- Gestion des données historiques: Distribue les tâches hors ligne telles que le compactage et la création d'index aux nœuds de données, et gère la topologie des segments et des vues de données.
Couche 3 : Nœuds de travail
Les bras et les jambes. Les nœuds de travail sont des exécutants muets qui suivent les instructions du coordinateur. Les nœuds de travail sont sans état grâce à la séparation du stockage et du calcul, et peuvent faciliter la mise à l'échelle du système et la reprise après sinistre lorsqu'ils sont déployés sur Kubernetes. Il existe trois types de nœuds de travail :
Nœud de streaming
Le nœud de streaming sert de "mini-cerveau" au niveau du shard, fournissant des garanties de cohérence au niveau du shard et une reprise sur panne basée sur le stockage WAL sous-jacent. Parallèlement, le nœud de streaming est également responsable de l'interrogation des données croissantes et de la génération de plans d'interrogation. En outre, il gère la conversion des données croissantes en données scellées (historiques).
Nœud de requête
Le nœud de requête charge les données historiques à partir du stockage d'objets et permet d'interroger les données historiques.
Nœud de données
Le nœud de données est responsable du traitement hors ligne des données historiques, comme le compactage et la construction d'index.
Couche 4 : Stockage
Le stockage est l'ossature du système, responsable de la persistance des données. Il comprend le méta stockage, le log broker et le stockage d'objets.
Méta stockage
Le méta-stockage stocke des instantanés de métadonnées telles que le schéma de collecte et les points de contrôle de la consommation de messages. Le stockage des métadonnées exige une très grande disponibilité, une forte cohérence et la prise en charge des transactions, c'est pourquoi Milvus a choisi etcd pour le méta-stockage. Milvus utilise également etcd pour l'enregistrement et la vérification de l'état des services.
Stockage d'objets
Le stockage d'objets stocke les fichiers d'instantanés des journaux, les fichiers d'index pour les données scalaires et vectorielles et les résultats de requêtes intermédiaires. Milvus utilise MinIO comme stockage d'objets et peut être facilement déployé sur AWS S3 et Azure Blob, deux des services de stockage les plus populaires et les plus rentables au monde. Toutefois, le stockage d'objets présente une latence d'accès élevée et est facturé en fonction du nombre de requêtes. Pour améliorer ses performances et réduire les coûts, Milvus prévoit de mettre en œuvre la séparation des données froides et chaudes sur un pool de cache à base de mémoire ou de SSD.
Stockage WAL
Le stockage WAL (Write-Ahead Log) est le fondement de la durabilité et de la cohérence des données dans les systèmes distribués. Avant qu'une modification ne soit validée, elle est d'abord enregistrée dans un journal, ce qui garantit qu'en cas de défaillance, vous pouvez reprendre exactement là où vous vous étiez arrêté.
Les implémentations WAL les plus courantes sont Kafka, Pulsar et Woodpecker. Contrairement aux solutions traditionnelles basées sur des disques, Woodpecker adopte une conception sans disque, native pour le cloud, qui écrit directement dans le stockage objet. Cette approche s'adapte sans effort à vos besoins et simplifie les opérations en supprimant les frais généraux liés à la gestion des disques locaux.
En enregistrant chaque opération d'écriture à l'avance, la couche WAL garantit un mécanisme fiable de récupération et de cohérence à l'échelle du système, quelle que soit la complexité de votre environnement distribué.
Flux de données et catégories d'API
Les API Milvus sont classées par fonction et suivent des chemins spécifiques dans l'architecture :
| Catégorie d'API | Opérations | Exemples d'API | Flux d'architecture |
|---|---|---|---|
| DDL/DCL | Schéma et contrôle d'accès | createCollection dropCollection, , hasCollection createPartition | Couche d'accès → Coordinateur |
| DML | Manipulation de données | insert, delete, upsert | Couche d'accès → Nœud de travail en continu |
| DQL | Requête de données | search, query | Couche d'accès → Nœud de travail par lots (nœuds de requête) |
Exemple de flux de données : opération de recherche
- Le client envoie une demande de recherche via le SDK/l'API RESTful.
- L'équilibreur de charge achemine la demande vers le mandataire disponible dans la couche d'accès.
- Le mandataire utilise le cache de routage pour déterminer les nœuds cibles ; il ne contacte le coordinateur que si le cache n'est pas disponible.
- Le proxy transmet la demande aux nœuds de streaming appropriés, qui coordonnent ensuite avec les nœuds de requête pour la recherche de données scellées tout en exécutant localement la recherche de données croissantes.
- Les nœuds d'interrogation chargent les segments scellés à partir du stockage d'objets, selon les besoins, et effectuent une recherche au niveau des segments.
- Les résultats de la recherche font l'objet d'une réduction à plusieurs niveaux : Les nœuds de requête réduisent les résultats sur plusieurs segments, les nœuds de diffusion en continu réduisent les résultats des nœuds de requête et le mandataire réduit les résultats de tous les nœuds de diffusion en continu avant de les renvoyer au client.
Exemple de flux de données : insertion de données
- Le client envoie une demande d'insertion avec des données vectorielles.
- La couche d'accès valide et transmet la demande au nœud de diffusion en continu.
- Le nœud de streaming enregistre l'opération dans le stockage WAL à des fins de durabilité.
- Les données sont traitées en temps réel et mises à disposition pour les requêtes.
- Lorsque les segments atteignent leur capacité, le nœud de diffusion en continu déclenche la conversion en segments scellés.
- Le nœud de données gère le compactage et construit des index sur les segments scellés, en stockant les résultats dans le stockage d'objets.
- Les nœuds de requête chargent les index nouvellement construits et remplacent les données croissantes correspondantes.
À suivre
- Explorez les composants principaux pour obtenir des informations détaillées sur la mise en œuvre.
- Découvrez les flux de traitement des données et les stratégies d'optimisation
- Comprendre le modèle de cohérence et les garanties de transaction dans Milvus