Désagrégation stockage/informatique

Suivant le principe de la désagrégation du plan de données et du plan de contrôle, Milvus comprend quatre couches qui sont mutuellement indépendantes en termes d'évolutivité et de reprise après sinistre.

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 final pour les 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.

Service de coordination

Le service de coordination assigne des tâches aux nœuds de travail et fonctionne comme le cerveau du système. Les tâches qu'il prend en charge comprennent la gestion de la topologie de la grappe, l'équilibrage de la charge, la génération de l'horodatage, la déclaration des données et la gestion des données.

Il existe trois types de coordinateurs : le coordinateur racine (root coord), le coordinateur de données (data coord) et le coordinateur de requêtes (query coord).

Coordinateur racine (root coord)

Le coordinateur racine 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'émission de TSO (timestamp Oracle) et de time ticker.

Coordinateur des requêtes (query coord)

Le coordinateur de requêtes gère la topologie et l'équilibrage de la charge pour les nœuds de requêtes, ainsi que le transfert des segments croissants vers les segments scellés.

Coordinateur des données (data coord)

Le coordinateur de données gère la topologie des nœuds de données et des nœuds d'index, maintient les métadonnées et déclenche les opérations de vidage, de compactage et de construction d'index, ainsi que d'autres opérations sur les données en arrière-plan.

Nœuds de travail

Les bras et les jambes. Les nœuds de travail sont des exécutants muets qui suivent les instructions du service de coordination et exécutent les commandes DML (Data Manipulation Language) du proxy. 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 requête

Le nœud de requête récupère les données incrémentales du journal et les transforme en segments croissants en s'abonnant au courtier du journal, charge les données historiques à partir du stockage d'objets et exécute une recherche hybride entre les données vectorielles et scalaires.

Nœud de données

Le nœud de données récupère les données incrémentielles du journal en s'abonnant au courtier du journal, traite les demandes de mutation et rassemble les données du journal dans des instantanés du journal et les stocke dans le stockage d'objets.

Nœud d'index

Le nœud d'index construit des index. Les nœuds d'index n'ont pas besoin d'être résidents en mémoire et peuvent être mis en œuvre avec le framework sans serveur.

Stockage

Le stockage est l'os 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 tels 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 des services et le contrôle de l'état de santé.

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.

Courtier en journaux

Le log broker est un système pub-sub qui prend en charge la lecture. Il est responsable de la persistance des données en continu et de la notification des événements. Il assure également l'intégrité des données incrémentielles lorsque les nœuds de travail se remettent d'une panne du système. Le cluster Milvus utilise Pulsar en tant que log broker ; Milvus standalone utilise RocksDB en tant que log broker. En outre, le courtier en journaux peut être facilement remplacé par des plateformes de stockage de données en continu telles que Kafka.

Milvus est construit autour du log broker et suit le principe "log as data", Milvus ne maintient donc pas de table physique mais garantit la fiabilité des données grâce à la persistance du logging et aux snapshot logs.

Mécanisme de journalisation

Le log broker est l'épine dorsale de Milvus. Il est responsable de la persistance des données et de la désagrégation en lecture-écriture, grâce à son mécanisme inné pub-sub. L'illustration ci-dessus montre une représentation simplifiée du mécanisme, où le système est divisé en deux rôles, le courtier en journaux (pour maintenir la séquence de journaux) et l'abonné aux journaux. Le premier enregistre toutes les opérations qui modifient l'état des collections ; le second s'abonne à la séquence de journaux pour mettre à jour les données locales et fournit des services sous la forme de copies en lecture seule. Le mécanisme pub-sub permet également d'étendre le système en termes de capture des données de changement (CDC) et de déploiement distribué à l'échelle mondiale.

À suivre

• Lisez Composants principaux pour plus de détails sur l'architecture Milvus.