Как развернуть базу данных Milvus Vector с открытым исходным кодом на Amazon EKS
Эта статья была первоначально опубликована на сайте AWS, переведена, отредактирована и опубликована здесь с разрешения.
Обзор векторных вкраплений и векторных баз данных
Развитие генеративного искусственного интеллекта (GenAI), в частности больших языковых моделей(LLM), значительно повысило интерес к векторным базам данных, сделав их важным компонентом экосистемы GenAI. В результате векторные базы данных находят все большее применение.
По прогнозам IDC, к 2025 году более 80 % бизнес-данных будут неструктурированными, существующими в таких форматах, как текст, изображения, аудио и видео. Понимание, обработка, хранение и запрос такого огромного количества неструктурированных данных в масштабе представляет собой серьезную проблему. Общепринятой практикой в GenAI и глубоком обучении является преобразование неструктурированных данных в векторные вкрапления, их хранение и индексация в векторных базах данных, таких как Milvus или Zilliz Cloud (полностью управляемый Milvus), для поиска по векторному сходству или семантическому сходству.
Но что же такое векторные вкрапления? Проще говоря, это числовые представления чисел с плавающей точкой в высокоразмерном пространстве. Расстояние между двумя векторами указывает на их релевантность: чем они ближе, тем более релевантны друг другу, и наоборот. Это означает, что похожие векторы соответствуют похожим исходным данным, что отличается от традиционного поиска по ключевым словам или точного поиска.
Как выполнить поиск векторного сходства
Рисунок 1: Как выполнить поиск векторного сходства
Возможность хранения, индексирования и поиска векторных вкраплений является основной функциональностью векторных баз данных. В настоящее время основные векторные базы данных делятся на две категории. Первая категория расширяет существующие продукты реляционных баз данных, такие как Amazon OpenSearch Service с плагином KNN и Amazon RDS для PostgreSQL с расширением pgvector. Вторая категория включает в себя специализированные продукты векторных баз данных, в том числе такие известные примеры, как Milvus, Zilliz Cloud (полностью управляемый Milvus), Pinecone, Weaviate, Qdrant и Chroma.
Методы встраивания и векторные базы данных находят широкое применение в различных сферах использования ИИ, включая поиск по сходству изображений, дедупликацию и анализ видео, обработку естественного языка, рекомендательные системы, целевую рекламу, персонализированный поиск, интеллектуальное обслуживание клиентов и выявление мошенничества.
Milvus - один из самых популярных вариантов с открытым исходным кодом среди многочисленных векторных баз данных. В этом посте мы познакомимся с Milvus и рассмотрим практику развертывания Milvus на AWS EKS.
Что такое Milvus?
Milvus - это очень гибкая, надежная и молниеносная облачная нативная векторная база данных с открытым исходным кодом. Она обеспечивает работу приложений для поиска векторных сходств и искусственного интеллекта и стремится сделать векторные базы данных доступными для каждой организации. Milvus может хранить, индексировать и управлять миллиардом с лишним векторных вкраплений, созданных глубокими нейронными сетями и другими моделями машинного обучения (ML).
Milvus был выпущен под лицензией Apache License 2.0 с открытым исходным кодом в октябре 2019 года. В настоящее время он является дипломным проектом LF AI & Data Foundation. На момент написания этого блога Milvus достиг более 50 миллионов загрузок Docker pull и используется многими клиентами, такими как NVIDIA, AT&T, IBM, eBay, Shopee и Walmart.
Ключевые особенности Milvus
Будучи облачной векторной базой данных, Milvus может похвастаться следующими ключевыми особенностями:
Высокая производительность и миллисекундный поиск в векторных наборах данных миллиардного масштаба.
Поддержка нескольких языков и набор инструментов.
Горизонтальная масштабируемость и высокая надежность даже в случае сбоев.
Гибридный поиск, достигаемый за счет объединения скалярной фильтрации с векторным поиском сходства.
Архитектура Milvus
Milvus следует принципу разделения потока данных и потока управления. Система состоит из четырех уровней, как показано на диаграмме:
Архитектура Milvus
Рисунок 2 Архитектура Milvus
Уровень доступа: Уровень доступа состоит из группы нестационарных прокси-серверов и служит в качестве переднего уровня системы и конечной точки для пользователей.
Служба координаторов: Служба координатора распределяет задачи между рабочими узлами.
Рабочие узлы: Рабочие узлы - это немые исполнители, которые следуют инструкциям службы координаторов и выполняют команды DML/DDL, инициированные пользователем.
Хранилище: Хранилище отвечает за сохранение данных. Оно включает в себя метахранилище, брокер журналов и хранилище объектов.
Варианты развертывания Milvus
Milvus поддерживает три режима работы: Milvus Lite, Standalone и Distributed.
Milvus Lite - это библиотека Python, которая может быть импортирована в локальные приложения. Как облегченная версия Milvus, она идеально подходит для быстрого создания прототипов в Jupyter Notebooks или для работы на смарт-устройствах с ограниченными ресурсами.
Milvus Standalone- это серверное развертывание на одной машине. Если у вас есть производственная рабочая нагрузка, но вы предпочитаете не использовать Kubernetes, запуск Milvus Standalone на одной машине с достаточным количеством памяти будет хорошим вариантом.
Milvus Distributed может быть развернут на кластерах Kubernetes. Он поддерживает большие массивы данных, более высокую доступность и масштабируемость и больше подходит для производственных сред.
Milvus с самого начала был разработан для поддержки Kubernetes и может быть легко развернут на AWS. Мы можем использовать Amazon Elastic Kubernetes Service (Amazon EKS) в качестве управляемого Kubernetes, Amazon S3 в качестве хранилища объектов, Amazon Managed Streaming for Apache Kafka (Amazon MSK) в качестве хранилища сообщений и Amazon Elastic Load Balancing (Amazon ELB) в качестве балансировщика нагрузки для создания надежного, эластичного кластера баз данных Milvus.
Далее мы дадим пошаговое руководство по развертыванию кластера Milvus с помощью EKS и других сервисов.
Развертывание Milvus на AWS EKS
Необходимые условия
Мы будем использовать AWS CLI для создания кластера EKS и развертывания базы данных Milvus. Для этого необходимы следующие предварительные условия:
ПК/Mac или экземпляр Amazon EC2 с установленным AWS CLI и настроенными соответствующими правами. Инструменты AWS CLI установлены по умолчанию, если вы используете Amazon Linux 2 или Amazon Linux 2023.
Установленные инструменты EKS, включая Helm, Kubectl, eksctl и т. д.
Ведро Amazon S3.
Экземпляр Amazon MSK.
Соображения при создании MSK
- Последняя стабильная версия Milvus (v2.3.13) зависит от функции Kafka
autoCreateTopics
. Поэтому при создании MSK нам необходимо использовать пользовательскую конфигурацию и изменить свойствоauto.create.topics.enable
со значения по умолчаниюfalse
наtrue
. Кроме того, для увеличения пропускной способности MSK рекомендуется увеличить значенияmessage.max.bytes
иreplica.fetch.max.bytes
. Подробности см. в разделе Пользовательские конфигурации MSK.
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
- Milvus не поддерживает аутентификацию MSK на основе ролей IAM. Поэтому при создании MSK включите опцию
SASL/SCRAM authentication
в конфигурации безопасности и настройтеusername
иpassword
в AWS Secrets Manager. Подробности смотрите в разделе Аутентификация учетных данных при входе в систему с помощью AWS Secrets Manager.
Рисунок 3 Настройки безопасности: включить аутентификацию SASL SCRAM.png
Рисунок 3: Настройки безопасности: включить аутентификацию SASL/SCRAM
- Нам нужно разрешить доступ к группе безопасности MSK из группы безопасности кластера EKS или диапазона IP-адресов.
Создание кластера EKS
Существует множество способов создания кластера EKS, например, через консоль, CloudFormation, eksctl и т. д. В этом посте мы покажем, как создать кластер EKS с помощью eksctl.
eksctl
это простой инструмент командной строки для создания и управления кластерами Kubernetes на Amazon EKS. Он обеспечивает самый быстрый и простой способ создания нового кластера с узлами для Amazon EKS. Дополнительную информацию см. на сайте eksctl.
- Сначала создайте файл
eks_cluster.yaml
с помощью следующего фрагмента кода. Заменитеcluster-name
на имя кластера, заменитеregion-code
на регион AWS, в котором вы хотите создать кластер, и заменитеprivate-subnet-idx
на частные подсети. Примечание: Этот файл конфигурации создает кластер EKS в существующем VPC, указывая частные подсети. Если вы хотите создать новый VPC, удалите конфигурацию VPC и подсетей, и тогдаeksctl
автоматически создаст новую.
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
- Затем выполните команду
eksctl
для создания кластера EKS.
eksctl create cluster -f eks_cluster.yaml
Эта команда создаст следующие ресурсы:
Кластер EKS с указанной версией.
Группа управляемых узлов с тремя экземплярами EC2 m6i.2xlarge.
Провайдер идентификации IAM OIDC и учетная запись ServiceAccount под названием
aws-load-balancer-controller
, которую мы будем использовать позже при установке контроллера балансировщика нагрузки AWS.Пространство имен
milvus
и ServiceAccountmilvus-s3-access-sa
в этом пространстве имен. Это пространство имен будет использоваться позже при настройке S3 в качестве хранилища объектов для Milvus.Примечание: Для простоты здесь
milvus-s3-access-sa
предоставлены полные права доступа к S3. В производственных развертываниях рекомендуется следовать принципу наименьших привилегий и предоставлять доступ только к конкретному ведру S3, используемому для Milvus.Несколько дополнений, где
vpc-cni
,coredns
,kube-proxy
- основные дополнения, необходимые EKS.aws-ebs-csi-driver
- драйвер AWS EBS CSI, который позволяет кластерам EKS управлять жизненным циклом томов Amazon EBS.
Теперь нам нужно дождаться завершения создания кластера.
Дождитесь завершения создания кластера. В процессе создания кластера файл kubeconfig
будет автоматически создан или обновлен. Вы также можете обновить его вручную, выполнив следующую команду. Обязательно замените region-code
на регион AWS, в котором создается кластер, и замените cluster-name
на имя кластера.
aws eks update-kubeconfig --region <region-code> --name <cluster-name>
После создания кластера вы можете просмотреть узлы, выполнив следующую команду:
kubectl get nodes -A -o wide
- Создайте
ebs-sc
StorageClass, настроенный на GP3 в качестве типа хранилища, и установите его в качестве StorageClass по умолчанию. Milvus использует etcd в качестве метахранилища и нуждается в этом StorageClass для создания и управления 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
Затем установите исходный gp2
StorageClass не по умолчанию:
kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
- Установите контроллер балансировщика нагрузки AWS. Мы будем использовать этот контроллер позже для Milvus Service и Attu Ingress, поэтому давайте установим его заранее.
- Сначала добавьте репо
eks-charts
и обновите его.
helm repo add eks https://aws.github.io/eks-charts
helm repo update
- Затем установите контроллер AWS Load Balancer Controller. Замените
cluster-name
на имя вашего кластера. Учетная запись ServiceAccount с именемaws-load-balancer-controller
уже была создана, когда мы создавали кластер EKS на предыдущих шагах.
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
- Проверьте, успешно ли установлен контроллер.
kubectl get deployment -n kube-system aws-load-balancer-controller
- Результат должен выглядеть следующим образом:
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 12m
Развертывание кластера Milvus
Milvus поддерживает несколько методов развертывания, таких как Operator и Helm. Operator проще, но Helm более прямой и гибкий. В этом примере мы будем использовать Helm для развертывания Milvus.
При развертывании Milvus с помощью Helm вы можете настроить конфигурацию с помощью файла values.yaml
. Щелкните values.yaml, чтобы просмотреть все параметры. По умолчанию Milvus создает внутрикластерные minio и pulsar в качестве хранилища объектов и хранилища сообщений, соответственно. Мы внесем некоторые изменения в конфигурацию, чтобы сделать ее более подходящей для производства.
- Сначала добавьте репо Milvus Helm и обновите его.
helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
- Создайте файл
milvus_cluster.yaml
со следующим фрагментом кода. Этот фрагмент кода настраивает конфигурацию Milvus, например, настраивает Amazon S3 в качестве хранилища объектов и Amazon MSK в качестве очереди сообщений. Подробные объяснения и рекомендации по настройке мы предоставим позже.
#####################################
# 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
Код содержит шесть секций. Следуйте следующим инструкциям, чтобы изменить соответствующие конфигурации.
Раздел 1: Настройка S3 в качестве хранилища объектов. ServiceAccount предоставляет Milvus доступ к S3 (в данном случае это milvus-s3-access-sa
, который был создан при создании кластера EKS). Обязательно замените <region-code>
на регион AWS, в котором расположен ваш кластер. Замените <bucket-name>
на имя вашего ведра S3, а <root-path>
- на префикс для ведра S3 (это поле можно оставить пустым).
Раздел 2: Настройка MSK в качестве хранилища сообщений. Замените <broker-list>
адресами конечных точек, соответствующих типу аутентификации SASL/SCRAM в MSK. Замените <username>
и <password>
на имя пользователя и пароль учетной записи MSK. Вы можете получить <broker-list>
из информации о клиенте MSK, как показано на рисунке ниже.
Рисунок 4 Настройка MSK в качестве хранилища сообщений Milvus.png
Рисунок 4: Настройка MSK в качестве хранилища сообщений Milvus
Раздел 3: Раскрываем службу Milvus и разрешаем доступ извне кластера. По умолчанию конечная точка Milvus использует сервис типа ClusterIP, который доступен только внутри кластера EKS. При необходимости вы можете изменить его на тип LoadBalancer, чтобы разрешить доступ извне кластера EKS. Служба типа LoadBalancer использует Amazon NLB в качестве балансировщика нагрузки. В соответствии с лучшими практиками безопасности, aws-load-balancer-scheme
по умолчанию настроен на внутренний режим, что означает, что доступ к Milvus разрешен только через внутреннюю сеть. Нажмите, чтобы просмотреть инструкции по настройке NLB.
Раздел 4: Установите и настройте Attu, инструмент администрирования milvus с открытым исходным кодом. Он имеет интуитивно понятный графический интерфейс, который позволяет легко взаимодействовать с Milvus. Мы включим Attu, настроим вход с помощью AWS ALB и установим тип internet-facing
, чтобы к Attu можно было получить доступ через Интернет. Щелкните этот документ, чтобы ознакомиться с руководством по настройке ALB.
Раздел 5: Включите HA-развертывание основных компонентов Milvus. Milvus содержит множество независимых и разрозненных компонентов. Например, служба координатора выступает в качестве уровня управления, обеспечивая координацию для компонентов Root, Query, Data и Index. Прокси-сервер на уровне доступа служит конечной точкой доступа к базе данных. По умолчанию для этих компонентов используется только 1 реплика стручка. Развертывание нескольких реплик этих компонентов службы особенно необходимо для повышения доступности Milvus.
Примечание: Для развертывания нескольких реплик компонентов координаторов Root, Query, Data и Index требуется включение опции activeStandby
.
Раздел 6: Настройте распределение ресурсов для компонентов Milvus в соответствии с требованиями рабочих нагрузок. На веб-сайте Milvus также имеется инструмент определения размеров для создания предложений по конфигурации на основе объема данных, размеров векторов, типов индексов и т. д. Он также может сгенерировать конфигурационный файл Helm одним щелчком мыши. Следующая конфигурация - это предложение, выданное инструментом для 1 миллиона векторов 1024 размеров и типа индекса HNSW.
- Используйте Helm для создания Milvus (развернутого в пространстве имен
milvus
). Примечание: Вы можете заменить<demo>
на собственное имя.
helm install <demo> milvus/milvus -n milvus -f milvus_cluster.yaml
- Выполните следующую команду, чтобы проверить состояние развертывания.
kubectl get deployment -n milvus
Следующий вывод показывает, что все компоненты Milvus находятся в состоянии AVAILABLE, а для компонентов координации включено несколько реплик.
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
Доступ к Milvus и управление им
Итак, мы успешно развернули базу данных векторов Milvus. Теперь мы можем получить доступ к Milvus через конечные точки. Milvus открывает конечные точки через сервисы Kubernetes. Attu открывает конечные точки через Kubernetes Ingress.
Доступ к конечным точкам Milvus
Выполните следующую команду, чтобы получить конечные точки сервисов:
kubectl get svc -n milvus
Вы можете просмотреть несколько сервисов. Milvus поддерживает два порта, порт 19530
и порт 9091
:
- Порт
19530
предназначен для gRPC и RESTful API. Это порт по умолчанию, когда вы подключаетесь к серверу Milvus с помощью различных Milvus SDK или HTTP-клиентов. - Порт
9091
- это порт управления для сбора метрик, профилирования pprof и зондов здоровья в Kubernetes.
Сервис demo-milvus
предоставляет конечную точку доступа к базе данных, которая используется для установления соединения с клиентами. В качестве балансировщика нагрузки сервиса используется NLB. Конечную точку службы можно получить из столбца 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
Управление Milvus с помощью Attu
Как было описано ранее, мы установили Attu для управления Milvus. Выполните следующую команду, чтобы получить конечную точку:
kubectl get ingress -n milvus
Вы увидите ингресс под названием demo-milvus-attu
, где столбец ADDRESS
- это URL-адрес доступа.
NAME CLASS HOSTS ADDRESS PORTS AGE
demo-milvus-attu <none> * k8s-attu-xxxx.us-west-2.elb.amazonaws.com 80 27s
Откройте адрес Ingress в браузере и увидите следующую страницу. Нажмите Connect, чтобы войти в систему.
Рисунок 5 Вход в учетную запись Attu.png
Рисунок 5: Вход в учетную запись Attu
После входа в систему вы сможете управлять базами данных Milvus через Attu.
Рисунок 6 Интерфейс Attu.png
Рисунок 6: Интерфейс Attu
Тестирование векторной базы данных Milvus
Мы будем использовать код примера Milvus, чтобы проверить, правильно ли работает база данных Milvus. Сначала загрузите код примера hello_milvus.py
с помощью следующей команды:
wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py
Измените host в коде примера на конечную точку сервиса Milvus.
print(fmt.format("start connecting to Milvus"))
connections.connect("default", host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com", port="19530")
Запустите код:
python3 hello_milvus.py
Если система вернет следующий результат, это означает, что Milvus работает нормально.
=== 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 ===
Заключение
В этой статье мы познакомились с Milvus, одной из самых популярных векторных баз данных с открытым исходным кодом, и привели руководство по развертыванию Milvus на AWS с помощью управляемых сервисов Amazon EKS, S3, MSK и ELB для достижения большей эластичности и надежности.
Являясь основным компонентом различных систем GenAI, в частности Retrieval Augmented Generation (RAG), Milvus поддерживает и интегрируется с различными основными моделями и фреймворками GenAI, включая Amazon Sagemaker, PyTorch, HuggingFace, LlamaIndex и LangChain. Начните свой путь к инновациям GenAI с Milvus уже сегодня!
Ссылки
- Обзор векторных вкраплений и векторных баз данных
- Что такое Milvus?
- Развертывание Milvus на AWS EKS
- Тестирование векторной базы данных Milvus
- Заключение
- Ссылки
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