Zeitsynchronisation

In diesem Thema wird der Zeitsynchronisationsmechanismus in Milvus vorgestellt.

Überblick

Die Ereignisse in Milvus können im Allgemeinen in zwei Typen kategorisiert werden:

• DDL-Ereignisse (Data Definition Language): Erstellen/Löschen einer Sammlung, Erstellen/Löschen einer Partition, usw.

• DML-Ereignisse (Data Manipulation Language): Einfügen, Suchen, usw.

Jedes Ereignis, egal ob DDL- oder DML-Ereignis, wird mit einem Zeitstempel versehen, der angibt, wann dieses Ereignis eintritt.

Nehmen wir an, es gibt zwei Benutzer, die eine Reihe von DML- und DDL-Ereignissen in Milvus in der in der folgenden Tabelle angegebenen zeitlichen Reihenfolge initiieren.

Idealerweise sollte Benutzer 2 in der Lage sein, zu sehen:

• Eine leere Sammlung C0 unter t2.

• Daten A1 unter t7.

• Beide Daten A1 und A2 unter t12.

• Nur die Daten A2 unter t17 (da die Daten A1 vor diesem Zeitpunkt aus der Sammlung gelöscht wurden).

Dieses ideale Szenario kann leicht erreicht werden, wenn es nur einen einzigen Knoten gibt. Milvus ist jedoch eine verteilte Vektordatenbank, und um sicherzustellen, dass alle DML- und DDL-Operationen in verschiedenen Knoten in der richtigen Reihenfolge durchgeführt werden, muss Milvus die folgenden beiden Probleme lösen:

1. Die Zeituhr ist für die beiden Benutzer im obigen Beispiel unterschiedlich, wenn sie sich auf verschiedenen Knoten befinden. Wenn z. B. Benutzer 2 24 Stunden hinter Benutzer 1 liegt, sind alle Operationen von Benutzer 1 für Benutzer 2 erst am nächsten Tag sichtbar.

2. Es kann zu Netzwerklatenz kommen. Wenn Benutzer 2 eine Suche in der Sammlung C0 unter t17 durchführt, sollte Milvus in der Lage sein, zu garantieren, dass alle Vorgänge vor t17 erfolgreich verarbeitet und abgeschlossen werden. Wenn sich der Löschvorgang unter t15 aufgrund von Netzwerklatenz verzögert, ist es sehr wahrscheinlich, dass Benutzer 2 die vermeintlich gelöschten Daten A1 noch sehen kann, wenn er eine Suche unter t17 durchführt.

Daher verwendet Milvus ein Zeitsynchronisationssystem (Timetick), um diese Probleme zu lösen.

Zeitstempel-Orakel (TSO)

Um das erste Problem zu lösen, das im vorigen Abschnitt erwähnt wurde, bietet Milvus, wie andere verteilte Systeme auch, einen Zeitstempel-Orakel (TSO) Dienst. Das bedeutet, dass alle Ereignisse in Milvus mit einem Zeitstempel vom TSO und nicht von der lokalen Uhr versehen werden müssen.

Der TSO-Dienst wird vom Root-Koordinator in Milvus bereitgestellt. Clients können einen oder mehrere Zeitstempel in einer einzigen Zeitstempelanforderung zuweisen.

Ein TSO-Zeitstempel ist ein Wert des Typs uint64, der sich aus einem physischen und einem logischen Teil zusammensetzt. Die folgende Abbildung veranschaulicht das Format eines Zeitstempels.

TSO_Zeitstempel.

Wie dargestellt, sind die 46 Bits am Anfang der physische Teil, nämlich die UTC-Zeit in Millisekunden. Die letzten 18 Bits sind der logische Teil.

Zeitsynchronisationssystem (Timetick)

In diesem Abschnitt wird der Zeitsynchronisationsmechanismus in Milvus am Beispiel eines Dateneinfügevorgangs erläutert.

Wenn der Proxy eine Dateneinfügeanforderung vom SDK erhält, teilt er die Einfügemeldungen in verschiedene Meldungsströme (MsgStream) entsprechend dem Hash-Wert der Primärschlüssel auf.

Jede Einfügemeldung (InsertMsg) wird mit einem Zeitstempel versehen, bevor sie an die MsgStream gesendet wird.

timesync_proxy_insert_msg

Ein allgemeiner Grundsatz besagt, dass die Zeitstempel derInsertMsgs vom selben Proxy auf MsgStream inkrementell sein müssen. Für die Zeitstempel der InsertMsgs von verschiedenen Proxys gibt es jedoch keine solche Regel.

Die folgende Abbildung ist ein Beispiel für InsertMsgs in einem MsgStream. Das Snippet enthält fünf InsertMsgs, von denen drei von Proxy1 und die übrigen von Proxy2 stammen.

msgstream

Die Zeitstempel der drei InsertMsgs von Proxy1 sind inkrementell, ebenso wie die der beiden InsertMsgs von Proxy2. Es gibt jedoch keine bestimmte Reihenfolge zwischen Proxy1 und Proxy2 InsertMsgs .

Ein mögliches Szenario ist, dass Milvus beim Lesen einer Nachricht mit dem Zeitstempel 110 von Proxy2 feststellt, dass sich die Nachricht mit dem Zeitstempel 80 von Proxy1 noch im MsgStream befindet. Daher führt Milvus ein Zeitsynchronisationssystem, timetick, ein, um sicherzustellen, dass beim Lesen einer Nachricht von MsgStream alle Nachrichten mit kleineren Zeitstempelwerten konsumiert werden müssen.

time_synchronisation

Wie in der Abbildung oben dargestellt,

• Jeder Proxy meldet in regelmäßigen Abständen (standardmäßig alle 200 ms) den größten Zeitstempelwert der letzten InsertMsg in der MsgStreaman root coord.

• Root Coord identifiziert den minimalen Zeitstempelwert auf dieser Msgstream, unabhängig davon, zu welchem Proxy die InsertMsgs gehört. Dann fügt Root Coord diesen minimalen Zeitstempel in die Msgstream ein. Dieser Zeitstempel wird auch Timetick genannt.

• Wenn die Verbraucherkomponenten den von Root Coord eingefügten Timetick lesen, verstehen sie, dass alle Einfüge-Nachrichten mit kleineren Timestamp-Werten verbraucht wurden. Daher können die entsprechenden Anfragen sicher ausgeführt werden, ohne dass der Auftrag unterbrochen wird.

Die folgende Abbildung ist ein Beispiel für Msgstream mit einem eingefügten Zeitstempel.

Zeitstempel

MsgStream verarbeitet die Nachrichten in Stapeln entsprechend dem Zeitstempel, um sicherzustellen, dass die ausgegebenen Nachrichten den Anforderungen des Zeitstempels entsprechen. Im obigen Beispiel werden alle Datensätze mit Ausnahme von InsertMsgs von Proxy2 auf Timestamp: 120 verarbeitet, da sie nach dem letzten TimeTick liegen.

Was kommt als Nächstes?

• Lernen Sie das Konzept des Zeitstempels kennen.
• Lernen Sie den Arbeitsablauf der Datenverarbeitung in Milvus kennen.