Vue d'ensemble de l'architecture distribuée
Milvus vise à réaliser une recherche de similarité et une analyse efficaces pour les vecteurs à grande échelle. Une instance autonome de Milvus peut facilement gérer la recherche vectorielle pour des vecteurs à l'échelle du milliard. Cependant, pour des ensembles de données de 10 milliards, 100 milliards ou même plus, un cluster Milvus est nécessaire. Le cluster peut être utilisé comme une instance autonome pour des applications de niveau supérieur et peut répondre aux besoins de l'entreprise en matière de faible latence et de forte concurrence pour les données à grande échelle. Un cluster Milvus peut renvoyer des requêtes, séparer la lecture de l'écriture, s'étendre horizontalement et dynamiquement, fournissant ainsi une instance Milvus qui peut s'étendre sans limite. Mishards est une solution distribuée pour Milvus.
Cet article présente brièvement les composants de l'architecture Mishards. Des informations plus détaillées seront présentées dans les prochains articles.
1-milvus-cluster-mishards.png
Vue d'ensemble de l'architecture distribuée
2-architecture-distribuée-overview.png
Traçage des services
3-service-tracing-milvus.png
Principaux composants des services
- Cadre de découverte des services, tel que ZooKeeper, etcd et Consul.
- Équilibreur de charge, tel que Nginx, HAProxy, Ingress Controller.
- Nœud Mishards : sans état, évolutif.
- Nœud Milvus en écriture seule : nœud unique et non évolutif. Vous devez utiliser des solutions de haute disponibilité pour ce nœud afin d'éviter un point de défaillance unique.
- Nœud Milvus en lecture seule : Nœud avec état et évolutif.
- Service de stockage partagé : Tous les nœuds Milvus utilisent un service de stockage partagé pour partager les données, tel que NAS ou NFS.
- Service de métadonnées : Tous les nœuds Milvus utilisent ce service pour partager des métadonnées. Actuellement, seul MySQL est pris en charge. Ce service nécessite une solution de haute disponibilité MySQL.
Composants évolutifs
- Mishards
- Nœuds Milvus en lecture seule
Présentation des composants
Nœuds Mishards
Mishards est responsable de la décomposition des demandes en amont et de l'acheminement des sous-demandes vers les sous-services. Les résultats sont résumés pour être renvoyés en amont.
4-noeuds-mishards.jpg
Comme l'indique le graphique ci-dessus, après avoir accepté une demande de recherche TopK, Mishards décompose d'abord la demande en sous-demandes et envoie les sous-demandes au service en aval. Lorsque toutes les sous-réponses sont collectées, elles sont fusionnées et renvoyées en amont.
Mishards étant un service sans état, il n'enregistre pas de données et ne participe pas à des calculs complexes. Les nœuds n'ont donc pas d'exigences élevées en matière de configuration et la puissance de calcul est principalement utilisée pour fusionner les sous-résultats. Il est donc possible d'augmenter le nombre de nœuds Mishards pour obtenir une concurrence élevée.
Nœuds Milvus
Les nœuds Milvus sont responsables des opérations de base liées au CRUD et ont donc des exigences de configuration relativement élevées. Tout d'abord, la taille de la mémoire doit être suffisante pour éviter un trop grand nombre d'opérations d'E/S sur disque. Ensuite, la configuration de l'unité centrale peut également affecter les performances. Au fur et à mesure que la taille du cluster augmente, davantage de nœuds Milvus sont nécessaires pour accroître le débit du système.
Nœuds en lecture seule et nœuds en écriture
- Les opérations principales de Milvus sont l'insertion et la recherche de vecteurs. La recherche est extrêmement exigeante pour les configurations de CPU et de GPU, alors que l'insertion ou d'autres opérations sont relativement peu exigeantes. Séparer le nœud qui exécute la recherche du nœud qui exécute les autres opérations permet un déploiement plus économique.
- En termes de qualité de service, lorsqu'un nœud effectue des opérations de recherche, le matériel connexe fonctionne à pleine charge et ne peut pas garantir la qualité de service des autres opérations. C'est pourquoi deux types de nœuds sont utilisés. Les demandes de recherche sont traitées par des nœuds en lecture seule et les autres demandes sont traitées par des nœuds en écriture.
Un seul nœud inscriptible est autorisé
Actuellement, Milvus ne prend pas en charge le partage des données pour plusieurs instances inscriptibles.
Lors du déploiement, un point de défaillance unique des nœuds inscriptibles doit être envisagé. Des solutions de haute disponibilité doivent être préparées pour les nœuds inscriptibles.
Évolutivité des nœuds en lecture seule
Lorsque la taille des données est très importante ou que les exigences en matière de latence sont très élevées, vous pouvez faire évoluer horizontalement les nœuds en lecture seule en tant que nœuds avec état. Supposons qu'il y ait 4 hôtes et que chacun ait la configuration suivante : CPU Cores : 16, GPU : 1, Mémoire : 64 Go. Le graphique suivant montre le cluster lors de la mise à l'échelle horizontale des nœuds à état. La puissance de calcul et la mémoire évoluent linéairement. Les données sont réparties en 8 zones, chaque nœud traitant les requêtes de 2 zones.
5-read-only-node-scalability-milvus.png
Lorsque le nombre de requêtes est important pour certains domaines, des nœuds en lecture seule sans état peuvent être déployés pour ces domaines afin d'augmenter le débit. Prenons l'exemple des hôtes ci-dessus. Lorsque les hôtes sont combinés en un cluster sans serveur, la puissance de calcul augmente de façon linéaire. Comme les données à traiter n'augmentent pas, la puissance de traitement pour le même groupe de données augmente également de façon linéaire.
6-read-only-node-scalability-milvus-2.png
Service de métadonnées
Mots clés : MySQL
Pour plus d'informations sur les métadonnées Milvus, voir Comment afficher les métadonnées. Dans un système distribué, les nœuds inscriptibles Milvus sont les seuls producteurs de métadonnées. Les nœuds Mishards, les nœuds inscriptibles Milvus et les nœuds en lecture seule Milvus sont tous des consommateurs de métadonnées. Actuellement, Milvus ne prend en charge que MySQL et SQLite pour le stockage des métadonnées. Dans un système distribué, le service ne peut être déployé qu'en tant que MySQL hautement disponible.
Découverte du service
Mots-clés : Apache Zookeeper, etcd, Consul, Kubernetes
7-decouverte-de-services.png
La découverte de services fournit des informations sur tous les nœuds Milvus. Les nœuds Milvus enregistrent leurs informations lorsqu'ils sont en ligne et se déconnectent lorsqu'ils sont hors ligne. Les nœuds Milvus peuvent également détecter les nœuds anormaux en vérifiant périodiquement l'état de santé des services.
La découverte de services comprend de nombreux cadres, notamment etcd, Consul, ZooKeeper, etc. Mishards définit les interfaces de découverte de services et offre des possibilités de mise à l'échelle par des plugins. Actuellement, Mishards fournit deux types de plugins, qui correspondent aux configurations statiques et aux clusters Kubernetes. Vous pouvez personnaliser votre propre découverte de services en suivant l'implémentation de ces plugins. Les interfaces sont temporaires et doivent être remaniées. Plus d'informations sur l'écriture de votre propre plugin seront développées dans les prochains articles.
Équilibrage de charge et répartition des services
Mots-clés : Nginx, HAProxy, Kubernetes
7-load-balancing-and-service-sharding.png
La découverte de services et l'équilibrage de charge sont utilisés ensemble. L'équilibrage de charge peut être configuré comme une interrogation, un hachage ou un hachage cohérent.
L'équilibreur de charge est chargé de renvoyer les demandes des utilisateurs au nœud Mishards.
Chaque nœud Mishards acquiert les informations de tous les nœuds Milvus en aval via le centre de découverte de services. Toutes les métadonnées connexes peuvent être obtenues par le service de métadonnées. Mishards implémente le sharding en consommant ces ressources. Mishards définit les interfaces liées aux stratégies de routage et fournit des extensions via des plugins. Actuellement, Mishards fournit une stratégie de hachage cohérente basée sur le niveau de segment le plus bas. Comme le montre le graphique, il y a 10 segments, de s1 à s10. Selon la stratégie de hachage cohérent basée sur les segments, Mishards achemine les demandes concernant s1, 24, s6 et s9 vers le nœud Milvus 1, s2, s3, s5 vers le nœud Milvus 2 et s7, s8, s10 vers le nœud Milvus 3.
En fonction des besoins de votre entreprise, vous pouvez personnaliser le routage en suivant le plugin de routage par hachage cohérent par défaut.
Traçage
Mots clés : OpenTracing, Jaeger, Zipkin
Étant donné la complexité d'un système distribué, les requêtes sont envoyées à de multiples invocations de services internes. Pour aider à identifier les problèmes, nous avons besoin de tracer la chaîne d'invocation des services internes. Au fur et à mesure que la complexité augmente, les avantages d'un système de traçage disponible s'expliquent d'eux-mêmes. Nous avons choisi le standard OpenTracing de la CNCF. OpenTracing fournit des API indépendantes de la plateforme et du fournisseur pour que les développeurs puissent facilement mettre en œuvre un système de traçage.
8-tracing-demo-milvus.png
Le graphique précédent est un exemple de traçage pendant l'invocation d'une recherche. La recherche invoque consécutivement get_routing
, do_search
et do_merge
. do_search
invoque également search_127.0.0.1
.
L'ensemble de l'enregistrement de traçage forme l'arbre suivant :
8-search-traceid-milvus.png
Le tableau suivant montre des exemples d'informations de requête/réponse et de balises pour chaque nœud :
request-response-info-tags-node-milvus.png
OpenTracing a été intégré à Milvus. De plus amples informations seront fournies dans les prochains articles.
Surveillance et alerte
Mots-clés : Prometheus, Grafana
10-monitor-alert-milvus.jpg
Résumé
En tant qu'intergiciel de service, Mishards intègre la découverte de services, le routage des requêtes, la fusion des résultats et le traçage. Une extension basée sur des plugins est également fournie. Actuellement, les solutions distribuées basées sur Mishards présentent encore les inconvénients suivants :
- Mishards utilise un proxy comme couche intermédiaire et a des coûts de latence.
- Les nœuds inscriptibles de Milvus sont des services à point unique.
- Le déploiement est compliqué lorsqu'il y a de multiples tiroirs et qu'un seul tiroir a plusieurs copies.
- Absence d'une couche de cache, comme l'accès aux métadonnées.
Nous corrigerons ces problèmes dans les prochaines versions afin que les Mishards puissent être appliqués à l'environnement de production plus facilement.
- Traçage des services
- Principaux composants des services
- Composants évolutifs
- Présentation des composants
- Nœuds Milvus
- Résumé
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word