Migración de Milvus autogestionado a Zilliz Cloud para una reducción de latencia de >99%
Publicado originalmente en simonhearne.com y republicado con permiso.
Así que has creado una aplicación usando Milvus como base de datos vectorial, utilizando Standalone o Distributed. Has llegado a un punto en el que la aplicación funciona, los clientes la están usando y el volumen de datos está creciendo. En algún momento, gestionar la base de datos vectorial empieza a consumir más tiempo, los fallos de pods causan inestabilidad en el servicio, te estás quedando sin RAM en el servidor, o etcd se convierte en un cuello de botella doloroso.
En esta etapa, probablemente estés explorando un servicio gestionado para quitarte la carga operativa. La buena noticia es que migrar de Milvus a Zilliz Cloud es sencillo, y las diversas opciones están bien documentadas.
En mi caso, había creado una aplicación RAG simple de Wikipedia: 50M de embeddings usando el modelo multilingüe Embed v3 de Cohere con 1.024 dimensiones (cubriendo todo el corpus en inglés de Wikipedia). Inicialmente, alojé esto en mi portátil usando Milvus Standalone, pero el contenedor era inestable, y los reinicios tardaban ~20 minutos — ¡no es ideal cuando quieres mostrar una demo!
El rendimiento de las consultas también se estaba viendo afectado por la paginación frecuente (no tengo suficiente memoria en mi portátil, así que habilité mmap). A continuación hay un breve vídeo que muestra la aplicación en acción:
Los tiempos de consulta de tres segundos no son excelentes, así que, sin presupuesto para un nuevo portátil, planifiqué mi migración a Milvus gestionado en Zilliz Cloud. El siguiente es el proceso paso a paso que seguí — hay varios métodos disponibles, pero elegí copia de seguridad/restauración por simplicidad.
1. Crea una copia de seguridad
Zilliz proporciona la utilidad milvus-backup, e instalarla es tan fácil como brew install milvus-backup
Luego necesitas crear un archivo de configuración (milvus-backup busca backup.yaml en el directorio de trabajo actual de forma predeterminada). Este es un ejemplo mínimo para crear una copia de seguridad desde Standalone ejecutándose en Docker localmente (consulta las opciones yaml completas en 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"
Luego ejecuta una comprobación 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!
Y finalmente, crea la copia de seguridad (esto tardará un poco):
$ milvus-backup create -n wiki_backup
2. Crea la instancia de destino en Zilliz Cloud
Primero, asegúrate de tener una cuenta de Zilliz Cloud — luego crea una instancia que coincida con los requisitos mínimos de tu despliegue local. Para mis embeddings de 50M x 1.024-D en Tiered-Storage, la calculadora pública estimó que necesitaba 2 Query CU:
Así que navegué a la consola en la nube, hice clic en "+ Cluster" y usé estos ajustes:
Mientras se está creando, puedes recuperar/generar la clave de API que necesitaremos para el siguiente paso:
Y toma nota del ID del clúster de la nueva instancia:
3. Migrar a Zilliz
Actualiza tu backup.yaml para incluir la clave de la nube que acabas de generar/recuperar:
cloud:
address: https://api.cloud.zilliz.com
apikey: <your-api-key>
Luego, finalmente, solo tenemos que ejecutar un comando de migración, con el nombre de la copia de seguridad y el ID del clúster de destino pasados como argumentos:
$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>
En mi caso, tardó unas horas en subir el archivo de copia de seguridad de ~120 GB a un Volumen en Zilliz Cloud, y luego aproximadamente una hora en crear el clúster de destino desde el Volumen. Puedes supervisar el estado de la migración en la consola de Zilliz Cloud en Jobs:
Una vez que se complete la migración, ¡asegúrate de cargar la colección en el clúster!
4. Validación
Ahora simplemente puedes actualizar la aplicación para usar el nuevo endpoint del clúster y las credenciales.
Observamos una mejora de rendimiento en comparación con Milvus Standalone — 25 ms frente a 3.112 ms — ¡eso supone una reducción de latencia de más del 99 %!. Esto se debe en parte al aumento de cómputo asignado en el servicio en la nube, así como al motor de índices propietario de Zilliz Cloud — Cardinal — que puede lograr consultas 10 veces más rápidas en comparación con Milvus OSS.
La mejora de rendimiento es enorme, pero, aún mejor, ¡ya no tengo que preocuparme de que el contenedor se detenga, y puedo liberar ~20 GB de RAM en mi portátil!
5. Otras consideraciones
- Si tu aplicación no se ejecuta 24x7, tu base de datos vectorial tampoco necesita hacerlo. Suspende los clústeres inactivos para reducir el costo de cómputo a cero cuando no se esté utilizando.
- Tiered-Storage es un excelente tipo de clúster para requisitos bajos (<10 QPS), pero hay otras opciones y puedes migrar datos entre ellas:
- On-Demand — solo usa cómputo cuando hay consultas en ejecución. Esto podría reducir el costo en un 99%, dependiendo de la frecuencia de las consultas, a costa de una mayor latencia de arranque en frío.
- Capacity-Optimized — proporciona una densidad de datos reducida en comparación con Tiered-Storage, pero logra un rendimiento 10 veces mayor y consultas de 2 a 5 veces más rápidas. Esto aumentaría el costo de cómputo de mi ejemplo en aproximadamente un 60%.
- Performance-Optimized — proporciona un rendimiento aún mayor (>1,000 QPS por réplica) y desempeño (10-100 veces más rápido) a costa de una densidad de datos aún más reducida.
- Zilliz Cloud admite montar volúmenes externos desde Google Cloud Storage, Amazon S3, Azure Blob Storage, etc. Así que un enfoque más limpio sería subir la copia de seguridad directamente al almacenamiento en la nube y restaurarla desde allí.
- Si crear/restaurar una copia de seguridad no es posible por cualquier motivo, y la implementación de Milvus puede hacerse accesible públicamente, puedes usar la función Migrate from Milvus Endpoint en Zilliz Cloud.
- Todo lo que realizamos en Zilliz Cloud puede gestionarse mediante API y/o Terraform si click-ops no es tu metodología preferida.
Sigue leyendo
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Zilliz Named "Highest Performer" and "Easiest to Use" in G2's Summer 2025 Grid® Report for Vector Databases
Zilliz shines in G2's Summer 2025 Grid® Report as both "Highest Performer" and "Easiest to Use," solving the performance-usability dilemma.
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.