Servicio de streaming
El Servicio de Streaming es un concepto para el módulo del sistema de streaming interno de Milvus, construido alrededor del Registro de Escritura en Cabecera (WAL) para soportar varias funciones relacionadas con el streaming. Entre ellas se incluyen la ingesta/suscripción de datos de streaming, la recuperación ante fallos del estado del clúster, la conversión de datos de streaming en datos históricos y las consultas de datos crecientes. Desde el punto de vista arquitectónico, el servicio de streaming consta de tres componentes principales:
Arco distribuido de streaming
Coordinador de Streaming: Un componente lógico en el nodo coordinador. Utiliza Etcd para el descubrimiento de servicios con el fin de localizar los nodos de streaming disponibles y se encarga de vincular la WAL a los nodos de streaming correspondientes. También registra el servicio para exponer la topología de distribución de WAL, permitiendo a los clientes de streaming conocer el nodo de streaming apropiado para un WAL dado.
Clúster de nodos de streaming: Un clúster de nodos de trabajo de streaming responsable de todas las tareas de procesamiento de streaming, como la anexión de wal, la recuperación de estado, la consulta de datos en crecimiento.
Cliente de streaming: Un cliente Milvus desarrollado internamente que encapsula funcionalidades básicas como el descubrimiento de servicios y las comprobaciones de disponibilidad. Se utiliza para iniciar operaciones como la escritura de mensajes y la suscripción.
Mensaje
El servicio de streaming es un sistema de streaming basado en registros, por lo que todas las operaciones de escritura en Milvus (como DML y DDL) se abstraen como mensajes.
A cada Mensaje se le asigna un campo Timestamp Oracle (TSO) por el Servicio de Streaming, que indica el orden del mensaje en la WAL. El orden de los mensajes determina el orden de las operaciones de escritura en Milvus. Esto permite reconstruir el último estado del cluster a partir de los logs.
Cada Mensaje pertenece a un VChannel (Canal Virtual) específico y mantiene ciertas propiedades invariantes dentro de ese canal para asegurar la consistencia de las operaciones. Por ejemplo, una operación Insert debe producirse siempre antes de una operación DropCollection en el mismo canal.
El orden de los mensajes en Milvus puede parecerse al siguiente:
Orden de mensajes
Componente WAL
Para soportar la escalabilidad horizontal a gran escala, el WAL de Milvus no es un único archivo de registro, sino un compuesto de múltiples registros. Cada registro puede soportar independientemente la funcionalidad de streaming para múltiples VChannels. En un momento dado, un componente WAL puede operar exactamente en un nodo de streaming, esta restricción es prometida tanto por un mecanismo de cercado del almacenamiento wal subyacente como por el coordinador de streaming.
Otras características del componente WAL son
Gestión del ciclo de vida de los segmentos: Basándose en políticas como las condiciones de memoria, el tamaño del segmento o el tiempo de inactividad del segmento, la WAL gestiona el ciclo de vida de cada segmento.
Soporte básico de transacciones: Dado que cada mensaje tiene un límite de tamaño, el componente WAL admite el nivel de transacción simple para prometer escrituras atómicas en el nivel VChannel.
Escritura de registro remoto de alta concurrencia: Milvus admite colas de mensajes remotas de terceros como almacenamiento WAL. Para mitigar la latencia de ida y vuelta (RTT) entre el nodo de streaming y el almacenamiento WAL remoto para mejorar el rendimiento de escritura, el servicio de streaming admite escrituras de registro concurrentes. Mantiene el orden de los mensajes mediante sincronización TSO y TSO, y los mensajes de la WAL se leen en orden TSO.
Buffer de escritura anticipada: Después de escribir los mensajes en la WAL, se almacenan temporalmente en un búfer de escritura anticipada. Esto permite realizar lecturas de cola de los registros sin tener que recuperar los mensajes del almacenamiento WAL remoto.
Soporta múltiples almacenamientos WAL: Woodpecker, Pulsar, Kafka. Si utilizamos Woodpecker en modo disco cero, podemos eliminar la dependencia del almacenamiento WAL remoto.
Almacenamiento de recuperación
El componente Recovery Storage siempre se ejecuta en el nodo de streaming en el que se encuentra el componente WAL correspondiente.
Es responsable de convertir los datos de streaming en datos históricos persistentes y almacenarlos en el almacenamiento de objetos.
También gestiona la recuperación del estado en memoria para el componente WAL en el nodo de streaming.
Almacenamiento de recuperación
Delegador de consultas
El Delegador de Consultas se ejecuta en cada nodo de streaming y es responsable de ejecutar consultas incrementales en un único fragmento. Genera planes de consulta, los envía a los nodos de consulta pertinentes y agrega los resultados.
Además, el Delegador de consultas se encarga de transmitir las operaciones de eliminación a otros nodos de consulta.
El Delegador de consultas siempre coexiste con el componente WAL en el mismo nodo de transmisión. Pero si la colección está configurada con multi-replica, entonces se desplegarán N-1 Delegadores en los otros nodos de streaming.
Duración de la WAL y espera de disponibilidad
Al separar los nodos de computación del almacenamiento, Milvus puede transferir fácilmente WAL de un nodo de streaming a otro, consiguiendo una alta disponibilidad en el servicio de streaming.
Tiempo de vida de la WAL
Espera de disponibilidad
Cuando la WAL va a trasladarse a un nuevo nodo de streaming, el cliente se encontrará con que el antiguo nodo de streaming rechaza algunas peticiones. Mientras tanto, la WAL será recuperada en el nuevo nodo de streaming, el cliente esperará a que la wal en el nuevo nodo de streaming esté lista para servir.
esperar a que esté listo