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
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.