milvus-logo
LFAI
Home
  • Conceitos

Sincronização de tempo

Este tópico apresenta o mecanismo de sincronização de tempo no Milvus.

Visão geral

Os eventos no Milvus podem ser geralmente categorizados em dois tipos:

  • Eventos de linguagem de definição de dados (DDL): criar/soltar uma coleção, criar/soltar uma partição, etc.

  • Eventos de linguagem de manipulação de dados (DML): inserção, pesquisa, etc.

Qualquer evento, independentemente de ser DDL ou DML, é marcado com um carimbo de data/hora que pode indicar quando esse evento ocorre.

Suponhamos que dois utilizadores iniciam uma série de eventos DML e DDL no Milvus pela ordem temporal indicada na tabela seguinte.

Carimbo de data/horaUtilizador 1Utilizador 2
t0Criou uma coleção com o nome C0./
t2/Efectuou uma pesquisa na coleção C0.
t5Inserção de dados A1 na coleção C0./
t7/Efectuou uma pesquisa na coleção C0.
t10Inserção de dados A2 na coleção C0./
t12/Efectuou uma pesquisa na coleção C0
t15Dados eliminados A1 da coleção C0./
t17/Efectuou uma pesquisa na coleção C0

Idealmente, o utilizador 2 deve ser capaz de ver:

  • Uma coleção vazia C0 em t2.

  • Dados A1 em t7.

  • Ambos os dados A1 e A2 em t12.

  • Apenas os dados A2 em t17 (uma vez que os dados A1 foram eliminados da coleção antes deste ponto).

Este cenário ideal pode ser facilmente alcançado quando existe apenas um único nó. No entanto, o Milvus é uma base de dados vetorial distribuída e, para garantir que todas as operações DML e DDL em nós diferentes são mantidas em ordem, o Milvus tem de resolver os dois problemas seguintes:

  1. O relógio de tempo é diferente para os dois utilizadores no exemplo acima se eles estiverem em nós diferentes. Por exemplo, se o utilizador 2 estiver 24 horas atrasado em relação ao utilizador 1, todas as operações do utilizador 1 só serão visíveis para o utilizador 2 no dia seguinte.

  2. Pode haver latência de rede. Se o utilizador 2 efetuar uma pesquisa na coleção C0 em t17, o Milvus deve poder garantir que todas as operações antes de t17 são processadas e concluídas com êxito. Se a operação de eliminação em t15 for atrasada devido à latência da rede, é muito provável que o utilizador 2 ainda possa ver os dados supostamente eliminados em A1 quando efetuar uma pesquisa em t17.

Por conseguinte, o Milvus adopta um sistema de sincronização do tempo (timetick) para resolver os problemas.

Oráculo de carimbo de data/hora (TSO)

Para resolver o primeiro problema mencionado na secção anterior, o Milvus, tal como outros sistemas distribuídos, fornece um serviço de oráculo de carimbo de data/hora (TSO). Isto significa que todos os eventos no Milvus devem ser atribuídos com um carimbo de data/hora do TSO e não do relógio local.

O serviço TSO é fornecido pelo coordenador de raiz do Milvus. Os clientes podem atribuir um ou mais carimbos temporais num único pedido de atribuição de carimbos temporais.

Um carimbo de data/hora TSO é um tipo de uint64 valor que é composto por uma parte física e uma parte lógica. A figura seguinte mostra o formato de um carimbo de data/hora.

TSO_Timestamp TSO_Timestamp.

Como ilustrado, os 46 bits no início são a parte física, nomeadamente a hora UTC em milissegundos. Os últimos 18 bits são a parte lógica.

Sistema de sincronização do tempo (timetick)

Esta secção utiliza o exemplo de uma operação de inserção de dados para explicar o mecanismo de sincronização do tempo em Milvus.

Quando o proxy recebe um pedido de inserção de dados do SDK, divide as mensagens de inserção em diferentes fluxos de mensagens (MsgStream) de acordo com o valor hash das chaves primárias.

A cada mensagem de inserção (InsertMsg) é atribuído um carimbo de data/hora antes de ser enviada para o MsgStream.

MsgStream é um wrapper da fila de mensagens, que é Pulsar por defeito no Milvus 2.0.

timesync_proxy_insert_msg timesync_proxy_insert_msg

Um princípio geral é que no MsgStream, os timestamps doInsertMsgs do mesmo proxy devem ser incrementais. No entanto, não existe essa regra para os InsertMsgs de diferentes proxies.

A figura seguinte é um exemplo de InsertMsgs num MsgStream. O snippet contém cinco InsertMsgs, três dos quais são de Proxy1 e os restantes de Proxy2.

msgstream fluxo de mensagens

Os carimbos de data/hora dos três InsertMsgs de Proxy1 são incrementais, tal como os dois InsertMsgs de Proxy2. No entanto, não existe uma ordem específica entre Proxy1 e Proxy2 InsertMsgs .

Um cenário possível é que, ao ler uma mensagem com carimbo de data/hora 110 de Proxy2, Milvus descobre que a mensagem com carimbo de data/hora 80 de Proxy1 ainda está em MsgStream. Portanto, Milvus introduz um sistema de sincronização de tempo, timetick, para garantir que, ao ler uma mensagem de MsgStream, todas as mensagens com valores de carimbo de data/hora menores devem ser consumidas.

time_synchronization sincronização de tempo

Como mostrado na figura acima,

  • Cada proxy reporta periodicamente (a cada 200 ms por padrão) o maior valor de timestamp do último InsertMsg no MsgStreampara o root coord.

  • A coord raiz identifica o valor mínimo de timestamp neste Msgstream, independentemente do proxy a que pertence o InsertMsgs. Em seguida, a coord de raiz insere este carimbo de data/hora mínimo em Msgstream. Este carimbo de data/hora é também designado por timetick.

  • Quando os componentes consumidores lêem o timetick inserido pelo root coord, compreendem que todas as mensagens de inserção com valores de timestamp mais pequenos foram consumidas. Por conseguinte, os pedidos relevantes podem ser executados em segurança sem interromper a ordem.

A figura seguinte é um exemplo do sítio Msgstream com um timetick inserido.

timetick marca de tempo

MsgStream processa as mensagens em lotes de acordo com o tique de tempo para garantir que as mensagens de saída cumprem os requisitos do carimbo de data/hora.

O que se segue

Traduzido porDeepLogo

Try Zilliz Cloud for Free

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

Get Started
Feedback

Esta página foi útil?