Limiti di timestamp

Introduzione

Durante la lettura dei 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 il timestamp in cui leggere i dati.

Perché impostare un limite di timestamp? Se il database è distribuito geograficamente (ovvero se hai creato l'istanza Spanner utilizzando una configurazione dell'istanza multiregionale) e l'applicazione è in grado di tollerare un certo livello di inattività durante la lettura dei dati, puoi usufruire di vantaggi in termini di latenza eseguendo una lettura inattiva anziché una lettura efficace. Scopri di più su questi tipi di lettura in Letture.

Tipi di limiti di timestamp

I tipi di timestamp associati sono:

  • Forte (impostazione predefinita): consente di leggere i dati più recenti.
  • Inattività limitata: viene letta una versione dei dati che non è più aggiornata di un limite.
  • Idoneità esatta: leggi la versione dei dati in corrispondenza di un timestamp esatto, ad esempio un momento passato, sebbene sia possibile specificare un timestamp per un'ora non ancora trascorsa. Se specifichi un timestamp in futuro, Spanner atterrà quel timestamp prima di fornire la lettura.

Note

  • Sebbene le letture utilizzando queste modalità associate al timestamp non facciano parte di una transazione di lettura e scrittura, possono bloccare l'attesa del commit di transazioni di lettura e scrittura simultanee. Le letture di inattività limitate tentano di scegliere un timestamp per evitare blocchi, ma possono comunque bloccarsi.

  • Le letture inattive (ovvero l'utilizzo di tipi di inattività limitati o esatti) offrono il massimo vantaggio in termini di prestazioni agli intervalli di inattività più lunghi. Utilizza un minimo di inattività di 10 secondi per ottenere un vantaggio.

  • Spanner tiene traccia dell'elemento earliest_version_time di un database, che specifica il momento in cui è possibile leggere le versioni precedenti dei dati. Non puoi leggere in un timestamp precedente alla data e ora della prima versione.

I tipi di associazione dei timestamp di Spanner sono spiegati in modo più dettagliato di seguito.

Elevata

Spanner fornisce un tipo associato per letture complesse. Le letture efficaci sono garantite per vedere gli effetti di tutte le transazioni eseguite prima dell'inizio della lettura. Inoltre, tutte le righe generate da una singola lettura sono coerenti tra loro: se una qualsiasi parte della lettura osserva una transazione, tutte le parti della lettura vedono la transazione.

Letture efficaci non sono ripetibili: due transazioni di sola lettura efficaci consecutive potrebbero restituire risultati incoerenti in presenza di scritture simultanee. Se è richiesta la coerenza tra le letture, queste devono essere eseguite all'interno della stessa transazione o in un timestamp di lettura esatto.

Inattività limitata

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

Tutte le righe prodotte sono coerenti tra loro: se una qualsiasi parte della lettura osserva una transazione, tutte le parti della lettura visualizzano la transazione. Le letture inattive del limite non sono ripetibili: due letture inattive, anche se utilizzano lo stesso limite di inattività, possono essere eseguite con timestamp diversi e quindi restituire risultati incoerenti.

Le letture di inattività limitate sono in genere un po' più lente rispetto alle letture di inattività esatte comparabili.

Inattività esatta

Spanner fornisce un tipo associato per l'esatta inattività. Questi limiti di timestamp eseguono le letture in un timestamp specificato dall'utente. Le letture in un timestamp garantiscono un prefisso coerente della cronologia delle transazioni globale: 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 dalle transazioni con un timestamp di commit più grande. Saranno bloccati fino al termine di tutte le transazioni in conflitto a cui possono 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 rispetto all'ora attuale.

Queste modalità non richiedono una "fase di negoziazione" per la scelta di un timestamp. Di conseguenza, vengono eseguite leggermente più velocemente rispetto alle modalità di contemporaneità dellimitate equivalenti. D'altra parte, le letture inattive e limitate in genere restituiscono risultati più aggiornati.

Livello massimo di inattività del timestamp

Spanner elimina costantemente i dati eliminati e sovrascritti in background per recuperare spazio di archiviazione. Questa procedura è nota come versione GC. La versione di GC recupera le versioni dopo la scadenza dopo la version_retention_period di un database, che per impostazione predefinita è di 1 ora, ma può essere configurata fino a una 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 viene restituito l'errore FAILED_PRECONDITION. L'unica eccezione è la lettura partizione/query con token di partizione, che impediscono la garbage collection dei dati scaduti mentre la sessione rimane attiva.