Limiti di timestamp

Introduzione

Quando leggi i dati in Spanner in una transazione di sola lettura o in una singola chiamata di lettura, puoi impostare un limite di timestamp, che indica a Spanner come scegliere un timestamp in cui leggere i dati.

Perché impostare un limite di timestamp? Se il tuo database è distribuito geograficamente (ovvero hai creato l'istanza Spanner utilizzando una configurazione di istanza multiregionale) e la tua applicazione può tollerare una certa obsolescenza durante la lettura dei dati, puoi ottenere vantaggi in termini di latenza eseguendo una lettura obsoleta anziché una lettura coerente. Scopri di più su questi tipi di lettura in Letture.

Tipi di limiti di timestamp

I tipi di limite di timestamp sono:

  • Forte (impostazione predefinita): legge i dati più recenti.
  • Stalezza limitata: leggi una versione dei dati non più obsoleta di un limite.
  • Stalezza esatta: leggi la versione dei dati in un timestamp esatto, ad esempio un momento nel passato, anche se puoi specificare un timestamp per un momento non ancora trascorso. Se specifichi un timestamp futuro, Spanner attenderà quel timestamp prima di pubblicare la lettura.

Note:

  • Sebbene le letture che utilizzano queste modalità con limiti di timestamp non facciano parte di una transazione di lettura/scrittura, possono bloccare l'attesa del commit delle transazioni di lettura/scrittura simultanee. Le letture con obsolescenza limitata tentano di scegliere un timestamp per evitare il blocco, ma potrebbero comunque bloccare.

  • Le letture non aggiornate (ovvero l'utilizzo dei tipi di non aggiornamento esatto o limitato) offrono il massimo vantaggio in termini di prestazioni agli intervalli di non aggiornamento più lunghi. Utilizza un valore minimo di obsolescenza di 10 secondi per ottenere un vantaggio.

  • Spanner tiene traccia del earliest_version_time di un database, che specifica l'ora più recente in cui è possibile leggere le versioni precedenti dei dati. Non puoi leggere a un timestamp precedente all'ora della versione meno recente.

I tipi di limiti temporali di Spanner sono spiegati in dettaglio in un secondo momento.

Elevata

Spanner fornisce un tipo di limite per le letture coerenti. Le letture coerenti hanno la garanzia di vedere gli effetti di tutte le transazioni di cui è stato eseguito il commit prima dell'inizio della lettura. Inoltre, tutte le righe restituite da una singola lettura sono coerenti tra loro: se una parte della lettura osserva una transazione, tutte le parti della lettura vedono la transazione.

Le letture coerenti non sono ripetibili: due transazioni di sola lettura coerenti consecutive potrebbero restituire risultati incoerenti se sono presenti scritture simultanee. Se è necessaria la coerenza tra le letture, queste devono essere eseguite all'interno della stessa transazione o a un timestamp di lettura esatto.

Inattività limitata

Spanner fornisce un tipo di limite per l'obsolescenza limitata. Le modalità di obsolescenza limitata consentono a Spanner di scegliere il timestamp di lettura, soggetto a un limite di obsolescenza fornito dall'utente. Spanner sceglie il timestamp più recente entro il limite di obsolescenza che consente l'esecuzione delle letture nella replica disponibile più vicina senza blocchi.

Tutte le righe restituite sono coerenti tra loro: se una parte della lettura osserva una transazione, tutte le parti della lettura vedono la transazione. Le letture obsolete con limiti non sono ripetibili: due letture obsolete, anche se utilizzano lo stesso limite di obsolescenza, possono essere eseguite in timestamp diversi e quindi restituire risultati incoerenti.

Le letture con obsolescenza limitata sono in genere un po' più lente rispetto alle letture con obsolescenza esatta comparabili.

Inattività esatta

Spanner fornisce un tipo di limite per la non aggiornamento esatto. Questi limiti del timestamp eseguono letture a un timestamp specificato dall'utente. Le letture a un timestamp garantiscono di visualizzare un prefisso coerente della cronologia delle transazioni globali: osservano le modifiche apportate da tutte le transazioni con un timestamp di commit minore o uguale al timestamp di lettura e non osservano nessuna delle modifiche apportate dalle transazioni con un timestamp di commit maggiore. Verranno bloccate finché non saranno terminate tutte le transazioni in conflitto a cui potrebbero essere assegnati timestamp di commit inferiori o uguali al timestamp di lettura.

Il timestamp può essere espresso come timestamp di commit Spanner assoluto o come obsolescenza relativa all'ora corrente.

Queste modalità non richiedono una "fase di negoziazione" per scegliere un timestamp. Di conseguenza, vengono eseguiti leggermente più velocemente rispetto alle modalità di concorrenza boundedly stale equivalenti. D'altra parte, le letture con obsolescenza limitata di solito restituiscono risultati più recenti.

Livello massimo di inattività del timestamp

Spanner esegue continuamente la garbage collection dei dati eliminati e sovrascritti in background per recuperare spazio di archiviazione. Questa procedura è nota come GC delle versioni. La garbage collection delle versioni recupera le versioni dopo la scadenza oltre il valore di version_retention_period di un database, che per impostazione predefinita è di 1 ora, ma può essere configurato fino a 1 settimana. Questa limitazione si applica anche alle letture e/o alle query SQL in corso il cui timestamp diventa troppo vecchio durante l'esecuzione. Le letture e le query SQL con timestamp di lettura troppo vecchi non vanno a buon fine e restituiscono l'errore FAILED_PRECONDITION. L'unica eccezione è Partition Read/Query con token di partizione, che impedirà la garbage collection dei dati scaduti mentre la sessione rimane attiva.