Comment déployer la base de données vectorielle Open-Source Milvus sur Amazon EKS
Ce billet a été publié à l'origine sur le site web d'AWS et est traduit, édité et rediffusé ici avec l'autorisation de l'auteur.
Vue d'ensemble des embarquements vectoriels et des bases de données vectorielles
L'essor de l'IA générative (GenAI), en particulier des grands modèles de langage(LLM), a considérablement stimulé l'intérêt pour les bases de données vectorielles, les établissant comme un composant essentiel au sein de l'écosystème GenAI. En conséquence, les bases de données vectorielles sont de plus en plus utilisées.
Un rapport IDC prévoit que d'ici 2025, plus de 80 % des données commerciales seront non structurées et existeront dans des formats tels que le texte, les images, le son et les vidéos. La compréhension, le traitement, le stockage et l'interrogation de cette vaste quantité de données non structurées à grande échelle représentent un défi de taille. La pratique courante en GenAI et en apprentissage profond consiste à transformer les données non structurées en encastrements vectoriels, à les stocker et à les indexer dans une base de données vectorielle comme Milvus ou Zilliz Cloud (Milvus entièrement géré) pour les recherches de similarité vectorielle ou de similarité sémantique.
Mais que sont exactement les embeddings vectoriels? En termes simples, il s'agit de représentations numériques de nombres à virgule flottante dans un espace à haute dimension. La distance entre deux vecteurs indique leur pertinence : plus ils sont proches, plus ils sont pertinents l'un par rapport à l'autre, et vice versa. Cela signifie que des vecteurs similaires correspondent à des données originales similaires, ce qui diffère des recherches traditionnelles par mots clés ou exactes.
Comment effectuer une recherche de similarité vectorielle
Figure 1 : Comment effectuer une recherche de similarité vectorielle ?
La capacité de stocker, d'indexer et de rechercher des vecteurs intégrés est la fonctionnalité principale des bases de données vectorielles. Actuellement, les bases de données vectorielles courantes se répartissent en deux catégories. La première catégorie étend les produits de bases de données relationnelles existants, comme Amazon OpenSearch Service avec le plugin KNN et Amazon RDS pour PostgreSQL avec l'extension pgvector. La deuxième catégorie comprend des produits de bases de données vectorielles spécialisées, y compris des exemples bien connus comme Milvus, Zilliz Cloud (Milvus entièrement géré), Pinecone, Weaviate, Qdrant et Chroma.
Les techniques d'intégration et les bases de données vectorielles ont de vastes applications dans divers cas d'utilisation axés sur l'IA, notamment la recherche de similitudes d'images, la déduplication et l'analyse de vidéos, le traitement du langage naturel, les systèmes de recommandation, la publicité ciblée, la recherche personnalisée, le service client intelligent et la détection des fraudes.
Milvus est l'une des options open-source les plus populaires parmi les nombreuses bases de données vectorielles. Ce billet présente Milvus et explore la pratique du déploiement de Milvus sur AWS EKS.
Qu'est-ce que Milvus ?
Milvus est une base de données vectorielles open-source extrêmement flexible, fiable et rapide. Elle alimente la recherche de similarités vectorielles et les applications d'IA et s'efforce de rendre les bases de données vectorielles accessibles à toutes les organisations. Milvus peut stocker, indexer et gérer plus d'un milliard d'encastrements vectoriels générés par des réseaux neuronaux profonds et d'autres modèles d'apprentissage automatique.
Milvus a été publié sous la licence open-source Apache License 2.0 en octobre 2019. Il s'agit actuellement d'un projet diplômé de la LF AI & Data Foundation. Au moment de la rédaction de ce blog, Milvus avait atteint plus de 50 millions de téléchargements Docker pull et était utilisé par de nombreux clients, tels que NVIDIA, AT&T, IBM, eBay, Shopee et Walmart.
Principales caractéristiques de Milvus
En tant que base de données vectorielles native dans le nuage, Milvus présente les caractéristiques clés suivantes :
Haute performance et recherche à la milliseconde sur des ensembles de données vectorielles à l'échelle du milliard.
Prise en charge et chaîne d'outils multilingues.
Évolutivité horizontale et grande fiabilité, même en cas d'interruption.
Recherche hybride, obtenue en associant le filtrage scalaire à la recherche de similarité vectorielle.
Architecture de Milvus
Milvus suit le principe de la séparation du flux de données et du flux de contrôle. Le système se décompose en quatre niveaux, comme le montre le diagramme :
Architecture Milvus
Figure 2 Architecture Milvus
Couche d'accès : La couche d'accès est composée d'un groupe de mandataires sans état et sert de couche frontale du système et de point final pour les utilisateurs.
Service de coordination : Le service de coordination attribue des tâches aux nœuds de travail.
Nœuds de travail : Les nœuds de travail sont des exécutants idiots qui suivent les instructions du service de coordination et exécutent les commandes DML/DDL déclenchées par l'utilisateur.
Stockage : Le stockage est responsable de la persistance des données. Il comprend un méta stockage, un courtier de journaux et un stockage d'objets.
Options de déploiement de Milvus
Milvus prend en charge trois modes d'exécution : Milvus Lite, Standalone et Distributed.
Milvus Lite est une bibliothèque Python qui peut être importée dans des applications locales. En tant que version légère de Milvus, elle est idéale pour le prototypage rapide dans les blocs-notes Jupyter ou l'exécution sur des appareils intelligents avec des ressources limitées.
Milvus Standalone estun déploiement de serveur sur une seule machine. Si vous avez une charge de travail de production mais préférez ne pas utiliser Kubernetes, l'exécution de Milvus Standalone sur une seule machine avec suffisamment de mémoire est une bonne option.
Milvus Distributed peut être déployé sur des clusters Kubernetes. Il prend en charge des ensembles de données plus importants, une plus grande disponibilité et une meilleure évolutivité, et convient mieux aux environnements de production.
Milvus est conçu dès le départ pour prendre en charge Kubernetes et peut être facilement déployé sur AWS. Nous pouvons utiliser Amazon Elastic Kubernetes Service (Amazon EKS) comme Kubernetes géré, Amazon S3 comme stockage d'objets, Amazon Managed Streaming for Apache Kafka (Amazon MSK) comme stockage de messages et Amazon Elastic Load Balancing (Amazon ELB) comme équilibreur de charge pour construire un cluster de base de données Milvus fiable et élastique.
Ensuite, nous fournirons des conseils étape par étape sur le déploiement d'un cluster Milvus à l'aide d'EKS et d'autres services.
Déploiement de Milvus sur AWS EKS
Conditions préalables
Nous utiliserons AWS CLI pour créer un cluster EKS et déployer une base de données Milvus. Les conditions suivantes sont requises :
Un PC/Mac ou une instance Amazon EC2 avec AWS CLI installé et configuré avec les autorisations appropriées. Les outils AWS CLI sont installés par défaut si vous utilisez Amazon Linux 2 ou Amazon Linux 2023.
Lesoutils EKS sont installés, y compris Helm, Kubectl, eksctl, etc.
Un panier Amazon S3.
Une instance Amazon MSK.
Éléments à prendre en compte lors de la création de MSK
- La dernière version stable de Milvus (v2.3.13) dépend de la fonctionnalité
autoCreateTopics
de Kafka. Ainsi, lors de la création de MSK, nous devons utiliser une configuration personnalisée et modifier la propriétéauto.create.topics.enable
de la valeur par défautfalse
àtrue
. En outre, pour augmenter le débit de messages de MSK, il est recommandé d'augmenter les valeurs demessage.max.bytes
etreplica.fetch.max.bytes
. Voir Configurations MSK personnalisées pour plus de détails.
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
- Milvus ne prend pas en charge l'authentification IAM basée sur les rôles de MSK. Ainsi, lors de la création de MSK, activer l'option
SASL/SCRAM authentication
dans la configuration de sécurité et configurerusername
etpassword
dans AWS Secrets Manager. Voir l'authentification des identifiants de connexion avec AWS Secrets Manager pour plus de détails.
Figure 3 : Paramètres de sécurité : activer l'authentification SASL SCRAM.png
Figure 3 : Paramètres de sécurité : activer l'authentification SASL/SCRAM
- Nous devons activer l'accès au groupe de sécurité MSK à partir du groupe de sécurité ou de la plage d'adresses IP du cluster EKS.
Création d'un cluster EKS
Il existe de nombreuses façons de créer un cluster EKS, notamment via la console, CloudFormation, eksctl, etc. Ce billet montrera comment créer un cluster EKS à l'aide d'eksctl.
eksctl
eksctl est un outil de ligne de commande simple pour créer et gérer des clusters Kubernetes sur Amazon EKS. Il fournit le moyen le plus rapide et le plus facile de créer un nouveau cluster avec des nœuds pour Amazon EKS. Voir le site web d'eksctl pour plus d'informations.
- Tout d'abord, créez un fichier
eks_cluster.yaml
avec l'extrait de code suivant. Remplacezcluster-name
par le nom de votre cluster,region-code
par la région AWS où vous souhaitez créer le cluster etprivate-subnet-idx
par vos sous-réseaux privés. Remarque : ce fichier de configuration crée un cluster EKS dans un VPC existant en spécifiant des sous-réseaux privés. Si vous souhaitez créer un nouveau VPC, supprimez la configuration du VPC et des sous-réseaux, et le siteeksctl
en créera automatiquement un nouveau.
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: <cluster-name>
region: <region-code>
version: "1.26"
iam:
withOIDC: true
serviceAccounts:
- metadata:
name: aws-load-balancer-controller
namespace: kube-system
wellKnownPolicies:
awsLoadBalancerController: true
- metadata:
name: milvus-s3-access-sa
# if no namespace is set, "default" will be used;
# the namespace will be created if it doesn't exist already
namespace: milvus
labels: {aws-usage: "milvus"}
attachPolicyARNs:
- "arn:aws:iam::aws:policy/AmazonS3FullAccess"
# Use existed VPC to create EKS.
# If you don't config vpc subnets, eksctl will automatically create a brand new VPC
vpc:
subnets:
private:
us-west-2a: { id: <private-subnet-id1> }
us-west-2b: { id: <private-subnet-id2> }
us-west-2c: { id: <private-subnet-id3> }
managedNodeGroups:
- name: ng-1-milvus
labels: { role: milvus }
instanceType: m6i.2xlarge
desiredCapacity: 3
privateNetworking: true
addons:
- name: vpc-cni # no version is specified so it deploys the default version
attachPolicyARNs:
- arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
- name: coredns
version: latest # auto discovers the latest available
- name: kube-proxy
version: latest
- name: aws-ebs-csi-driver
wellKnownPolicies: # add IAM and service account
ebsCSIController: true
- Ensuite, exécutez la commande
eksctl
pour créer le cluster EKS.
eksctl create cluster -f eks_cluster.yaml
Cette commande créera les ressources suivantes :
Un cluster EKS avec la version spécifiée.
Un groupe de nœuds gérés avec trois instances EC2 m6i.2xlarge.
Un fournisseur d'identité IAM OIDC et un ServiceAccount appelé
aws-load-balancer-controller
, que nous utiliserons plus tard lors de l'installation du contrôleur AWS Load Balancer.Un espace de noms
milvus
et un ServiceAccountmilvus-s3-access-sa
dans cet espace de noms. Cet espace de noms sera utilisé ultérieurement lors de la configuration de S3 en tant que stockage d'objets pour Milvus.Remarque : pour des raisons de simplicité, le site
milvus-s3-access-sa
bénéficie ici de toutes les autorisations d'accès à S3. Dans les déploiements en production, il est recommandé de suivre le principe du moindre privilège et de n'accorder l'accès qu'au seau S3 spécifique utilisé pour Milvus.Multiple add-ons, où
vpc-cni
,coredns
,kube-proxy
sont des add-ons de base requis par EKS.aws-ebs-csi-driver
est le pilote AWS EBS CSI qui permet aux clusters EKS de gérer le cycle de vie des volumes Amazon EBS.
Il ne nous reste plus qu'à attendre la fin de la création du cluster.
Attendez la fin de la création du cluster. Au cours du processus de création du cluster, le fichier kubeconfig
sera automatiquement créé ou mis à jour. Vous pouvez également le mettre à jour manuellement en exécutant la commande suivante. Veillez à remplacer region-code
par la région AWS dans laquelle votre cluster est créé et cluster-name
par le nom de votre cluster.
aws eks update-kubeconfig --region <region-code> --name <cluster-name>
Une fois le cluster créé, vous pouvez afficher les nœuds en exécutant la commande suivante :
kubectl get nodes -A -o wide
- Créez une StorageClass
ebs-sc
configurée avec GP3 comme type de stockage et définissez-la comme StorageClass par défaut. Milvus utilise etcd comme méta stockage et a besoin de cette StorageClass pour créer et gérer les PVC.
cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
EOF
Ensuite, définissez la StorageClass d'origine gp2
comme n'étant pas une classe par défaut :
kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
- Installer le contrôleur AWS Load Balancer. Nous utiliserons ce contrôleur plus tard pour le service Milvus et Attu Ingress, donc installons-le au préalable.
- Tout d'abord, ajoutez le repo
eks-charts
et mettez-le à jour.
helm repo add eks https://aws.github.io/eks-charts
helm repo update
- Ensuite, installez le contrôleur AWS Load Balancer. Remplacez
cluster-name
par le nom de votre cluster. Le ServiceAccount nomméaws-load-balancer-controller
a déjà été créé lorsque nous avons créé le cluster EKS dans les étapes précédentes.
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=<cluster-name> \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller
- Vérifiez que le contrôleur a été installé avec succès.
kubectl get deployment -n kube-system aws-load-balancer-controller
- La sortie doit ressembler à ceci :
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 12m
Déploiement d'un cluster Milvus
Milvus prend en charge plusieurs méthodes de déploiement, telles que Operator et Helm. Operator est plus simple, mais Helm est plus direct et plus flexible. Dans cet exemple, nous utiliserons Helm pour déployer Milvus.
Lors du déploiement de Milvus avec Helm, vous pouvez personnaliser la configuration via le fichier values.yaml
. Cliquez sur values.yaml pour afficher toutes les options. Par défaut, Milvus crée dans le cluster minio et pulsar en tant que stockage d'objets et stockage de messages, respectivement. Nous allons apporter quelques modifications à la configuration pour la rendre plus adaptée à la production.
- Tout d'abord, ajoutez le repo Milvus Helm et mettez-le à jour.
helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
- Créez un fichier
milvus_cluster.yaml
avec l'extrait de code suivant. Cet extrait de code personnalise la configuration de Milvus, par exemple en configurant Amazon S3 comme stockage d'objets et Amazon MSK comme file d'attente de messages. Nous fournirons des explications détaillées et des conseils de configuration ultérieurement.
#####################################
# Section 1
#
# Configure S3 as the Object Storage
#####################################
# Service account
# - this service account are used by External S3 access
serviceAccount:
create: false
name: milvus-s3-access-sa
# Close in-cluster minio
minio:
enabled: false
# External S3
# - these configs are only used when `externalS3.enabled` is true
externalS3:
enabled: true
host: "s3.<region-code>.amazonaws.com"
port: "443"
useSSL: true
bucketName: "<bucket-name>"
rootPath: "<root-path>"
useIAM: true
cloudProvider: "aws"
iamEndpoint: ""
#####################################
# Section 2
#
# Configure MSK as the Message Storage
#####################################
# Close in-cluster pulsar
pulsar:
enabled: false
# External kafka
# - these configs are only used when `externalKafka.enabled` is true
externalKafka:
enabled: true
brokerList: "<broker-list>"
securityProtocol: SASL_SSL
sasl:
mechanisms: SCRAM-SHA-512
username: "<username>"
password: "<password>"
#####################################
# Section 3
#
# Expose the Milvus service to be accessed from outside the cluster (LoadBalancer service).
# or access it from within the cluster (ClusterIP service). Set the service type and the port to serve it.
#####################################
service:
type: LoadBalancer
port: 19530
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: external #AWS Load Balancer Controller fulfills services that has this annotation
service.beta.kubernetes.io/aws-load-balancer-name : milvus-service #User defined name given to AWS Network Load Balancer
service.beta.kubernetes.io/aws-load-balancer-scheme: internal # internal or internet-facing, later allowing for public access via internet
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip #The Pod IPs should be used as the target IPs (rather than the node IPs)
#####################################
# Section 4
#
# Installing Attu the Milvus management GUI
#####################################
attu:
enabled: true
name: attu
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: alb # Annotation: set ALB ingress type
alb.ingress.kubernetes.io/scheme: internet-facing #Places the load balancer on public subnets
alb.ingress.kubernetes.io/target-type: ip #The Pod IPs should be used as the target IPs (rather than the node IPs)
alb.ingress.kubernetes.io/group.name: attu # Groups multiple Ingress resources
hosts:
-
#####################################
# Section 5
#
# HA deployment of Milvus Core Components
#####################################
rootCoordinator:
replicas: 2
activeStandby:
enabled: true # Enable active-standby when you set multiple replicas for root coordinator
resources:
limits:
cpu: 1
memory: 2Gi
indexCoordinator:
replicas: 2
activeStandby:
enabled: true # Enable active-standby when you set multiple replicas for index coordinator
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
queryCoordinator:
replicas: 2
activeStandby:
enabled: true # Enable active-standby when you set multiple replicas for query coordinator
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
dataCoordinator:
replicas: 2
activeStandby:
enabled: true # Enable active-standby when you set multiple replicas for data coordinator
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
proxy:
replicas: 2
resources:
limits:
cpu: 1
memory: 4Gi
#####################################
# Section 6
#
# Milvus Resource Allocation
#####################################
queryNode:
replicas: 1
resources:
limits:
cpu: 2
memory: 8Gi
dataNode:
replicas: 1
resources:
limits:
cpu: 1
memory: 4Gi
indexNode:
replicas: 1
resources:
limits:
cpu: 4
memory: 8Gi
Le code contient six sections. Suivez les instructions suivantes pour modifier les configurations correspondantes.
Section 1: Configurer S3 comme stockage d'objets. Le serviceAccount accorde à Milvus l'accès à S3 (dans ce cas, il s'agit de milvus-s3-access-sa
, qui a été créé lorsque nous avons créé le cluster EKS). Veillez à remplacer <region-code>
par la région AWS où se trouve votre cluster. Remplacez <bucket-name>
par le nom de votre seau S3 et <root-path>
par le préfixe du seau S3 (ce champ peut être laissé vide).
Section 2: Configurer MSK comme stockage de messages. Remplacez <broker-list>
par les adresses des points d'extrémité correspondant au type d'authentification SASL/SCRAM de MSK. Remplacez <username>
et <password>
par le nom d'utilisateur et le mot de passe du compte MSK. Vous pouvez obtenir l'adresse <broker-list>
à partir des informations du client MSK, comme le montre l'image ci-dessous.
Figure 4 : Configurer MSK en tant que stockage de messages de Milvus.png
Figure 4 : Configurer MSK en tant que stockage de messages de Milvus
Section 3 : Exposer le service Milvus et permettre l'accès depuis l'extérieur du cluster. Le point d'extrémité Milvus utilise par défaut un service de type ClusterIP, qui n'est accessible qu'à l'intérieur du cluster EKS. Si nécessaire, vous pouvez le changer pour un service de type LoadBalancer afin de permettre l'accès depuis l'extérieur du cluster EKS. Le service de type LoadBalancer utilise Amazon NLB comme équilibreur de charge. Conformément aux meilleures pratiques en matière de sécurité, aws-load-balancer-scheme
est configuré par défaut en mode interne, ce qui signifie que seul l'accès intranet à Milvus est autorisé. Cliquez pour voir les instructions de configuration NLB.
Section 4 : Installer et configurer Attu, un outil d'administration milvus open-source. Il dispose d'une interface graphique intuitive qui vous permet d'interagir facilement avec Milvus. Nous activons Attu, configurons l'entrée à l'aide d'AWS ALB et la définissons sur le type internet-facing
afin qu'Attu soit accessible via Internet. Cliquez sur ce document pour obtenir le guide de la configuration ALB.
Section 5 : activer le déploiement HA des composants principaux de Milvus. Milvus contient plusieurs composants indépendants et découplés. Par exemple, le service de coordination agit en tant que couche de contrôle, gérant la coordination des composants Racine, Requête, Données et Index. Le proxy de la couche d'accès sert de point d'accès à la base de données. Par défaut, ces composants ne comportent qu'une seule réplique de pod. Le déploiement de plusieurs répliques de ces composants de service est particulièrement nécessaire pour améliorer la disponibilité de Milvus.
Remarque : le déploiement multiréplique des composants Root, Query, Data et Index coordinator nécessite l'activation de l'option activeStandby
.
Section 6 : Ajustez l'allocation des ressources pour les composants Milvus afin de répondre aux exigences de vos charges de travail. Le site Web de Milvus propose également un outil de dimensionnement qui génère des suggestions de configuration en fonction du volume de données, des dimensions des vecteurs, des types d'index, etc. Il peut également générer un fichier de configuration Helm en un seul clic. La configuration suivante est la suggestion donnée par l'outil pour 1 million de vecteurs de 1024 dimensions et un type d'index HNSW.
- Utilisez Helm pour créer Milvus (déployé dans l'espace de noms
milvus
). Remarque : vous pouvez remplacer<demo>
par un nom personnalisé.
helm install <demo> milvus/milvus -n milvus -f milvus_cluster.yaml
- Exécutez la commande suivante pour vérifier l'état du déploiement.
kubectl get deployment -n milvus
La sortie suivante montre que les composants Milvus sont tous DISPONIBLES et que les composants de coordination ont plusieurs répliques activées.
NAME READY UP-TO-DATE AVAILABLE AGE
demo-milvus-attu 1/1 1 1 5m27s
demo-milvus-datacoord 2/2 2 2 5m27s
demo-milvus-datanode 1/1 1 1 5m27s
demo-milvus-indexcoord 2/2 2 2 5m27s
demo-milvus-indexnode 1/1 1 1 5m27s
demo-milvus-proxy 2/2 2 2 5m27s
demo-milvus-querycoord 2/2 2 2 5m27s
demo-milvus-querynode 1/1 1 1 5m27s
demo-milvus-rootcoord 2/2 2 2 5m27s
Accès et gestion de Milvus
Jusqu'à présent, nous avons déployé avec succès la base de données vectorielle Milvus. Nous pouvons maintenant accéder à Milvus par le biais de points d'extrémité. Milvus expose des points finaux via les services Kubernetes. Attu expose les points d'extrémité via Kubernetes Ingress.
Accès aux points d'extrémité de Milvus
Exécutez la commande suivante pour obtenir les points de terminaison des services :
kubectl get svc -n milvus
Vous pouvez voir plusieurs services. Milvus prend en charge deux ports, le port 19530
et le port 9091
:
- Le port
19530
est destiné à gRPC et à l'API RESTful. C'est le port par défaut lorsque vous vous connectez à un serveur Milvus avec différents SDK Milvus ou clients HTTP. - Le port
9091
est un port de gestion pour la collecte de métriques, le profilage pprof et les sondes de santé dans Kubernetes.
Le service demo-milvus
fournit un point d'accès à la base de données, qui est utilisé pour établir une connexion à partir des clients. Il utilise NLB comme équilibreur de charge. Vous pouvez obtenir le point d'extrémité du service à partir de la colonne EXTERNAL-IP
.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demo-etcd ClusterIP 172.20.103.138 <none> 2379/TCP,2380/TCP 62m
demo-etcd-headless ClusterIP None <none> 2379/TCP,2380/TCP 62m
demo-milvus LoadBalancer 172.20.219.33 milvus-nlb-xxxx.elb.us-west-2.amazonaws.com 19530:31201/TCP,9091:31088/TCP 62m
demo-milvus-datacoord ClusterIP 172.20.214.106 <none> 13333/TCP,9091/TCP 62m
demo-milvus-datanode ClusterIP None <none> 9091/TCP 62m
demo-milvus-indexcoord ClusterIP 172.20.106.51 <none> 31000/TCP,9091/TCP 62m
demo-milvus-indexnode ClusterIP None <none> 9091/TCP 62m
demo-milvus-querycoord ClusterIP 172.20.136.213 <none> 19531/TCP,9091/TCP 62m
demo-milvus-querynode ClusterIP None <none> 9091/TCP 62m
demo-milvus-rootcoord ClusterIP 172.20.173.98 <none> 53100/TCP,9091/TCP 62m
Gestion de Milvus à l'aide d'Attu
Comme décrit précédemment, nous avons installé Attu pour gérer Milvus. Exécutez la commande suivante pour obtenir le point final :
kubectl get ingress -n milvus
Vous pouvez voir un Ingress appelé demo-milvus-attu
, où la colonne ADDRESS
est l'URL d'accès.
NAME CLASS HOSTS ADDRESS PORTS AGE
demo-milvus-attu <none> * k8s-attu-xxxx.us-west-2.elb.amazonaws.com 80 27s
Ouvrez l'adresse Ingress dans un navigateur et voyez la page suivante. Cliquez sur Connecter pour vous connecter.
Figure 5 : Connectez-vous à votre compte Attu.png
Figure 5 : Connexion à votre compte Attu
Après vous être connecté, vous pouvez gérer les bases de données Milvus via Attu.
Figure 6 L'interface Attu.png
Figure 6 : L'interface Attu
Test de la base de données vectorielle Milvus
Nous allons utiliser le code d'exemple Milvus pour tester le bon fonctionnement de la base de données Milvus. Tout d'abord, téléchargez le code d'exemple hello_milvus.py
à l'aide de la commande suivante :
wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py
Modifiez l'hôte dans le code d'exemple en point d'extrémité du service Milvus.
print(fmt.format("start connecting to Milvus"))
connections.connect("default", host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com", port="19530")
Exécutez le code :
python3 hello_milvus.py
Si le système renvoie le résultat suivant, cela signifie que Milvus fonctionne normalement.
=== start connecting to Milvus ===
Does collection hello_milvus exist in Milvus: False
=== Create collection `hello_milvus` ===
=== Start inserting entities ===
Number of entities in Milvus: 3000
=== Start Creating index IVF_FLAT ===
=== Start loading ===
Conclusion
Cet article présente Milvus, l'une des bases de données vectorielles open-source les plus populaires, et fournit un guide sur le déploiement de Milvus sur AWS à l'aide de services gérés tels qu'Amazon EKS, S3, MSK et ELB pour obtenir une plus grande élasticité et une plus grande fiabilité.
En tant que composant central de divers systèmes GenAI, en particulier Retrieval Augmented Generation (RAG), Milvus prend en charge et s'intègre à une variété de modèles et de cadres GenAI courants, notamment Amazon Sagemaker, PyTorch, HuggingFace, LlamaIndex et LangChain. Commencez votre voyage d'innovation GenAI avec Milvus dès aujourd'hui !
Références
- Vue d'ensemble des embarquements vectoriels et des bases de données vectorielles
- Qu'est-ce que Milvus ?
- Déploiement de Milvus sur AWS EKS
- Test de la base de données vectorielle Milvus
- Conclusion
- Références
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