Timestamp

Questo argomento spiega il concetto di timestamp e introduce i quattro principali parametri relativi al timestamp nel database vettoriale Milvus.

Panoramica

Milvus è un database vettoriale che può cercare e interrogare vettori convertiti da dati non strutturati. Quando si esegue un'operazione in linguaggio di manipolazione dei dati (DML), compresi l'inserimento e la cancellazione di dati, Milvus assegna dei timestamp alle entità coinvolte nell'operazione. Pertanto, tutte le entità in Milvus hanno un attributo timestamp. E i lotti di entità nella stessa operazione DML condividono lo stesso valore di timestamp.

Parametri di timestamp

Quando si esegue una ricerca o un'interrogazione di similarità vettoriale in Milvus sono coinvolti diversi parametri relativi al timestamp.

• Guarantee_timestamp

• Service_timestamp

• Graceful_time

• Travel_timestamp

Guarantee_timestamp

Guarantee_timestamp è un tipo di timestamp utilizzato per garantire che tutti gli aggiornamenti dei dati effettuati da operazioni DML prima di Guarantee_timestamp siano visibili quando si esegue una ricerca o una query di similarità vettoriale. Ad esempio, se si inserisce un batch di dati alle 15:00, un altro batch alle 17:00 e il valore di Guarantee_timestamp è impostato alle 18:00 durante una ricerca di similarità vettoriale. Ciò significa che i due batch di dati inseriti rispettivamente alle 15:00 e alle 17:00 devono essere coinvolti nella ricerca.

Se Guarantee_timestamp non è configurato, Milvus considera automaticamente il momento in cui viene effettuata la richiesta di ricerca. Pertanto, la ricerca viene condotta su una vista dati con tutti gli aggiornamenti dei dati tramite operazioni DML prima della ricerca.

Per risparmiare la comprensione del TSO all'interno di Milvus, come utente non è necessario configurare direttamente il parametro Guarantee_timestamp. È sufficiente scegliere il livello di consistenza e Milvus gestisce automaticamente il parametro Guarantee_timestamp. Ogni livello di coerenza corrisponde a un determinato valore di Guarantee_timestamp.

Garanzia_Timestamp.

Esempio

Come mostrato nell'illustrazione precedente, il valore di Guarantee_timestamp è impostato come 2021-08-26T18:15:00 (per semplicità, in questo esempio il timestamp è rappresentato dal tempo fisico). Quando si esegue una ricerca o una query, vengono ricercati o interrogati tutti i dati precedenti al 2021-08-26T18:15:00.

Service_timestamp

Service_timestamp è un tipo di timestamp generato automaticamente e gestito dai nodi di query in Milvus. Viene utilizzato per indicare quali operazioni DML vengono eseguite dai nodi di query.

I dati gestiti dai nodi di interrogazione possono essere classificati in due tipi:

• Dati storici (o anche chiamati dati batch)

• Dati incrementali (o anche chiamati dati in streaming).

In Milvus, è necessario caricare i dati prima di effettuare una ricerca o una query. Pertanto, i dati batch in una raccolta vengono caricati dal nodo di query prima che venga effettuata una ricerca o una richiesta di query. Tuttavia, i dati in streaming vengono inseriti o eliminati da Milvus al volo, il che richiede che il nodo di query mantenga una cronologia delle operazioni DML e delle richieste di ricerca o di query. Di conseguenza, i nodi di interrogazione utilizzano Service_timestamp per mantenere tale cronologia. Service_timestamp può essere visto come il momento in cui alcuni dati sono visibili, in quanto i nodi di interrogazione possono garantire che tutte le operazioni DML prima di Service_timestamp siano state completate.

Quando c'è una richiesta di ricerca o di interrogazione in arrivo, un nodo di interrogazione confronta i valori di Service_timestamp e Guarantee_timestamp. Esistono principalmente due scenari.

Service_Timestamp.

Scenario 1: Service_timestamp >= Guarantee_timestamp

Come mostrato nella figura 1, il valore di Guarantee_timestamp è impostato come 2021-08-26T18:15:00. Quando il valore di Service_timestamp è cresciuto fino a 2021-08-26T18:15:01, significa che tutte le operazioni DML precedenti a questo momento sono state eseguite e completate dal nodo di query, comprese le operazioni DML precedenti al momento indicato da Guarantee_timestamp. Di conseguenza, la richiesta di ricerca o di interrogazione può essere eseguita immediatamente.

Scenario 2: Service_timestamp < Guarantee_timestamp

Come mostrato nella figura 2, il valore di Guarantee_timestamp è impostato come 2021-08-26T18:15:00, e il valore corrente di Service_timestamp è solo 2021-08-26T18:14:55. Ciò significa che solo le operazioni DML prima di 2021-08-26T18:14:55 vengono eseguite e completate, lasciando incompiuta una parte delle operazioni DML dopo questo punto temporale ma prima di Guarantee_timestamp. Se la ricerca o la query viene eseguita a questo punto, alcuni dei dati richiesti sono ancora invisibili e non disponibili, il che compromette seriamente l'accuratezza dei risultati della ricerca o della query. Pertanto, il nodo di interrogazione deve rimandare la richiesta di ricerca o di interrogazione fino al completamento delle operazioni DML prima di guarantee_timestamp (cioè quando Service_timestamp >= Guarantee_timestamp).

Graceful_time

Tecnicamente, Graceful_time non è un timestamp, ma piuttosto un periodo di tempo (ad esempio 100 ms). Tuttavia, Graceful_time è degno di nota perché è fortemente correlato a Guarantee_timestamp e Service_timestamp. Graceful_time è un parametro configurabile nel file di configurazione di Milvus. Viene utilizzato per indicare il periodo di tempo che può essere tollerato prima che alcuni dati diventino visibili. In breve, le operazioni DML non completate durante Graceful_time possono essere tollerate.

Quando c'è una richiesta di ricerca o di interrogazione in arrivo, si possono verificare due scenari.

Graceful_Time.

Scenario 1: Service_timestamp + Graceful_time >= Guarantee_timestamp

Come mostrato nella figura 1, il valore di Guarantee_timestamp è impostato come 2021-08-26T18:15:01, e Graceful_time come 2s. Il valore di Service_timestamp è cresciuto fino a 2021-08-26T18:15:00. Sebbene il valore di Service_timestamp sia ancora inferiore a quello di Guarantee_timestamp e non tutte le operazioni DML prima di 2021-08-26T18:15:01 siano state completate, viene tollerato un periodo di 2 secondi di invisibilità dei dati, come indicato dal valore di Graceful_time. Pertanto, la richiesta di ricerca o di interrogazione in arrivo può essere eseguita immediatamente.

Scenario 2: Service_timestamp + Graceful_time < Guarantee_timestamp

Come mostrato nella figura 2, il valore di Guarantee_timestamp è impostato come 2021-08-26T18:15:01 e Graceful_time come 2s. Il valore attuale di Service_timestamp è solo 2021-08-26T18:14:54. Ciò significa che le operazioni DML previste non sono ancora state completate e che, anche con un tempo di grazia di 2 secondi, l'invisibilità dei dati è ancora intollerabile. Pertanto, il nodo di interrogazione deve rimandare la richiesta di ricerca o di interrogazione fino al completamento di alcune richieste DML (cioè quando Service_timestamp + Graceful_time >= Guarantee_timestamp).

Cosa succede dopo

• Scoprite come il timestamp di garanzia consente di regolare la coerenza in Milvus.