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/hora | Utilizador 1 | Utilizador 2 |
---|---|---|
t0 | Criou uma coleção com o nome C0 . | / |
t2 | / | Efectuou uma pesquisa na coleção C0 . |
t5 | Inserção de dados A1 na coleção C0 . | / |
t7 | / | Efectuou uma pesquisa na coleção C0 . |
t10 | Inserção de dados A2 na coleção C0 . | / |
t12 | / | Efectuou uma pesquisa na coleção C0 |
t15 | Dados 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
emt2
.Dados
A1
emt7
.Ambos os dados
A1
eA2
emt12
.Apenas os dados
A2
emt17
(uma vez que os dadosA1
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:
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.
Pode haver latência de rede. Se o utilizador 2 efetuar uma pesquisa na coleção
C0
emt17
, o Milvus deve poder garantir que todas as operações antes det17
são processadas e concluídas com êxito. Se a operação de eliminação emt15
for atrasada devido à latência da rede, é muito provável que o utilizador 2 ainda possa ver os dados supostamente eliminados emA1
quando efetuar uma pesquisa emt17
.
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.
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
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
.
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.
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
noMsgStream
para o root coord.A coord raiz identifica o valor mínimo de timestamp neste
Msgstream
, independentemente do proxy a que pertence oInsertMsgs
. Em seguida, a coord de raiz insere este carimbo de data/hora mínimo emMsgstream
. 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.
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
- Saiba mais sobre o conceito de carimbo de data/hora.
- Saiba mais sobre o fluxo de trabalho de processamento de dados no Milvus.