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.

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 construction d'index aux nœuds de données, et gère la topologie des segments et des vues de données.

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 l'interrogation des 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.

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

À suivre

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