Desagregación de almacenamiento/informática
Siguiendo el principio de desagregación del plano de datos y el plano de control, Milvus comprende cuatro capas que son independientes entre sí en términos de escalabilidad y recuperación ante desastres.
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.
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 las 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 los segmentos y las vistas de datos.
Nodos de trabajo
Los brazos y las piernas. Los nodos trabajadores 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 de trabajo:
Nodo de streaming
El nodo de streaming actúa como "minicerebro" a nivel de shard, proporcionando garantías de coherencia a nivel de shard y recuperación de fallos basada en el almacenamiento WAL subyacente. Mientras tanto, el nodo de streaming 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.
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.
Más información
- Lea Componentes principales para obtener más detalles sobre la arquitectura Milvus.