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.

Servicio de coordinación

El servicio coordinador asigna tareas a los nodos trabajadores y funciona como el cerebro del sistema. Entre las tareas que asume se incluyen la gestión de la topología del clúster, el equilibrio de la carga, la generación de marcas de tiempo, la declaración de datos y la gestión de datos.

Existen tres tipos de coordinadores: coordinador raíz (root coord), coordinador de datos (data coord) y coordinador de consultas (query coord).

Coordinador raíz (root coord)

El coordinador raíz gestiona las peticiones de lenguaje de definición de datos (DDL) y lenguaje de control de datos (DCL), como crear o eliminar colecciones, particiones o índices, así como gestionar la emisión de TSO (timestamp Oracle) y time ticker.

Coordinador de consultas (query coord)

El coordinador de consultas gestiona la topología y el equilibrio de carga de los nodos de consulta, así como el traspaso de segmentos en crecimiento a segmentos cerrados.

Coordinador de datos (data coord)

El coordinador de datos gestiona la topología de los nodos de datos y los nodos de índice, mantiene los metadatos y activa la descarga, compactación y creación de índices y otras operaciones de datos en segundo plano.

Nodos de trabajo

Los brazos y las piernas. Los nodos de trabajo son ejecutores mudos que siguen instrucciones del servicio de coordinación y ejecutan comandos de lenguaje de manipulación de datos (DML) desde el proxy. Los nodos de trabajo no tienen estado 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 consulta

El nodo de consulta recupera datos de registro incrementales y los convierte en segmentos crecientes suscribiéndose al corredor de registro, carga datos históricos del almacenamiento de objetos y ejecuta búsquedas híbridas entre datos vectoriales y escalares.

Nodo de datos

El nodo de datos recupera datos de registro incrementales suscribiéndose al agente de registros, procesa las solicitudes de mutación y empaqueta los datos de registro en instantáneas de registro y las almacena en el almacenamiento de objetos.

Nodo de índices

El nodo de índices crea índices. Los nodos de índice no necesitan ser residentes en memoria y pueden implementarse con el marco sin servidor.

Almacenamiento

El almacenamiento es el hueso del sistema, responsable de la persistencia de los datos. Comprende el metaalmacenamiento, el log broker 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.

Agente de registros

El log broker es un sistema pub-sub que soporta la reproducción. Es responsable de la persistencia de los datos de flujo y de la notificación de eventos. También garantiza la integridad de los datos incrementales cuando los nodos trabajadores se recuperan de una avería del sistema. Milvus cluster utiliza Pulsar como log broker; Milvus standalone utiliza RocksDB como log broker. Además, el log broker puede sustituirse fácilmente por plataformas de almacenamiento de datos en streaming como Kafka.

Milvus está construido en torno al corredor de registros y sigue el principio de "registro como datos", por lo que Milvus no mantiene una tabla física, sino que garantiza la fiabilidad de los datos mediante la persistencia del registro y los registros de instantáneas.

Mecanismo_de_registro

El log broker es la columna vertebral de Milvus. Es responsable de la persistencia de los datos y de la desagregación de lectura-escritura, gracias a su mecanismo innato pub-sub. La ilustración anterior muestra una representación simplificada del mecanismo, en la que el sistema se divide en dos funciones, el corredor de registros (para mantener la secuencia de registros) y el suscriptor de registros. El primero registra todas las operaciones que cambian los estados de las colecciones; el segundo se suscribe a la secuencia de registros para actualizar los datos locales y proporciona servicios en forma de copias de sólo lectura. El mecanismo pub-sub también permite ampliar el sistema en términos de captura de datos de cambios (CDC) y despliegue distribuido globalmente.

Más información

• Lea Componentes principales para obtener más detalles sobre la arquitectura de Milvus.