Una descripción general del sistema de almacenamiento de Milvus y técnicas para evaluar y optimizar su rendimiento
Bienvenido a nuestra exploración de Milvus, la base de datos vectorial de código abierto conocida por su impresionante escalabilidad horizontal y su rendimiento ultrarrápido. En el núcleo de Milvus se encuentra su robusto sistema de almacenamiento, una base fundamental para la persistencia y el almacenamiento fiables de datos. Este sistema comprende varios componentes esenciales: almacenamiento de metadatos, intermediario de registros y almacenamiento de objetos.
Esta guía profundizará en la arquitectura de Milvus, desglosará sus componentes clave de almacenamiento y explorará técnicas efectivas para evaluar su rendimiento.
Una visión general de la arquitectura de Milvus
Milvus adopta una arquitectura distribuida que garantiza la separación entre almacenamiento y cómputo y admite escalabilidad horizontal para sus nodos de cómputo. Esta configuración se organiza en cuatro capas clave: la capa de acceso, el servicio coordinador, los nodos de trabajo y el almacenamiento, cada una escalable de forma independiente y optimizada para la recuperación ante desastres.
Milvus Architecture Overview.png
Capa de acceso: Esta capa de front-end consta de proxies sin estado que gestionan las solicitudes de los usuarios y optimizan las respuestas, sirviendo como la interfaz de usuario principal del sistema.
Capa de coordinación: Actuando como el comando central del sistema, el servicio coordinador gestiona la distribución de tareas, la topología del clúster, el balanceo de carga y la gestión de datos entre los nodos de trabajo.
Nodos de trabajo: Estos son los ejecutores que procesan comandos del Lenguaje de Manipulación de Datos (DML) bajo la dirección del servicio coordinador.
Almacenamiento: Fundamental para la persistencia de datos, esta capa incluye almacenamiento de metadatos, un intermediario de registros y almacenamiento de objetos, garantizando la integridad y disponibilidad de los datos.
Componentes de almacenamiento de Milvus
Milvus utiliza tres componentes principales de almacenamiento para garantizar la integridad y disponibilidad de los datos: almacenamiento de metadatos, almacenamiento de objetos y un intermediario de registros.
Almacenamiento de metadatos
El almacenamiento de metadatos en Milvus almacena instantáneas de metadatos, como esquemas de colecciones, estados de nodos y puntos de control de consumo de mensajes. Dada la necesidad de alta disponibilidad, consistencia sólida y soporte para transacciones, Milvus utiliza etcd como su solución de almacenamiento de metadatos. Etcd es un almacén clave-valor robusto y distribuido que es crucial para los sistemas distribuidos dentro de Milvus. Gestiona tareas como el registro de servicios y las comprobaciones de estado, además de la preservación de metadatos.
Almacenamiento de objetos
El almacenamiento de objetos en Milvus gestiona el almacenamiento de archivos de instantáneas de registros, archivos de índices para datos escalares y vectoriales, y resultados intermedios de consultas. Milvus integra MinIO para el almacenamiento de objetos debido a su alto rendimiento y compatibilidad con Kubernetes, facilitando una operación fluida dentro de entornos en la nube como AWS S3 y Azure Blob Storage.
Intermediario de registros
El intermediario de registros en Milvus adopta un sistema de publicación-suscripción con capacidades de reproducción. Es esencial para la persistencia de datos en streaming, la ejecución de consultas asíncronas fiables, las notificaciones de eventos y la devolución de resultados de consultas. También garantiza la integridad de los datos incrementales durante la recuperación de nodos de trabajo tras fallos del sistema. Según la implementación, Milvus utiliza diferentes herramientas de intermediario de registros. Las configuraciones de Milvus Cluster utilizan Pulsar o Kafka, mientras que las versiones independientes de Milvus suelen usar RocksDB.
Cómo evaluar y optimizar el rendimiento del almacenamiento de Milvus
Evaluar y mejorar constantemente el rendimiento del almacenamiento es crucial.
Etcd: el almacén de metadatos de Milvus
Etcd es un almacén clave-valor robusto y distribuido diseñado para sistemas distribuidos. En Milvus, etcd es un almacén de metadatos que almacena datos esenciales como esquemas de colecciones, estados de nodos y puntos de control de consumo de mensajes.
La latencia de escritura en disco es crítica para el rendimiento de etcd; una velocidad de disco lenta puede aumentar significativamente la latencia de las solicitudes y poner en riesgo la estabilidad del sistema. Recomendamos mantener al menos 500 IOPS secuenciales (operaciones de entrada/salida por segundo) para un rendimiento óptimo en entornos de producción, asegurando que el 99% de las duraciones de fdatasync permanezcan por debajo de diez milisegundos. Aunque etcd normalmente requiere solo un ancho de banda de disco moderado, aumentar este ancho de banda puede reducir notablemente los tiempos de recuperación. En consecuencia, recomendamos un ancho de banda de disco base de al menos 100MB/s para entornos de producción.
Para verificar si su solución de almacenamiento cumple con estos criterios, considere realizar evaluaciones de rendimiento usando Fio, una herramienta de evaluación comparativa de discos. A continuación se muestra una guía sobre cómo usar Fio para evaluar el rendimiento de su almacenamiento.
Primero, asegúrese de que Fio esté instalado en su sistema. Luego, ejecute el siguiente comando, especificando el directorio donde está montado su almacenamiento como el directorio test-data. Este directorio debe estar bajo el punto de conexión de su almacenamiento.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Inspeccione los resultados para asegurarse de que el 99% de la duración de fdatasync sea inferior a 10ms y que los IOPS de escritura sean superiores a 500. Si se cumplen estas condiciones, su almacenamiento tiene un rendimiento adecuado.
A continuación se muestra un ejemplo de los resultados de salida:
Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022
write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
clat percentiles (usec):
| 1.00th=[ 3], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 5],
| 30.00th=[ 6], 40.00th=[ 9], 50.00th=[ 233], 60.00th=[ 343],
| 70.00th=[ 437], 80.00th=[ 553], 90.00th=[ 701], 95.00th=[ 742],
| 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],
| 99.99th=[15533]
bw ( KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207
iops : min= 726, max= 1106, avg=968.37, stdev=86.19, samples=207
lat (usec) : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%
lat (usec) : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%
lat (msec) : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%
fsync/fdatasync/sync_file_range:
sync (usec): min=309, max=21848, avg=741.93, stdev=489.64
sync percentiles (usec):
| 1.00th=[ 392], 5.00th=[ 437], 10.00th=[ 474], 20.00th=[ 529],
| 30.00th=[ 578], 40.00th=[ 619], 50.00th=[ 660], 60.00th=[ 709],
| 70.00th=[ 742], 80.00th=[ 791], 90.00th=[ 988], 95.00th=[ 1369],
| 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],
| 99.99th=[11994]
Al desplegar un clúster de Milvus en entornos en la nube, seleccionar el tipo adecuado de almacenamiento en bloque para etcd es crucial debido a su sensibilidad al rendimiento del disco. Los proveedores de nube ofrecen varias opciones de almacenamiento en bloque, cada una con características de rendimiento distintas adecuadas para diferentes cargas de trabajo.
A continuación se muestran los tipos de volumen y las métricas de rendimiento recomendados de varios proveedores de nube.
| Proveedor de nube | Tipo de volumen | TAMAÑO | IOPS | sincronización P99 |
| AWS | gp3 | 20Gi | 660 | 4.3ms |
| GCP | pd-ssd | 20Gi | 1262 | 1.3ms |
| Azure | PremiumV2 | 20Gi | 705 | 2.6ms |
| Aliyun | cloud_essd | 20Gi | 1137 | 3.5ms |
También puedes usar Fio para confirmar que el almacenamiento en bloques elegido cumple con los benchmarks de rendimiento necesarios para el funcionamiento óptimo de etcd dentro de tu despliegue de Milvus.
MinIO: herramienta de almacenamiento de objetos de Milvus
MinIO es una solución de almacenamiento de objetos de alto rendimiento y nativa de Kubernetes, optimizada para cargas de trabajo nativas de la nube. Milvus utiliza MinIO para almacenar archivos de instantáneas de logs, archivos de índice tanto para datos escalares como vectoriales, y resultados intermedios de consultas.
El rendimiento del almacenamiento de objetos como MinIO se mide principalmente por el throughput de E/S en lugar de IOPS. Esta métrica afecta significativamente a varias operaciones en Milvus, como cargar colecciones, crear índices e insertar datos. Muchos factores influyen en el rendimiento de throughput de MinIO, incluidos el ancho de banda de red, el ajuste de rendimiento del kernel de Linux y el rendimiento de las unidades de disco individuales. El rendimiento del disco es particularmente crucial.
Podemos usar el comando dd para medir el rendimiento de una sola unidad. DD es una herramienta de Unix que copia datos de un archivo a otro bit a bit. Proporciona varias opciones para controlar el tamaño de bloque de cada lectura y escritura.
En el ejemplo siguiente, al probar una sola unidad NVMe con un tamaño de bloque de 16MB, la opción O_DIRECT para 64 recuentos genera un rendimiento de escritura superior a 2GB por segundo por unidad.
$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s
En el mismo ejemplo, al probar una sola unidad NVMe con un tamaño de bloque de 16MB, la opción O_DIRECT para 64 recuentos genera un rendimiento de lectura superior a 5GB por segundo por unidad.
$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s
Cuanto mayor sea el rendimiento de lectura y escritura de tu unidad de disco, mejor será el rendimiento general de throughput de MinIO. Recomendamos usar unidades de tipo SSD o NVMe como discos de almacenamiento en una configuración de MinIO para obtener resultados óptimos. Estas unidades pueden admitir eficazmente los requisitos de alto throughput de las operaciones de MinIO. Evita usar dispositivos SAN/NAS para el almacenamiento de MinIO. Estas configuraciones suelen introducir problemas de concurrencia y cuellos de botella de rendimiento que pueden degradar la eficiencia y la capacidad de respuesta del sistema.
Pulsar/Kafka: herramientas de intermediación de logs de Milvus
Como se mencionó anteriormente, Milvus utiliza diferentes herramientas de intermediación de logs adaptadas a modos de despliegue específicos. Las configuraciones de Milvus Cluster usan Pulsar o Kafka, mientras que las versiones independientes de Milvus suelen usar RocksDB.
Tanto Pulsar como Kafka están diseñados para admitir almacenamiento persistente de mensajes y proporcionar alto throughput para los consumidores de mensajes. Su rendimiento depende de manera crítica del tipo de almacenamiento en disco utilizado, ya que se basan en operaciones secuenciales de E/S de disco.
Para Pulsar, los discos de alto rendimiento son esenciales para los archivos journal de BookKeeper a fin de garantizar la integridad y durabilidad de los datos, siendo los SSD de baja latencia muy beneficiosos para este propósito. Tanto Pulsar Ledgers como Kafka están optimizados para la eficiencia del disco, utilizando la caché del sistema de archivos y funcionando bien con HDDs y SSDs. Sin embargo, para aplicaciones sensibles a la latencia o despliegues a gran escala, los SSD ofrecen beneficios de rendimiento significativos.
Para optimizar el rendimiento, usa varios dispositivos de disco para Pulsar y Kafka. Específicamente, para Pulsar, usar discos separados para el journal y el almacenamiento general permite a los bookies aislar la latencia de las operaciones de escritura de las operaciones de lectura. Para garantizar una latencia óptima, no uses las mismas unidades para almacenar datos, logs de aplicaciones u otras actividades del sistema de archivos del SO. Estas unidades pueden configurarse como un único volumen mediante RAID, o cada unidad puede formatearse y montarse como su propio directorio. Debe evitarse el almacenamiento conectado a la red (NAS) debido a su rendimiento más lento, latencias más altas y más variables, y su potencial como punto único de fallo.
Resumen
Nuestra exploración en profundidad del sistema de almacenamiento Milvus ofrece información completa sobre su arquitectura y componentes, destacando sus funciones en el apoyo a la gestión y el análisis de datos a gran escala. Hemos analizado los tres componentes principales de almacenamiento de Milvus: almacenamiento de metadatos, almacenamiento de objetos y log broker, y proporcionado estrategias para evaluar y mejorar su rendimiento.
Fendy FengFendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
Jay ZhuJay Zhu is the Senior Software Engineer and tech leader of the DevOps & Infrastructure team at Zilliz. He specializes in DevOps, cloud-native technologies, and Kubernetes projects. Additionally, Jay is actively involved in developing and maintaining various open-source projects, including Milvus, Milvus-helm, and Milvus-operator.
Sigue leyendo
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.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.