milvus-logo
LFAI
Home
  • Conceptos

Sincronización horaria

Este tema presenta el mecanismo de sincronización horaria en Milvus.

Visión general

Los eventos en Milvus pueden clasificarse generalmente en dos tipos:

  • Eventos de lenguaje de definición de datos (DDL): crear/soltar una colección, crear/soltar una partición, etc.

  • Eventos de lenguaje de manipulación de datos (DML): insertar, buscar, etc.

Cualquier evento, ya sea DDL o DML, se marca con una marca de tiempo que puede indicar cuándo se produce.

Supongamos que hay dos usuarios que inician una serie de eventos DML y DDL en Milvus en el orden temporal que se muestra en la siguiente tabla.

Marca de tiempoUsuario 1Usuario 2
t0Creó una colección llamada C0./
t2/Realizada una búsqueda en la colección C0.
t5Datos insertados A1 en la colección C0./
t7/Búsqueda en la colección C0.
t10Inserción de datos A2 en la colección C0./
t12/Búsqueda en la colección C0
t15Borrados los datos A1 de la colección C0./
t17/Realizada una búsqueda en la colección C0

Idealmente, el usuario 2 debería poder ver

  • Una colección vacía C0 en t2.

  • Los datos A1 en t7.

  • Los datos A1 y A2 en t12.

  • Sólo los datos A2 en t17 (ya que los datos A1 se han eliminado de la colección antes de este punto).

Este escenario ideal puede alcanzarse fácilmente cuando sólo hay un único nodo. Sin embargo, Milvus es una base de datos vectorial distribuida, y para garantizar que todas las operaciones DML y DDL en diferentes nodos se mantienen en orden, Milvus necesita abordar las dos cuestiones siguientes:

  1. El reloj de tiempo es diferente para los dos usuarios del ejemplo anterior si están en nodos diferentes. Por ejemplo, si el usuario 2 está 24 horas por detrás del usuario 1, todas las operaciones del usuario 1 no son visibles para el usuario 2 hasta el día siguiente.

  2. Puede haber latencia de red. Si el usuario 2 realiza una búsqueda en la colección C0 en t17, Milvus debería poder garantizar que todas las operaciones anteriores a t17 se procesan y completan con éxito. Si la operación de borrado en t15 se retrasa debido a la latencia de la red, es muy probable que el usuario 2 pueda seguir viendo los datos supuestamente borrados A1 al realizar una búsqueda en t17.

Por lo tanto, Milvus adopta un sistema de sincronización temporal (timetick) para resolver los problemas.

Oráculo de marcas de tiempo (TSO)

Para resolver el primer problema mencionado en la sección anterior, Milvus, al igual que otros sistemas distribuidos, proporciona un servicio de oráculo de marca de tiempo (TSO). Esto significa que todos los eventos en Milvus deben ser asignados con una marca de tiempo del TSO en lugar del reloj local.

El servicio TSO lo proporciona el coordinador raíz de Milvus. Los clientes pueden asignar una o más marcas de tiempo en una única solicitud de asignación de marca de tiempo.

Una marca de tiempo TSO es un tipo de valor uint64 que se compone de una parte física y una parte lógica. La siguiente figura muestra el formato de una marca de tiempo.

TSO_Timestamp TSO_Timestamp.

Como se muestra, los 46 bits del principio son la parte física, es decir, la hora UTC en milisegundos. Los últimos 18 bits son la parte lógica.

Sistema de sincronización horaria (timetick)

Esta sección utiliza el ejemplo de una operación de inserción de datos para explicar el mecanismo de sincronización de tiempo en Milvus.

Cuando el proxy recibe una solicitud de inserción de datos del SDK, divide los mensajes de inserción en diferentes flujos de mensajes (MsgStream) según el valor hash de las claves primarias.

A cada mensaje de inserción (InsertMsg) se le asigna una marca de tiempo antes de ser enviado a MsgStream.

MsgStream es una envoltura de la cola de mensajes, que es Pulsar por defecto en Milvus 2.0.

timesync_proxy_insert_msg timesync_proxy_insert_msg

Un principio general es que en MsgStream, las marcas de tiempo deInsertMsgs del mismo proxy deben ser incrementales. Sin embargo, no existe tal regla para las de InsertMsgs procedentes de proxies diferentes.

La siguiente figura es un ejemplo de InsertMsgs en un MsgStream. El fragmento contiene cinco InsertMsgs, tres de los cuales proceden de Proxy1 y el resto de Proxy2.

msgstream msgstream

Las marcas de tiempo de los tres InsertMsgs de Proxy1 son incrementales, al igual que las de los dos InsertMsgs de Proxy2. Sin embargo, no existe un orden concreto entre Proxy1 y Proxy2 InsertMsgs .

Un escenario posible es que al leer un mensaje con timestamp 110 de Proxy2, Milvus encuentre que el mensaje con timestamp 80 de Proxy1 está todavía en MsgStream. Por lo tanto, Milvus introduce un sistema de sincronización de tiempo, timetick, para asegurar que al leer un mensaje de MsgStream, todos los mensajes con valores timestamp más pequeños deben ser consumidos.

time_synchronization sincronización_temporal

Como se muestra en la figura anterior,

  • Cada proxy informa periódicamente (cada 200 ms por defecto) del mayor valor de timestamp del último InsertMsg en el MsgStreama root coord.

  • Root coord identifica el valor mínimo de timestamp en este Msgstream, sin importar a qué proxy pertenece el InsertMsgs. A continuación, root coord inserta este timestamp mínimo en Msgstream. Este timestamp también se denomina timetick.

  • Cuando los componentes consumidores leen la marca de tiempo insertada por root coord, entienden que se han consumido todos los mensajes de inserción con valores de marca de tiempo menores. Por lo tanto, las peticiones relevantes pueden ejecutarse de forma segura sin interrumpir el orden.

La siguiente figura es un ejemplo de Msgstream con un timetick insertado.

timetick timetick

MsgStream procesa los mensajes por lotes en función de la marca de tiempo para garantizar que los mensajes de salida cumplen los requisitos de la marca de tiempo.

A continuación

Traducido porDeepLogo

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
Feedback

¿Fue útil esta página?