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 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

Les nœuds de requête récupèrent les données incrémentales des journaux et les transforment en segments croissants en s'abonnant au courtier de journaux, chargent les données historiques à partir du stockage d'objets et exécutent des recherches hybrides entre les données vectorielles et scalaires.

Nœud de données

Les nœuds de données récupèrent les données incrémentielles du journal en s'abonnant au courtier du journal, traitent les demandes de mutation et regroupent les données du journal dans des instantanés du journal et les stockent dans le stockage d'objets.

Nœud d'index

Les nœuds d'index construisent des index. Ils n'ont pas besoin d'être 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 à cette fin. Milvus utilise également etcd pour l'enregistrement des services et les contrôles de santé.

Stockage d'objets

Le stockage d'objets permet de stocker des fichiers instantanés de journaux, des fichiers d'index pour les données scalaires et vectorielles, ainsi que des 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. Milvus Distributed utilise Pulsar comme courtier de protocole, tandis que Milvus Standalone utilise RocksDB. Le courtier en journaux peut être facilement remplacé par des plateformes de stockage de données en continu telles que Kafka.

Milvus suit le principe du "log as data", c'est-à-dire que Milvus ne maintient pas de table physique mais garantit la fiabilité des données grâce à la persistance de la journalisation et aux journaux instantanés.

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.