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 istanze multiregionali) e la tua applicazione può tollerare un po' di inattività durante la lettura dei dati, puoi ottenere vantaggi in termini di latenza dall'esecuzione di una lettura non aggiornata anziché di una lettura affidabile. Scopri di più su questi tipi di letture in Letture.

Tipi di limiti di timestamp

I tipi di vincolo del timestamp sono:

  • Alto (impostazione predefinita): vengono letti i dati più recenti.
  • Mancata aggiornamento limitata: leggi una versione dei dati che non è più vecchia di un limite.
  • Mancata aggiornamento esatta: leggi la versione dei dati in base a un timestamp esatto, ad esempio un punto nel tempo nel passato, anche se puoi specificare un timestamp per un momento che non è ancora trascorso. Se specifichi un timestamp futuro, Spanner aspetta questo timestamp prima di eseguire la lettura.

Note:

  • Sebbene le letture che utilizzano queste modalità vincolate dal 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 tempo di aggiornamento limitato tentano di scegliere un timestamp per evitare il blocco, ma potrebbero comunque bloccarsi.

  • Le letture non aggiornate (ovvero con tipi di inattualità limitati o esatti) hanno il massimo vantaggio in termini di prestazioni con gli intervalli di inattualità più lunghi. Utilizza un'obsolescenza minima di 10 secondi per ottenere un vantaggio.

  • Spanner tiene traccia del earliest_version_time di un database, che specifica la data e l'ora più antiche in cui è possibile leggere le versioni precedenti dei dati. Non puoi leggere con un timestamp precedente all'ora della versione più antica.

I tipi di limiti di timestamp di Spanner sono descritti più dettagliatamente di seguito.

Elevata

Spanner fornisce un tipo vincolato per le letture sicure. Le letture sicure garantiscono di vedere gli effetti di tutte le transazioni che sono state committate prima dell'inizio della lettura. Inoltre, tutte le righe restituite da una singola lettura sono coerenti tra loro: se una parte della lettura rileva una transazione, tutte le parti della lettura vedono la transazione.

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

Inattività limitata

Spanner fornisce un tipo di limite per l'inattività limitata. Le modalità di invecchiamento limitato consentono a Spanner di scegliere il timestamp di lettura, in base a un limite di invecchiamento fornito dall'utente. Spanner sceglie il timestamp più recente all'interno del limite di inattività che consente l'esecuzione delle letture nella replica disponibile più vicina senza blocco.

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

Le letture con tempo di aggiornamento limitato sono in genere un po' più lente rispetto alle letture con tempo di aggiornamento esatto paragonabili.

Inattività esatta

Spanner fornisce un tipo di limite per l'obsolescenza esatta. Questi limiti di timestamp consentono di eseguire letture in base a un timestamp specificato dall'utente. Le letture con un timestamp garantiscono di vedere un prefisso coerente della cronologia delle transazioni globali: osservano le modifiche apportate da tutte le transazioni con un timestamp di commit inferiore o uguale al timestamp di lettura e non osservano nessuna delle modifiche apportate da le transazioni con un timestamp di commit maggiore. Rimarranno bloccate fino al termine di tutte le transazioni in conflitto a cui possono essere assegnati timestamp di commit minori o uguali al timestamp di lettura.

Il timestamp può essere espresso come timestamp assoluto del commit di Spanner o come stato non aggiornato rispetto all'ora corrente.

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

Inattività massima del timestamp

Spanner esegue continuamente la raccolta dei dati eliminati e sovrascritti in background per recuperare spazio di archiviazione. Questa procedura è nota come versione GC. La rimozione delle versioni recupera le versioni dopo la loro scadenza oltre il version_retention_period di un database, che per impostazione predefinita è 1 ora, ma può essere configurato fino a 1 settimana. Questa limitazione si applica anche alle letture in corso e/o alle query SQL 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 è Lettura/query della partizione con token di partizione, che impedisce la raccolta dei dati scaduti mentre la sessione rimane attiva.