Sincronizzazione temporale

Questo argomento introduce il meccanismo di sincronizzazione temporale di Milvus.

Panoramica

Gli eventi in Milvus possono essere generalmente classificati in due tipi:

• Eventi del linguaggio di definizione dei dati (DDL): creare/togliere una collezione, creare/togliere una partizione, ecc.

• Eventi del linguaggio di manipolazione dei dati (DML): inserimento, ricerca, ecc.

Ogni evento, indipendentemente dal fatto che sia DDL o DML, è contrassegnato da un timestamp che può indicare quando si verifica l'evento.

Supponiamo che due utenti inizino una serie di eventi DML e DDL in Milvus nell'ordine temporale indicato nella tabella seguente.

Idealmente, l'utente 2 dovrebbe essere in grado di vedere:

• Una raccolta vuota C0 a t2.

• I dati A1 su t7.

• Entrambi i dati A1 e A2 su t12.

• Solo i dati A2 in t17 (poiché i dati A1 sono stati cancellati dalla raccolta prima di questo punto).

Questo scenario ideale può essere facilmente realizzato quando c'è un solo nodo. Tuttavia, Milvus è un database vettoriale distribuito e per garantire che tutte le operazioni DML e DDL nei diversi nodi siano mantenute in ordine, Milvus deve affrontare i due problemi seguenti:

1. L'orologio è diverso per i due utenti dell'esempio precedente se si trovano su nodi diversi. Ad esempio, se l'utente 2 è 24 ore indietro rispetto all'utente 1, tutte le operazioni dell'utente 1 non sono visibili all'utente 2 fino al giorno successivo.

2. Può esserci una latenza di rete. Se l'utente 2 effettua una ricerca sulla collezione C0 all'indirizzo t17, Milvus dovrebbe essere in grado di garantire che tutte le operazioni prima di t17 vengano elaborate e completate con successo. Se l'operazione di cancellazione in t15 è ritardata a causa della latenza di rete, è molto probabile che l'utente 2 possa ancora vedere i dati presumibilmente cancellati A1 quando effettua una ricerca in t17.

Pertanto, Milvus adotta un sistema di sincronizzazione temporale (timetick) per risolvere il problema.

Timestamp oracle (TSO)

Per risolvere il primo problema menzionato nella sezione precedente, Milvus, come altri sistemi distribuiti, fornisce un servizio di timestamp oracle (TSO). Ciò significa che tutti gli eventi in Milvus devono essere assegnati con un timestamp dal TSO piuttosto che dall'orologio locale.

Il servizio TSO è fornito dal coordinatore principale di Milvus. I client possono allocare uno o più timestamp in una singola richiesta di allocazione di timestamp.

Un timestamp TSO è un tipo di valore uint64 composto da una parte fisica e una logica. La figura seguente illustra il formato di un timestamp.

TSO_Timestamp.

Come illustrato, i 46 bit all'inizio rappresentano la parte fisica, ovvero l'ora UTC in millisecondi. Gli ultimi 18 bit sono la parte logica.

Sistema di sincronizzazione temporale (timetick)

Questa sezione utilizza l'esempio di un'operazione di inserimento dati per spiegare il meccanismo di sincronizzazione temporale di Milvus.

Quando il proxy riceve una richiesta di inserimento dati dall'SDK, divide i messaggi di inserimento in diversi flussi di messaggi (MsgStream) in base al valore hash delle chiavi primarie.

A ogni messaggio di inserimento (InsertMsg) viene assegnato un timestamp prima di essere inviato a MsgStream.

timesync_proxy_insert_msg

Un principio generale è che in MsgStream, i timestamp diInsertMsgs provenienti dallo stesso proxy devono essere incrementali. Tuttavia, non esiste una regola simile per i timestamp di InsertMsgs provenienti da proxy diversi.

La figura seguente è un esempio di InsertMsgs in un MsgStream. Il frammento contiene cinque InsertMsgs, tre dei quali provengono da Proxy1 e il resto da Proxy2.

msgstream

I timestamp dei tre InsertMsgs di Proxy1 sono incrementali, così come i due InsertMsgs di Proxy2. Tuttavia, non c'è un ordine particolare tra Proxy1 e Proxy2 InsertMsgs .

Un possibile scenario è che quando si legge un messaggio con timestamp 110 da Proxy2, Milvus scopra che il messaggio con timestamp 80 da Proxy1 è ancora in MsgStream. Pertanto, Milvus introduce un sistema di sincronizzazione temporale, timetick, per garantire che quando si legge un messaggio da MsgStream, tutti i messaggi con timestamp più piccoli devono essere consumati.

sincronizzazione temporale

Come mostrato nella figura precedente,

• Ogni proxy riporta periodicamente (ogni 200 ms per impostazione predefinita) il valore di timestamp più grande dell'ultimo InsertMsg nel MsgStreama root coord.

• Il root coord identifica il valore minimo del timestamp di questo Msgstream, indipendentemente dal proxy a cui appartiene il InsertMsgs. Quindi root coord inserisce questo timestamp minimo in Msgstream. Questo timestamp è chiamato anche timetick.

• Quando i componenti consumer leggono il timetick inserito da root coord, capiscono che tutti i messaggi di inserimento con valori di timestamp inferiori sono stati consumati. Pertanto, le richieste pertinenti possono essere eseguite in modo sicuro senza interrompere l'ordine.

La figura seguente è un esempio di Msgstream con un timetick inserito.

timetick

MsgStream elabora i messaggi in batch in base al timetick per garantire che i messaggi in uscita soddisfino i requisiti del timestamp.

Cosa succede dopo

• Conoscere il concetto di timestamp.
• Conoscere il flusso di lavoro dell'elaborazione dei dati in Milvus.