🚀 Experimente o Zilliz Cloud, o Milvus totalmente gerenciado, gratuitamente—experimente um desempenho 10x mais rápido! Experimente Agora>>

milvus-logo
LFAI
  • Home
  • Blog
  • Como implementar a base de dados vetorial Milvus de código aberto no Amazon EKS

Como implementar a base de dados vetorial Milvus de código aberto no Amazon EKS

  • Engineering
August 09, 2024
AWS

Este post foi originalmente publicado no site da AWS e é traduzido, editado e republicado aqui com permissão.

Uma visão geral dos embeddings vectoriais e das bases de dados vectoriais

A ascensão da IA generativa (GenAI), particularmente os modelos de linguagem grande(LLMs), aumentou significativamente o interesse em bancos de dados vetoriais, estabelecendo-os como um componente essencial dentro do ecossistema GenAI. Como resultado, as bases de dados vectoriais estão a ser adoptadas em cada vez mais casos de utilização.

Um relatório da IDC prevê que, até 2025, mais de 80% dos dados comerciais serão não estruturados, existindo em formatos como texto, imagens, áudio e vídeos. Compreender, processar, armazenar e consultar esta vasta quantidade de dados não estruturados à escala representa um desafio significativo. A prática comum na GenAI e na aprendizagem profunda consiste em transformar dados não estruturados em incorporações vectoriais, armazená-los e indexá-los numa base de dados vetorial como o Milvus ou o Zilliz Cloud (o Milvus totalmente gerido) para pesquisas de semelhança vetorial ou de semelhança semântica.

Mas o que são exatamente os vetor embeddings? Em termos simples, são representações numéricas de números de vírgula flutuante num espaço de elevada dimensão. A distância entre dois vectores indica a sua relevância: quanto mais próximos estiverem, mais relevantes são um para o outro, e vice-versa. Isto significa que vectores semelhantes correspondem a dados originais semelhantes, o que difere das pesquisas tradicionais por palavra-chave ou exactas.

How to perform a vector similarity search Como efetuar uma pesquisa de semelhança de vectores

Figura 1: Como efetuar uma pesquisa de semelhança de vectores

A capacidade de armazenar, indexar e pesquisar incorporações vectoriais é a principal funcionalidade das bases de dados vectoriais. Atualmente, as principais bases de dados vectoriais dividem-se em duas categorias. A primeira categoria estende os produtos de bases de dados relacionais existentes, como o Amazon OpenSearch Service com o plug-in KNN e o Amazon RDS para PostgreSQL com a extensão pgvector. A segunda categoria inclui produtos especializados de bases de dados vectoriais, incluindo exemplos bem conhecidos como o Milvus, o Zilliz Cloud (o Milvus totalmente gerido), o Pinecone, o Weaviate, o Qdrant e o Chroma.

As técnicas de incorporação e as bases de dados vectoriais têm amplas aplicações em vários casos de utilização orientados para a IA, incluindo pesquisa de semelhança de imagens, desduplicação e análise de vídeo, processamento de linguagem natural, sistemas de recomendação, publicidade direcionada, pesquisa personalizada, serviço de apoio ao cliente inteligente e deteção de fraudes.

O Milvus é uma das opções de código aberto mais populares entre os vários bancos de dados vetoriais. Esta postagem apresenta o Milvus e explora a prática de implantação do Milvus no AWS EKS.

O que é o Milvus?

O Milvus é um banco de dados vetorial de código aberto, nativo da nuvem, altamente flexível, confiável e extremamente rápido. Potencia a pesquisa de semelhanças vectoriais e as aplicações de IA e esforça-se por tornar as bases de dados vectoriais acessíveis a todas as organizações. O Milvus pode armazenar, indexar e gerenciar mais de um bilhão de embeddings vetoriais gerados por redes neurais profundas e outros modelos de aprendizado de máquina (ML).

O Milvus foi lançado sob a licença Apache 2.0 de código aberto em outubro de 2019. Atualmente, é um projeto de pós-graduação da LF AI & Data Foundation. No momento em que este blog foi escrito, o Milvus havia atingido mais de 50 milhões de downloads do Docker pull e era usado por muitos clientes, como NVIDIA, AT&T, IBM, eBay, Shopee e Walmart.

Principais recursos do Milvus

Como um banco de dados vetorial nativo da nuvem, o Milvus possui os seguintes recursos principais:

  • Alto desempenho e pesquisa em milissegundos em conjuntos de dados vetoriais em escala de bilhões.

  • Suporte multilíngue e conjunto de ferramentas.

  • Escalabilidade horizontal e elevada fiabilidade, mesmo em caso de interrupção.

  • Pesquisa híbrida, conseguida através do emparelhamento da filtragem escalar com a pesquisa de semelhanças vectoriais.

Arquitetura de Milvus

Milvus segue o princípio da separação entre o fluxo de dados e o fluxo de controlo. O sistema divide-se em quatro níveis, como mostra o diagrama:

Milvus Architecture Arquitetura de Milvus

Figura 2 Arquitetura Milvus

  • Camada de acesso: A camada de acesso é composta por um grupo de proxies sem estado e serve como camada frontal do sistema e ponto final para os utilizadores.

  • Serviço de coordenação: O serviço de coordenação atribui tarefas aos nós de trabalho.

  • Nós de trabalho: Os nós de trabalho são executores burros que seguem as instruções do serviço coordenador e executam comandos DML/DDL activados pelo utilizador.

  • Armazenamento: O armazenamento é responsável pela persistência dos dados. Inclui um meta-armazenamento, um corretor de registos e um armazenamento de objectos.

Opções de implantação do Milvus

O Milvus suporta três modos de execução: Milvus Lite, Standalone, e Distributed.

  • Milvus Lite é uma biblioteca Python que pode ser importada para aplicações locais. Como uma versão leve do Milvus, é ideal para prototipagem rápida em Jupyter Notebooks ou execução em dispositivos inteligentes com recursos limitados.

  • O Milvus Standalone éuma implantação de servidor de máquina única. Se tiver uma carga de trabalho de produção, mas preferir não usar Kubernetes, executar o Milvus Standalone numa única máquina com memória suficiente é uma boa opção.

  • Milvus Distributed pode ser implantado em clusters Kubernetes. Ele suporta conjuntos de dados maiores, maior disponibilidade e escalabilidade, e é mais adequado para ambientes de produção.

O Milvus foi projetado desde o início para oferecer suporte ao Kubernetes e pode ser facilmente implantado na AWS. Podemos usar o Amazon Elastic Kubernetes Service (Amazon EKS) como o Kubernetes gerido, o Amazon S3 como o armazenamento de objectos, o Amazon Managed Streaming for Apache Kafka (Amazon MSK) como o armazenamento de mensagens e o Amazon Elastic Load Balancing (Amazon ELB) como o Load Balancer para criar um cluster de base de dados Milvus fiável e elástico.

Em seguida, forneceremos orientações passo a passo sobre a implantação de um cluster do Milvus usando o EKS e outros serviços.

Implantação do Milvus no AWS EKS

Pré-requisitos

Usaremos o AWS CLI para criar um cluster do EKS e implantar um banco de dados do Milvus. Os seguintes pré-requisitos são necessários:

  • Um PC/Mac ou uma instância do Amazon EC2 com o AWS CLI instalado e configurado com as permissões apropriadas. As ferramentas da CLI do AWS são instaladas por padrão se você usar o Amazon Linux 2 ou o Amazon Linux 2023.

  • Ferramentas EKS instaladas, incluindo Helm, Kubectl, eksctl, etc.

  • Um bucket do Amazon S3.

  • Uma instância do Amazon MSK.

Considerações ao criar o MSK

  • A última versão estável do Milvus (v2.3.13) depende da funcionalidade autoCreateTopics do Kafka. Assim, ao criar o MSK, é necessário utilizar uma configuração personalizada e alterar a propriedade auto.create.topics.enable da predefinição false para true. Além disso, para aumentar o débito de mensagens do MSK, recomenda-se que os valores de message.max.bytes e replica.fetch.max.bytes sejam aumentados. Consulte Configurações personalizadas do MSK para obter detalhes.
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
  • O Milvus não é compatível com a autenticação baseada em função IAM do MSK. Portanto, ao criar o MSK, habilite a opção SASL/SCRAM authentication na configuração de segurança e configure username e password no AWS Secrets Manager. Consulte Autenticação de credenciais de entrada com o AWS Secrets Manager para obter detalhes.

Figure 3 Security settings enable SASL SCRAM authentication.png Figura 3 Configurações de segurança: habilitar a autenticação SASL SCRAM.png

Figura 3: Definições de segurança: ativar a autenticação SASL/SCRAM

  • Precisamos habilitar o acesso ao grupo de segurança MSK do grupo de segurança ou intervalo de endereços IP do cluster EKS.

Criando um cluster EKS

Há muitas maneiras de criar um cluster EKS, como através do console, CloudFormation, eksctl, etc. Este post mostrará como criar um cluster EKS usando eksctl.

eksctl é uma ferramenta simples de linha de comando para criar e gerenciar clusters Kubernetes no Amazon EKS. Ele fornece a maneira mais rápida e fácil de criar um novo cluster com nós para o Amazon EKS. Consulte o site do eksctl para obter mais informações.

  1. Primeiro, crie um arquivo eks_cluster.yaml com o seguinte trecho de código. Substitua cluster-name pelo nome do cluster, substitua region-code pela região da AWS onde deseja criar o cluster e substitua private-subnet-idx pelas sub-redes privadas. Observação: esse arquivo de configuração cria um cluster EKS em um VPC existente especificando sub-redes privadas. Se quiser criar uma nova VPC, remova a configuração de VPC e sub-redes e, em seguida, o eksctl criará automaticamente uma nova.
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
  1. Em seguida, execute o comando eksctl para criar o cluster EKS.
eksctl create cluster -f eks_cluster.yaml

Esse comando criará os seguintes recursos:

  • Um cluster EKS com a versão especificada.

  • Um grupo de nós gerenciados com três instâncias EC2 m6i.2xlarge.

  • Um provedor de identidade IAM OIDC e uma ServiceAccount chamada aws-load-balancer-controller, que usaremos posteriormente ao instalar o AWS Load Balancer Controller.

  • Um namespace milvus e uma ServiceAccount milvus-s3-access-sa dentro desse namespace. Este namespace será utilizado mais tarde quando configurarmos o S3 como o armazenamento de objectos para o Milvus.

    Nota: Para simplificar, o milvus-s3-access-sa aqui recebe permissões de acesso completo ao S3. Em implantações de produção, é recomendável seguir o princípio do menor privilégio e conceder acesso apenas ao bucket S3 específico usado para o Milvus.

  • Vários complementos, onde vpc-cni, coredns, kube-proxy são complementos principais exigidos pelo EKS. aws-ebs-csi-driver é o driver CSI do AWS EBS que permite que os clusters EKS gerenciem o ciclo de vida dos volumes do Amazon EBS.

Agora, só precisamos de esperar que a criação do cluster seja concluída.

Aguardar a conclusão da criação do cluster. Durante o processo de criação do cluster, o arquivo kubeconfig será criado ou atualizado automaticamente. Você também pode atualizá-lo manualmente executando o seguinte comando. Certifique-se de substituir region-code pela região do AWS onde o cluster está sendo criado e substitua cluster-name pelo nome do cluster.

aws eks update-kubeconfig --region <region-code> --name <cluster-name>

Depois que o cluster for criado, você poderá exibir os nós executando:

kubectl get nodes -A -o wide
  1. Crie um ebs-sc StorageClass configurado com GP3 como o tipo de armazenamento e defina-o como o StorageClass padrão. O Milvus usa o etcd como seu Meta Storage e precisa dessa StorageClass para criar e gerenciar PVCs.
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

De seguida, defina a StorageClass original de gp2 como não predefinida:

kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
  1. Instale o AWS Load Balancer Controller. Usaremos esse controlador mais tarde para o Serviço Milvus e o Attu Ingress, portanto, vamos instalá-lo com antecedência.
  • Primeiro, adicione o repositório eks-charts e atualize-o.
helm repo add eks https://aws.github.io/eks-charts
helm repo update
  • Em seguida, instale o AWS Load Balancer Controller. Substitua cluster-name pelo nome do seu cluster. A ServiceAccount chamada aws-load-balancer-controller já foi criada quando criamos o cluster EKS nas etapas anteriores.
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
  • Verifique se o controlador foi instalado com êxito.
kubectl get deployment -n kube-system aws-load-balancer-controller
  • A saída deve ser semelhante:
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-controller   2/2     2            2           12m

Implantação de um cluster Milvus

O Milvus suporta vários métodos de implantação, como o Operator e o Helm. O Operator é mais simples, mas o Helm é mais direto e flexível. Neste exemplo, usaremos o Helm para implantar o Milvus.

Ao implementar o Milvus com o Helm, pode personalizar a configuração através do ficheiro values.yaml. Clique em values.yaml para ver todas as opções. Por padrão, o Milvus cria o minio e o pulsar no cluster como o armazenamento de objetos e o armazenamento de mensagens, respetivamente. Faremos algumas alterações de configuração para torná-lo mais adequado para produção.

  1. Primeiro, adicione o repositório Milvus Helm e atualize-o.
helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
  1. Crie um arquivo milvus_cluster.yaml com o seguinte trecho de código. Este trecho de código personaliza a configuração do Milvus, como a configuração do Amazon S3 como o armazenamento de objetos e o Amazon MSK como a fila de mensagens. Forneceremos explicações detalhadas e orientações de configuração mais tarde.
#####################################
# 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

O código contém seis secções. Siga as instruções a seguir para alterar as configurações correspondentes.

Secção 1: Configurar o S3 como armazenamento de objectos. O serviceAccount concede ao Milvus acesso ao S3 (neste caso, é milvus-s3-access-sa, que foi criado quando criámos o cluster EKS). Certifique-se de que substitui <region-code> pela região AWS onde o seu cluster está localizado. Substitua <bucket-name> pelo nome do seu bucket S3 e <root-path> pelo prefixo do bucket S3 (este campo pode ser deixado vazio).

Secção 2: Configurar o MSK como armazenamento de mensagens. Substitua <broker-list> pelos endereços de ponto de extremidade correspondentes ao tipo de autenticação SASL/SCRAM do MSK. Substitua <username> e <password> pelo nome de utilizador e palavra-passe da conta MSK. Pode obter o endereço <broker-list> a partir das informações do cliente MSK, como mostra a imagem abaixo.

Figure 4 Configure MSK as the Message Storage of Milvus.png Figura 4: Configurar o MSK como armazenamento de mensagens do Milvus.png

Figura 4: Configurar o MSK como armazenamento de mensagens do Milvus

Secção 3: Expor o serviço Milvus e permitir o acesso a partir do exterior do cluster. O ponto de extremidade do Milvus usou o serviço do tipo ClusterIP por padrão, que só é acessível dentro do cluster EKS. Se necessário, é possível alterá-lo para o tipo LoadBalancer para permitir o acesso de fora do cluster EKS. O serviço do tipo LoadBalancer usa o Amazon NLB como balanceador de carga. De acordo com as práticas recomendadas de segurança, aws-load-balancer-scheme é configurado como modo interno por padrão aqui, o que significa que apenas o acesso à intranet para Milvus é permitido. Clique para ver as instruções de configuração do NLB.

Secção 4: Instale e configure o Attu, uma ferramenta de administração do Milvus de código aberto. Ela tem uma GUI intuitiva que permite interagir facilmente com o Milvus. Ativamos o Attu, configuramos o ingresso usando o AWS ALB e o definimos como internet-facing type para que o Attu possa ser acessado pela Internet. Clique neste documento para obter o guia de configuração do ALB.

Secção 5: Ativar a implementação HA dos componentes principais do Milvus. O Milvus contém vários componentes independentes e desacoplados. Por exemplo, o serviço coordenador actua como a camada de controlo, tratando da coordenação dos componentes Root, Query, Data e Index. O Proxy na camada de acesso serve como ponto final de acesso à base de dados. Estes componentes são predefinidos para apenas 1 réplica de pod. A implantação de várias réplicas desses componentes de serviço é especialmente necessária para melhorar a disponibilidade do Milvus.

Nota: a implantação de várias réplicas dos componentes do coordenador Root, Query, Data e Index requer a opção activeStandby ativada.

Secção 6: Ajustar a atribuição de recursos aos componentes do Milvus para satisfazer os requisitos das cargas de trabalho. O site do Milvus também fornece uma ferramenta de dimensionamento para gerar sugestões de configuração com base no volume de dados, dimensões dos vectores, tipos de índices, etc. Também pode gerar um ficheiro de configuração Helm com apenas um clique. A configuração seguinte é a sugestão dada pela ferramenta para 1 milhão de vectores de 1024 dimensões e tipo de índice HNSW.

  1. Utilize o Helm para criar o Milvus (implementado no espaço de nomes milvus). Nota: Pode substituir <demo> por um nome personalizado.
helm install <demo> milvus/milvus -n milvus -f milvus_cluster.yaml
  1. Execute o seguinte comando para verificar o status da implantação.
kubectl get deployment -n milvus

A saída a seguir mostra que os componentes do Milvus estão todos DISPONÍVEIS e que os componentes de coordenação têm várias réplicas ativadas.

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

Acessando e gerenciando o Milvus

Até agora, implantamos com sucesso o banco de dados de vetores do Milvus. Agora, podemos acessar o Milvus por meio de pontos de extremidade. Milvus expõe pontos finais através dos serviços Kubernetes. A Attu expõe pontos finais através do Kubernetes Ingress.

Aceder aos pontos finais do Milvus

Execute o seguinte comando para obter pontos finais de serviço:

kubectl get svc -n milvus

Pode ver vários serviços. O Milvus suporta duas portas, a porta 19530 e a porta 9091:

  • A porta 19530 destina-se ao gRPC e à API RESTful. É a porta predefinida quando se liga a um servidor Milvus com diferentes SDKs Milvus ou clientes HTTP.
  • A porta 9091 é uma porta de gerenciamento para coleta de métricas, perfil de pprof e sondas de integridade no Kubernetes.

O serviço demo-milvus fornece um ponto de extremidade de acesso à base de dados, que é utilizado para estabelecer uma ligação a partir de clientes. Ele usa o NLB como o balanceador de carga do serviço. Você pode obter o ponto de extremidade do serviço na coluna 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

Gerir o Milvus utilizando o Attu

Conforme descrito anteriormente, instalámos a Attu para gerir o Milvus. Execute o seguinte comando para obter o ponto de extremidade:

kubectl get ingress -n milvus

Pode ver um Ingress chamado demo-milvus-attu, em que a coluna ADDRESS é o URL de acesso.

NAME            CLASS   HOSTS   ADDRESS                                     PORTS   AGE
demo-milvus-attu   <none>   *       k8s-attu-xxxx.us-west-2.elb.amazonaws.com   80      27s

Abra o endereço do Ingress num browser e veja a seguinte página. Clique em Connect (Ligar ) para iniciar sessão.

Figure 5 Log in to your Attu account.png Figura 5: Iniciar sessão na sua conta Attu.png

Figura 5: Iniciar sessão na sua conta Attu

Depois de iniciar a sessão, pode gerir as bases de dados do Milvus através do Attu.

Figure 6 The Attu interface.png Figura 6 A interface da Attu.png

Figura 6: A interface da Attu

Testar a base de dados de vectores do Milvus

Vamos utilizar o código de exemplo do Milvus para testar se a base de dados do Milvus está a funcionar corretamente. Em primeiro lugar, descarregue o código de exemplo hello_milvus.py utilizando o seguinte comando:

wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py

Modifique o anfitrião no código de exemplo para o ponto de extremidade do serviço Milvus.

print(fmt.format("start connecting to Milvus"))
connections.connect("default", host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com", port="19530")

Execute o código:

python3 hello_milvus.py

Se o sistema devolver o seguinte resultado, isso indica que o Milvus está a funcionar normalmente.

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

Conclusão

Este post apresenta o Milvus, um dos bancos de dados vetoriais de código aberto mais populares, e fornece um guia sobre a implantação do Milvus na AWS usando serviços gerenciados como Amazon EKS, S3, MSK e ELB para obter maior elasticidade e confiabilidade.

Como um componente central de vários sistemas GenAI, particularmente Retrieval Augmented Generation (RAG), o Milvus suporta e integra-se com uma variedade de modelos e estruturas GenAI mainstream, incluindo Amazon Sagemaker, PyTorch, HuggingFace, LlamaIndex e LangChain. Comece sua jornada de inovação GenAI com Milvus hoje mesmo!

Referências

Like the article? Spread the word

Continue Lendo