Arquitecturas de referencia de Milvus
Este blog aborda algunas preguntas frecuentes sobre la asignación de recursos de Milvus en función de casos de uso específicos. Esas preguntas incluyen:
¿Cuántos recursos de CPU y memoria se necesitan para Milvus, según un número específico de usuarios o solicitudes por segundo (RPS)?
¿Cuántos recursos de CPU y memoria se necesitan para Milvus, según diferentes combinaciones de READ y WRITE?
Comprender las características de tu carga de trabajo
El primer paso para asignar recursos a Milvus es comprender las características de tu carga de trabajo. Estos factores desempeñan un papel crucial a la hora de determinar la potencia computacional y los requisitos de memoria de Milvus.
A continuación se muestra una lista de ejemplo de arquitecturas de referencia basadas en paquetes de Linux, donde RPS significa solicitudes por segundo:
Hasta 20 RPS o 1.000 usuarios API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
Hasta 40 RPS o 2.000 usuarios API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
Hasta 60 RPS o 3.000 usuarios API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
Hasta 100 RPS o 5.000 usuarios API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
Hasta 200 RPS o 10.000 usuarios API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
Hasta 500 RPS o 25.000 usuarios API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
Hasta 1000 RPS o 50.000 usuarios API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS
Estimar los requisitos de recursos
Para estimar los requisitos de recursos para Milvus, necesitamos hacer algunas suposiciones:
Lecturas: Cada solicitud web y Git pull es una operación READ.
Escrituras: Cada Git push se considera una operación WRITE.
Volumen y proporción de lecturas/escrituras: Se supone que Milvus es igual a la proporción de lectura/escritura de las llamadas de API por número de usuarios.
Consultas por segundo (QPS): debe coincidir con el requisito de RPS de API (solicitudes por segundo) por número de usuarios.
También necesitamos estimar el tamaño de los datos por solicitud de lectura/escritura. Supondremos un caso de uso común de GenAI:
Dimensión del vector: 1024 números de punto flotante
Tamaño en bytes por número de punto flotante: 4 KB
Top_k (número de vectores devueltos): 10 vectores por solicitud de búsqueda
Tamaño de una colección (tabla de base de datos): 1 millón de vectores por solicitud de escritura
Tipo de índice de base de datos: HNSW
Basándonos en estas suposiciones, podemos hacer un cálculo aproximado para estimar el tamaño de los datos por lectura o escritura. Supongamos que la dimensión del vector es 1024, y que cada vector ocupa 1024 * 4 bytes = 4 KB. Supongamos un top_k típico = 10 vectores por lectura. Con estas suposiciones:
Cada operación de lectura de Milvus procesa alrededor de 40 KB de datos.
Se estima que cada operación de escritura de Milvus implica 40 MB de datos.
Milvus ofrece funcionalidades tanto de insert (crear una colección completamente nueva) como de upsert (modificar unas pocas filas) (Consulta el blog Milvus insert, upsert, delete para obtener más información). Sobrestimaremos cada operación WRITE como una inserción de una colección completa en lugar de solo unos pocos upserts de filas.
Las bases de datos deben considerar no solo el tamaño de los datos, sino también la velocidad de búsqueda e inserción. Asumiremos que la colección está indexada usando el popular índice HNSW, que tiene notación Big-O, O(log n), en tiempo de búsqueda.
Con estas suposiciones, esta es nuestra conversión de usuarios/RPS/lecturas/escrituras basados en la Web a niveles de arquitectura de QPS/tamaño de datos de bases de datos vectoriales:
Hasta 1,000 usuarios = 20 QPS con 1 millón de vectores
Hasta 2,000 usuarios = 40 QPS con 1 millón de vectores
Hasta 3,000 usuarios = 60 QPS con 1 millón de vectores
Hasta 5,000 usuarios = 100 QPS con 2 millones de vectores
Hasta 10,000 usuarios = 200 QPS con 4 millones de vectores
Hasta 25,000 usuarios = 500 QPS con 10 millones de vectores
Hasta 50,000 usuarios = 1000 QPS con 20 millones de vectores
Pruebas de carga y evaluación comparativa
Para garantizar la precisión de nuestras estimaciones de recursos, realizamos pruebas de carga y evaluaciones comparativas de los niveles de arquitectura en VectorDBBench. Asumimos los tamaños predeterminados de Segment, Partition, Shard, Data node, Query node e Index node para la arquitectura de Milvus en sí.
¡Debido a las capacidades de autoescalado de Milvus, el rendimiento es lineal con el tamaño de los datos y los recursos del clúster! A continuación se muestra una tabla con los tamaños de recursos recomendados de Milvus y Zilliz Cloud (el Milvus completamente administrado) para diferentes capacidades de datos y requisitos de QPS.
La tabla siguiente muestra la capacidad de datos en millones de vectores de 1024_dimension. Los recursos de Milvus se indican en varias CPU y GB de memoria. Para la comparación de costos, mostramos los tamaños de recursos de Zilliz Cloud, indicados en Compute Units (cu), ya sea en tipos de rendimiento o de capacidad.
Tabla de tamaños de recursos recomendados de Milvus y Zilliz por niveles de usuarios/RPS
| Usuarios | Capacidad de datos | QPS evaluado | RPS requerido | Recurso de Milvus | Recurso de Zilliz |
| 3,000 | 1m_1024d vectores | 1200 | 60 | 8CPU, 32G | 1cu-perf |
| 3,000 | 1m_1024d vectores | 2400 | 60 | 16CPU, 64G | 2cu-perf |
| 3,000 | 1m_1024d vectores | 3600 | 60 | 24CPU, 96G | 4cu-perf |
| 10,000 | 3.7m_1024d vectores | 360 | 200 | 16CPU, 64G | 2cu-cap |
| 10,000 | 3.7m_1024d vectores | 700 | 200 | 64CPU, 256G | 4cu-cap |
| 25,000 | 10m_1024d vectores | 600 | 500 | 196CPU, 768G | 12cu- cap |
| 250,000 | 100m_1024d vectores | 6000 | 5000 | 19200CPU, 76800G | 1200cu- cap |
Tabla de tamaños de recursos recomendados de Milvus y Zilliz por número de niveles de usuarios/RPS. El escalado de Milvus es lineal con respecto al tamaño de los datos y los QPS requeridos.
De la tabla anterior, cuando el tamaño de los datos y los QPS necesitan alcanzar un cierto umbral, podría ser más rentable ejecutar Milvus desde Zilliz Cloud en lugar de en las instalaciones.
Conclusión
Al comprender las características de tu carga de trabajo, estimar los requisitos de recursos basados en suposiciones y aprovechar herramientas de pruebas de carga y evaluación comparativa como VectorDBBench, puedes aprovisionar con confianza los recursos necesarios para tu implementación de Milvus.
Consulta nuestra guía de dimensionamiento de clústeres para profundizar más. Recuerda que, a medida que evoluciona tu carga de trabajo, es esencial revisar y ajustar regularmente tu asignación de recursos para mantener el máximo rendimiento.
Referencias
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Arquitectura de Milvus: https://docs.gitlab.com/ee/administration/reference_architectures/
Blog Dependencias de empaquetado de Milvus: https://zilliz.com/blog/Milvus-server-docker-installation-and-packaging-dependencies
Blog Herramienta de dimensionamiento de Milvus: https://medium.com/@zilliz_learn/demystifying-the-milvus-sizing-tool-2c0afe7fe963
Shards, Particiones, Segmentos: https://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Tipos de CU de Zilliz Cloud: https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
Herramienta VectorDBBench para hacer benchmarks de Milvus, Zilliz Cloud y muchas otras bases de datos vectoriales principales
Sigue leyendo
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
How to Install and Run OpenClaw (Previously Clawdbot/Moltbot) on Mac
Turn your Mac into an AI gateway for WhatsApp, Telegram, Discord, iMessage, and more — in under 5 minutes.
Why Not All VectorDBs Are Agent-Ready
Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.