Zeitstempel
Dieses Thema erklärt das Konzept des Zeitstempels und stellt die vier wichtigsten zeitstempelbezogenen Parameter in der Milvus-Vektordatenbank vor.
Überblick
Milvus ist eine Vektordatenbank, die aus unstrukturierten Daten konvertierte Vektoren suchen und abfragen kann. Bei der Durchführung einer DML-Operation (Data Manipulation Language), einschließlich des Einfügens und Löschens von Daten, weist Milvus den an der Operation beteiligten Entitäten Zeitstempel zu. Daher haben alle Entitäten in Milvus ein Zeitstempel-Attribut. Und die Stapel von Entitäten in derselben DML-Operation haben denselben Zeitstempelwert.
Zeitstempel-Parameter
Mehrere zeitstempelbezogene Parameter sind beteiligt, wenn Sie eine Vektorähnlichkeitssuche oder -abfrage in Milvus durchführen.
Guarantee_timestamp
Service_timestamp
Graceful_time
Travel_timestamp
Guarantee_timestamp
Guarantee_timestamp
ist eine Art von Zeitstempel, der verwendet wird, um sicherzustellen, dass alle Datenaktualisierungen durch DML-Operationen vor Guarantee_timestamp
sichtbar sind, wenn eine Vektorähnlichkeitssuche oder -abfrage durchgeführt wird. Wenn Sie beispielsweise einen Datenstapel um 15 Uhr und einen weiteren um 17 Uhr eingefügt haben und der Wert von Guarantee_timestamp
während einer Vektorähnlichkeitssuche auf 18 Uhr festgelegt ist. Dies bedeutet, dass die beiden um 15 Uhr bzw. 17 Uhr eingefügten Datenstapel in die Suche einbezogen werden sollten.
Wenn Guarantee_timestamp
nicht konfiguriert ist, nimmt Milvus automatisch den Zeitpunkt, an dem die Suchanfrage gestellt wird. Daher wird die Suche in einer Datenansicht mit allen Datenaktualisierungen durch DML-Operationen vor der Suche durchgeführt.
Um Ihnen die Mühe zu ersparen, den TSO innerhalb von Milvus zu verstehen, müssen Sie als Benutzer den Parameter Guarantee_timestamp
nicht direkt konfigurieren. Sie müssen nur die Konsistenzstufe auswählen, und Milvus verwaltet den Parameter Guarantee_timestamp
automatisch für Sie. Jede Konsistenzstufe entspricht einem bestimmten Guarantee_timestamp
Wert.
Garantiert_Zeitstempel.
Beispiel
Wie in der obigen Abbildung gezeigt, ist der Wert von Guarantee_timestamp
auf 2021-08-26T18:15:00
eingestellt (der Einfachheit halber wird der Zeitstempel in diesem Beispiel durch die physikalische Zeit dargestellt). Wenn Sie eine Suche oder Abfrage durchführen, werden alle Daten vor 2021-08-26T18:15:00 durchsucht oder abgefragt.
Service_timestamp
Service_timestamp
ist ein Typ von Zeitstempel, der automatisch von Abfrageknoten in Milvus generiert und verwaltet wird. Er wird verwendet, um anzuzeigen, welche DML-Operationen von Abfrageknoten ausgeführt werden.
Die von Abfrageknoten verwalteten Daten können in zwei Typen kategorisiert werden:
Historische Daten (oder auch Batch-Daten genannt)
Inkrementelle Daten (oder auch Streaming-Daten genannt).
In Milvus müssen Sie die Daten laden, bevor Sie eine Suche oder Abfrage durchführen. Daher werden Batch-Daten in einer Sammlung von einem Abfrageknoten geladen, bevor eine Such- oder Abfrageanfrage gestellt wird. Streaming-Daten werden jedoch in Milvus während des laufenden Betriebs eingefügt oder gelöscht, so dass der Abfrageknoten einen Zeitplan für die DML-Operationen und die Such- oder Abfrageanfragen erstellen muss. Daher verwenden die Abfrageknoten Service_timestamp
, um eine solche Zeitleiste zu führen. Service_timestamp
kann als der Zeitpunkt angesehen werden, an dem bestimmte Daten sichtbar sind, da die Abfrageknoten sicherstellen können, dass alle DML-Operationen vor Service_timestamp
abgeschlossen sind.
Wenn eine Such- oder Abfrageanfrage eingeht, vergleicht ein Abfrageknoten die Werte von Service_timestamp
und Guarantee_timestamp
. Es gibt hauptsächlich zwei Szenarien.
Service_Timestamp.
Szenario 1: Service_timestamp
>= Guarantee_timestamp
Wie in Abbildung 1 dargestellt, wird der Wert von Guarantee_timestamp
als 2021-08-26T18:15:00
festgelegt. Wenn der Wert von Service_timestamp
auf 2021-08-26T18:15:01
angewachsen ist, bedeutet dies, dass alle DML-Operationen vor diesem Zeitpunkt vom Abfrageknoten ausgeführt und abgeschlossen werden, einschließlich der DML-Operationen vor dem durch Guarantee_timestamp
angegebenen Zeitpunkt. Folglich kann die Such- oder Abfrageanfrage sofort ausgeführt werden.
Szenario 2: Service_timestamp
< Guarantee_timestamp
Wie in Abbildung 2 dargestellt, ist der Wert von Guarantee_timestamp
auf 2021-08-26T18:15:00
gesetzt, und der aktuelle Wert von Service_timestamp
ist nur 2021-08-26T18:14:55
. Dies bedeutet, dass nur DML-Operationen vor 2021-08-26T18:14:55
ausgeführt und abgeschlossen werden, wobei ein Teil der DML-Operationen nach diesem Zeitpunkt, aber vor Guarantee_timestamp
, nicht abgeschlossen wird. Wenn die Suche oder Abfrage zu diesem Zeitpunkt ausgeführt wird, sind einige der erforderlichen Daten noch nicht sichtbar und nicht verfügbar, was die Genauigkeit der Such- oder Abfrageergebnisse erheblich beeinträchtigt. Daher muss der Abfrageknoten die Such- oder Abfrageanfrage verschieben, bis die DML-Operationen vor guarantee_timestamp
abgeschlossen sind (d. h. wenn Service_timestamp
>= Guarantee_timestamp
).
Graceful_time
Technisch gesehen ist Graceful_time
kein Zeitstempel, sondern eher eine Zeitspanne (z. B. 100 ms). Dennoch ist Graceful_time
erwähnenswert, da er eng mit Guarantee_timestamp
und Service_timestamp
zusammenhängt. Graceful_time
ist ein konfigurierbarer Parameter in der Milvus-Konfigurationsdatei. Er wird verwendet, um die Zeitspanne anzugeben, die toleriert werden kann, bevor bestimmte Daten sichtbar werden. Kurz gesagt, können nicht abgeschlossene DML-Operationen während Graceful_time
toleriert werden.
Wenn eine Such- oder Abfrageanfrage eingeht, kann es zwei Szenarien geben.
Graceful_Time.
Szenario 1: Service_timestamp
+ Graceful_time
>= Guarantee_timestamp
Wie in Abbildung 1 dargestellt, wird der Wert von Guarantee_timestamp
als 2021-08-26T18:15:01
und Graceful_time
als 2s
festgelegt. Der Wert von Service_timestamp
ist auf 2021-08-26T18:15:00
angewachsen. Obwohl der Wert von Service_timestamp
immer noch kleiner ist als der von Guarantee_timestamp
und nicht alle DML-Vorgänge vor 2021-08-26T18:15:01
abgeschlossen sind, wird eine Zeitspanne von 2 Sekunden der Datenunsichtbarkeit toleriert, wie durch den Wert von Graceful_time
angezeigt. Daher kann die eingehende Such- oder Abfrageanfrage sofort ausgeführt werden.
Szenario 2: Service_timestamp
+ Graceful_time
< Guarantee_timestamp
Wie in Abbildung 2 dargestellt, wird der Wert von Guarantee_timestamp
auf 2021-08-26T18:15:01
und der Wert von Graceful_time
auf 2s
gesetzt. Der aktuelle Wert von Service_timestamp
ist nur 2021-08-26T18:14:54
. Das bedeutet, dass die erwarteten DML-Vorgänge noch nicht abgeschlossen sind und dass die Unsichtbarkeit der Daten selbst bei einer Schonzeit von 2 Sekunden nicht tolerierbar ist. Daher muss der Abfrageknoten die Such- oder Abfrageanforderung zurückstellen, bis bestimmte DML-Anforderungen abgeschlossen sind (d. h. wenn Service_timestamp
+ Graceful_time
>= Guarantee_timestamp
).