Migrando o Milvus autogerenciado para o Zilliz Cloud para uma redução de latência de >99%
Publicado originalmente em simonhearne.com e republicado com permissão.
Então você criou uma aplicação usando Milvus como banco de dados vetorial, usando Standalone ou Distributed. Você chegou a um ponto em que a aplicação está funcionando, clientes a estão usando e o volume de dados está crescendo. Em algum momento, gerenciar o banco de dados vetorial começa a consumir mais tempo, falhas de pods causam instabilidade no serviço, você está ficando sem RAM no servidor, ou o etcd se torna um gargalo doloroso.
Nesta etapa, você provavelmente está explorando um serviço gerenciado para remover a carga operacional. A boa notícia é que migrar do Milvus para o Zilliz Cloud é simples, e as várias opções estão bem documentadas.
No meu caso, eu havia criado uma aplicação RAG simples da Wikipedia: 50M embeddings usando o modelo multilíngue Embed v3 da Cohere com 1.024 dimensões (cobrindo todo o corpus em inglês da Wikipedia). Inicialmente, hospedei isso no meu laptop usando Milvus Standalone, mas o contêiner era instável, e reinicializações levavam ~20 minutos — nada ideal quando você quer mostrar uma demonstração!
O desempenho das consultas também estava sofrendo devido à paginação frequente (não tenho memória suficiente no meu laptop, então habilitei mmap). Abaixo está um vídeo rápido mostrando a aplicação em ação:
Tempos de consulta de três segundos não são ótimos, então, sem orçamento para um novo laptop, planejei minha migração para o Milvus gerenciado no Zilliz Cloud. A seguir está o processo passo a passo que segui — há vários métodos disponíveis, mas escolhi backup/restauração pela simplicidade.
1. Criar um backup
A Zilliz fornece o utilitário milvus-backup, e instalá-lo é tão fácil quanto brew install milvus-backup
Em seguida, você precisa criar um arquivo de configuração (o milvus-backup procura por backup.yaml no diretório de trabalho atual por padrão). Este é um exemplo mínimo para criar um backup a partir do Standalone rodando localmente em Docker (veja as opções yaml completas no GitHub):
milvus:
address: localhost
port: 19530
user: "root"
password: "Milvus"
tlsMode: 0
etcd:
endpoints: 127.0.0.1:2379
rootPath: "by-dev"
minio:
storageType: "local"
rootPath: "/../milvus_wikipedia/volumes/milvus/data"
backupStorageType: "local"
backupRootPath: "/../milvus-backup-test/backup"
Então execute uma verificação rápida:
$ milvus-backup check
Milvus version: 2.6.2
Storage:
milvus-storage-type: local
milvus-bucket: a-bucket
milvus-rootpath: /../milvus_wikipedia/volumes/milvus/data
backup-storage-type: local
backup-bucket: a-bucket
backup-rootpath: /../milvus-backup-test/backup
Success!
E, por fim, crie o backup (isso levará um pouco de tempo):
$ milvus-backup create -n wiki_backup
2. Criar a instância de destino no Zilliz Cloud
Primeiro, certifique-se de que você tem uma conta no Zilliz Cloud — depois crie uma instância que corresponda aos requisitos mínimos da sua implantação local. Para meus embeddings de 50M x 1.024-D no Tiered-Storage, a calculadora pública estimou que eu precisava de 2 Query CU:
Então naveguei até o console da nuvem, cliquei em "+ Cluster" e usei estas configurações:
Enquanto ela está sendo criada, você pode recuperar/gerar a chave de API de que precisaremos para a próxima etapa:
E anote o ID do cluster da nova instância:
3. Migrar para a Zilliz
Atualize seu backup.yaml para incluir a chave da nuvem que você acabou de gerar/recuperar:
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
Então, por fim, precisamos apenas executar um comando de migração, com o nome do backup e o ID do cluster de destino passados como argumentos:
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
No meu caso, levou algumas horas para fazer upload do arquivo de backup de ~120 GB para um Volume na Zilliz Cloud, depois cerca de uma hora para criar o cluster de destino a partir do Volume. Você pode monitorar o status da migração no console da Zilliz Cloud em Jobs:
Assim que a migração estiver concluída, certifique-se de carregar a coleção no cluster!
4. Validação
Agora você pode simplesmente atualizar a aplicação para usar o novo endpoint e as novas credenciais do cluster.
Observamos uma melhoria de desempenho em comparação com o Milvus Standalone — 25 ms em comparação com 3.112 ms — isso é uma redução de latência de mais de 99%!. Isso se deve em parte ao aumento da computação alocada no serviço em nuvem, bem como ao mecanismo de índice proprietário na Zilliz Cloud — Cardinal — que pode atingir consultas 10x mais rápidas em comparação com o Milvus OSS.
O ganho de desempenho é enorme, mas, melhor ainda, não preciso mais me preocupar com a parada do contêiner, e posso liberar ~20 GB de RAM no meu laptop!
5. Outras considerações
- Se a sua aplicação não funciona 24 horas por dia, 7 dias por semana, o seu banco de dados vetorial também não precisa funcionar. Suspenda clusters inativos para reduzir o custo de computação a zero quando não estiverem sendo usados.
- Tiered-Storage é um ótimo tipo de cluster para requisitos baixos (<10 QPS), mas há outras opções e você pode migrar dados entre elas:
- On-Demand — usa computação apenas quando há consultas em execução. Isso poderia reduzir o custo em 99%, dependendo da frequência das consultas, ao custo de maior latência de cold-start.
- Capacity-Optimized — oferece densidade de dados reduzida em comparação com Tiered-Storage, mas alcança throughput 10 vezes maior e consultas 2 a 5 vezes mais rápidas. Isso aumentaria o custo de computação do meu exemplo em cerca de 60%.
- Performance-Optimized — oferece throughput ainda maior (>1.000 QPS por réplica) e desempenho (10 a 100 vezes mais rápido) ao custo de uma densidade de dados ainda mais reduzida.
- O Zilliz Cloud oferece suporte à montagem de volumes externos do Google Cloud Storage, Amazon S3, Azure Blob Storage etc. Portanto, uma abordagem mais limpa seria enviar o backup diretamente para o armazenamento em nuvem e restaurá-lo de lá.
- Se criar/restaurar um backup não for possível por qualquer motivo, e a implantação do Milvus puder ser tornada acessível publicamente, você poderá usar o recurso Migrate from Milvus Endpoint no Zilliz Cloud.
- Tudo o que realizamos no Zilliz Cloud pode ser gerenciado via API e/ou Terraform se click-ops não for sua metodologia preferida.
Continue lendo
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
How to Improve Retrieval Quality for Japanese Text with Sudachi, Milvus/Zilliz, and AWS Bedrock
Learn how Sudachi normalization and Milvus/Zilliz hybrid search improve Japanese RAG accuracy with BM25 + vector fusion, AWS Bedrock embeddings, and practical code examples.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.