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 nodos de trabajo son ejecutores "tontos" 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

Los nodos de consulta recuperan datos de registro incrementales y los convierten en segmentos crecientes suscribiéndose al corredor de registros, cargan datos históricos del almacenamiento de objetos y ejecutan búsquedas híbridas entre datos vectoriales y escalares.

Nodo de datos

Los nodos de datos recuperan datos de registro incrementales suscribiéndose al agente de registros, procesan solicitudes de mutación y empaquetan los datos de registro en instantáneas de registro y las almacenan en el almacenamiento de objetos.

Nodo índice

Los nodos de índice crean índices. 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 este propósito. Milvus también utiliza etcd para el registro de servicios y las comprobaciones de 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 costes, Milvus planea implementar la separación de datos en frío y en caliente en un grupo de caché basado 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 Distributed utiliza Pulsar como corredor de registro mientras que Milvus Standalone utiliza RocksDB. El log broker puede sustituirse fácilmente por plataformas de almacenamiento de datos en streaming como Kafka.

Milvus 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.