Visión general de la arquitectura de Milvus
Milvus es una base de datos vectorial de código abierto, nativa de la nube, diseñada para la búsqueda de similitud de alto rendimiento en conjuntos de datos vectoriales masivos. Construida sobre librerías populares de búsqueda vectorial, incluyendo Faiss, HNSW, DiskANN y SCANN, potencia las aplicaciones de IA y los escenarios de recuperación de datos no estructurados. Antes de continuar, familiarícese con los principios básicos de la recuperación por incrustación.
Diagrama de arquitectura
El siguiente diagrama ilustra la arquitectura de alto nivel de Milvus, mostrando su diseño modular, escalable y nativo de la nube con capas de almacenamiento y computación totalmente desagregadas.
Diagrama_de_arquitectura
Principios arquitectónicos
Milvus sigue el principio de desagregación del plano de datos y el plano de control, y consta de cuatro capas principales que son independientes entre sí en términos de escalabilidad y recuperación ante desastres. Esta arquitectura de almacenamiento compartido con capas de almacenamiento y computación totalmente desagregadas permite el escalado horizontal de los nodos de computación al tiempo que implementa Woodpecker como capa WAL de disco cero para aumentar la elasticidad y reducir la sobrecarga operativa.
Al separar el procesamiento de flujos en Streaming Node y el procesamiento por lotes en Query Node y Data Node, Milvus consigue un alto rendimiento y satisface simultáneamente los requisitos de procesamiento en tiempo real.
Arquitectura detallada de capas
Capa 1: Capa de acceso
Compuesta por un grupo de proxies sin estado, la capa de acceso es la capa frontal del sistema y el punto final para los usuarios. Valida las solicitudes de los clientes y reduce los resultados devueltos:
- El proxy es en sí mismo apátrida. Proporciona una dirección de servicio unificada utilizando componentes de equilibrio de carga como Nginx, Kubernetes Ingress, NodePort y LVS.
- Como Milvus emplea una arquitectura de procesamiento paralelo masivo (MPP), el proxy agrega y post-procesa los resultados intermedios antes de devolver los resultados finales al cliente.
Capa 2: Coordinador
El Coordinador es el cerebro de Milvus. En cualquier momento, hay exactamente un Coordinador activo en todo el clúster, responsable de mantener la topología del clúster, programar todos los tipos de tareas y garantizar la coherencia a nivel de clúster.
Las siguientes son algunas de las tareas gestionadas por el Coordinador:
- Gestión de DDL/DCL/TSO: Gestiona las solicitudes del lenguaje de definición de datos (DDL) y del lenguaje de control de datos (DCL), como la creación o eliminación de colecciones, particiones o índices, así como la gestión de la marca de tiempo Oracle (TSO) y la emisión de marcas de tiempo.
- Gestión de servicios de streaming: Vincula el registro de escritura en cabeza (WAL) con los nodos de streaming y proporciona el descubrimiento de servicios para el servicio de streaming.
- Gestión de consultas: Gestiona la topología y el equilibrio de carga para los nodos de consulta, y proporciona y gestiona las vistas de consulta de servicio para guiar el enrutamiento de la consulta.
- Gestión de datos históricos: Distribuye tareas fuera de línea como la compactación y la creación de índices a los Nodos de Datos, y gestiona la topología de segmentos y vistas de datos.
Capa 3: Nodos de trabajo
Los brazos y las piernas. Los nodos de trabajo son ejecutores mudos que siguen las instrucciones del coordinador. Los nodos de trabajo son apátridas gracias a la separación del almacenamiento y la computación, y pueden facilitar la escalabilidad del sistema y la recuperación ante desastres cuando se despliegan en Kubernetes. Existen tres tipos de nodos trabajadores:
Nodo de streaming
Streaming Node actúa como "mini-cerebro" a nivel de shard, proporcionando garantías de consistencia a nivel de shard y recuperación de fallos basada en el almacenamiento WAL subyacente. Mientras tanto, Streaming Node también es responsable de la consulta de datos crecientes y de la generación de planes de consulta. Además, también se encarga de la conversión de los datos crecientes en datos sellados (históricos).
Nodo de consulta
El nodo de consulta carga los datos históricos desde el almacenamiento de objetos y proporciona la consulta de datos históricos.
Nodo de datos
El nodo de datos es responsable del procesamiento fuera de línea de los datos históricos, como la compactación y la creación de índices.
Capa 4: Almacenamiento
El almacenamiento es el núcleo del sistema, responsable de la persistencia de los datos. Comprende el metaalmacenamiento, el corredor de registros y el almacenamiento de objetos.
Metaalmacenamiento
El metaalmacenamiento almacena instantáneas de metadatos, como el esquema de recopilación y los puntos de control de consumo de mensajes. El almacenamiento de metadatos exige una disponibilidad extremadamente alta, una fuerte consistencia y soporte de transacciones, por lo que Milvus eligió etcd para el metaalmacenamiento. Milvus también utiliza etcd para el registro de servicios y la comprobación del estado.
Almacenamiento de objetos
El almacenamiento de objetos almacena archivos de instantáneas de registros, archivos de índices para datos escalares y vectoriales y resultados intermedios de consultas. Milvus utiliza MinIO como almacenamiento de objetos y puede desplegarse fácilmente en AWS S3 y Azure Blob, dos de los servicios de almacenamiento más populares y rentables del mundo. Sin embargo, el almacenamiento de objetos tiene una alta latencia de acceso y cobra por el número de consultas. Para mejorar su rendimiento y reducir los costes, Milvus planea implementar la separación de datos en frío y en caliente en una reserva de caché basada en memoria o SSD.
Almacenamiento WAL
El almacenamiento WAL (Write-Ahead Log) es la base de la durabilidad y coherencia de los datos en los sistemas distribuidos. Antes de confirmar cualquier cambio, se registra en un registro, lo que garantiza que, en caso de fallo, se pueda recuperar exactamente donde se dejó.
Entre las implementaciones habituales de WAL se encuentran Kafka, Pulsar y Woodpecker. A diferencia de las soluciones tradicionales basadas en disco, Woodpecker adopta un diseño de disco cero nativo de la nube que escribe directamente en el almacenamiento de objetos. Este enfoque se adapta sin esfuerzo a sus necesidades y simplifica las operaciones al eliminar la sobrecarga de la gestión de discos locales.
Al registrar todas las operaciones de escritura con antelación, la capa WAL garantiza un mecanismo fiable en todo el sistema para la recuperación y la coherencia, independientemente de la complejidad de su entorno distribuido.
Flujo de datos y categorías de API
Las API de Milvus se clasifican por su función y siguen rutas específicas a través de la arquitectura:
| Categoría de API | Operaciones | Ejemplo de API | Flujo de la arquitectura |
|---|---|---|---|
| DDL/DCL | Esquema y control de acceso | createCollection, dropCollection, hasCollection, createPartition | Capa de acceso → Coordinador |
| DML | Manipulación de Datos | insert, delete, upsert | Capa de acceso → Nodo de trabajo de streaming |
| DQL | Consulta de datos | search, query | Capa de acceso → Nodo de trabajo por lotes (nodos de consulta) |
Ejemplo de flujo de datos: operación de búsqueda
- El cliente envía una solicitud de búsqueda a través de SDK/RESTful API
- El equilibrador de carga enruta la solicitud al proxy disponible en la capa de acceso
- El proxy utiliza la caché de enrutamiento para determinar los nodos de destino; sólo se pone en contacto con el coordinador si la caché no está disponible.
- El proxy reenvía la solicitud a los nodos de transmisión adecuados, que a su vez se coordinan con los nodos de consulta para la búsqueda de datos sellados mientras ejecutan localmente la búsqueda de datos crecientes.
- Los nodos de consulta cargan los segmentos sellados desde el almacenamiento de objetos según sea necesario y realizan la búsqueda a nivel de segmento.
- Los resultados de la búsqueda se someten a una reducción multinivel: Los nodos de consulta reducen los resultados en varios segmentos, los nodos de transmisión reducen los resultados de los nodos de consulta y el proxy reduce los resultados de todos los nodos de transmisión antes de devolverlos al cliente.
Ejemplo de flujo de datos: inserción de datos
- El cliente envía una solicitud de inserción con datos vectoriales
- La capa de acceso valida y reenvía la solicitud al nodo de transmisión.
- El nodo de transmisión registra la operación en el almacenamiento WAL para garantizar su durabilidad.
- Los datos se procesan en tiempo real y están disponibles para consultas
- Cuando los segmentos alcanzan su capacidad, el nodo de transmisión activa la conversión a segmentos sellados.
- El nodo de datos se encarga de la compactación y crea índices sobre los segmentos sellados, almacenando los resultados en el almacenamiento de objetos.
- Los nodos de consulta cargan los índices recién creados y sustituyen los datos crecientes correspondientes.
Lo que sigue
- Explore los componentes principales para conocer los detalles de la implementación
- Conozca los flujos de trabajo de procesamiento de datos y las estrategias de optimización
- Comprender el Modelo de Consistencia y las garantías de transacción en Milvus