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_timestampService_timestampGraceful_timeTravel_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, zu 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 im laufenden Betrieb 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-Vorgänge vor diesem Zeitpunkt vom Abfrageknoten ausgeführt und abgeschlossen werden, einschließlich der DML-Vorgänge 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-Vorgänge vor 2021-08-26T18:14:55 ausgeführt und abgeschlossen werden, wobei ein Teil der DML-Vorgänge 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 aufschieben, 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). Graceful_time ist jedoch 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).
