Introduzione
Quando leggi i dati in Spanner in una transazione di sola lettura o in una chiamata singola di lettura, puoi impostare un vincolo di timestamp, che indica a Spanner come scegliere un timestamp in cui leggere i dati.
Perché impostare un vincolo di timestamp? Se il database è distribuito geograficamente (ovvero, hai creato l'istanza Spanner utilizzando una configurazione di istanze su più regioni) e l'applicazione può tollerare un certo periodo di inattività durante la lettura dei dati, puoi ottenere vantaggi in termini di latenza eseguendo una lettura inattiva anziché una lettura efficace. Scopri di più su questi tipi di lettura nella pagina Letture.
Tipi associati al timestamp
I tipi di timestamp associati sono:
- Sicura (impostazione predefinita): consente di leggere i dati più recenti.
- Mancanza limitata: legge una versione dei dati che non è obsoleta di un limite.
- Esatta obsolescenza: leggi la versione dei dati a un timestamp esatto, ad esempio un punto nel passato, anche se puoi specificare un timestamp per un intervallo di tempo non ancora trascorso. Se nel futuro specifichi un timestamp, Spanner attenderà che quel timestamp venga fornito prima di fornire la lettura.
Note:
Anche se le letture che utilizzano queste modalità associate a timestamp non fanno parte di una transazione di lettura-scrittura, possono bloccare l'attesa del commit di transazioni di lettura/scrittura simultanee. Le letture di inattività limitata tentano di scegliere un timestamp per evitare il blocco, ma possono comunque bloccarsi.
Le letture inattive (ovvero l'utilizzo dei tipi di inattività limitata o esatta) offrono il massimo vantaggio in termini di prestazioni negli intervalli di inattività più lunghi. Utilizza un periodo di inattività minimo di 10 secondi per ottenere un vantaggio.
Spanner tiene traccia della classe
earliest_version_timedi un database, specificando il momento in cui è possibile leggere le versioni precedenti dei dati. Non puoi leggere con un timestamp precedente all'ora della versione meno recente.
I tipi di associazioni al timestamp di Spanner sono spiegati in maggiore dettaglio di seguito.
Elevata
Spanner fornisce un tipo di limite per le letture complesse. Sono garantite letture efficaci per vedere gli effetti di tutte le transazioni di cui è stato eseguito il commit 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.
Le letture efficaci non sono ripetibili: due transazioni efficaci consecutive di sola lettura potrebbero restituire risultati incoerenti in caso di scritture simultanee. Se è richiesta coerenza tra le letture, queste devono essere eseguite all'interno della stessa transazione o in corrispondenza di un timestamp di lettura esatto.
Inattività limitata
Spanner fornisce un tipo di limite per il mancato aggiornamento limitato. Le modalità di inattività limitata consentono a Spanner di scegliere il timestamp di lettura, in base a un limite di inattività fornito dall'utente. Spanner sceglie il timestamp più recente entro il limite di inattività che consente l'esecuzione delle letture nella replica più vicina disponibile senza blocchi.
Tutte le righe ricavate sono coerenti tra loro: se una qualsiasi parte della lettura osserva una transazione, tutte le parti della lettura vedono la transazione. Le letture in stato di inattività limitata non sono ripetibili: due letture inattive, anche se utilizzano lo stesso limite di inattività, possono essere eseguite in timestamp diversi e quindi restituire risultati incoerenti.
Le letture di inattività limitata sono in genere un po' più lente rispetto alle letture di inattività esatte comparabili.
Inattività esatta
Spanner fornisce un tipo di limite per il mancato aggiornamento esatto. Questi limiti del timestamp eseguono le letture in un timestamp specificato dall'utente. Le letture a un timestamp sono garantite per vedere un prefisso coerente nella cronologia delle transazioni globale: osservano le modifiche apportate da tutte le transazioni con un timestamp del commit inferiore o uguale al timestamp di lettura e non osservano nessuna delle modifiche apportate dalle transazioni con un timestamp di commit più grande. Verranno bloccati fino al termine di 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 obsolescenza rispetto all'ora attuale.
Queste modalità non richiedono una "fase di negoziazione" per scegliere un timestamp. Di conseguenza, vengono eseguite leggermente più velocemente rispetto alle equivalenti modalità di contemporaneità marginalmente inattiva. D'altra parte, letture marginalmente obsolete di solito restituiscono risultati più aggiornati.
Inattività massima del timestamp
Spanner raccoglie continuamente i dati eliminati e sovrascritti in background per recuperare spazio di archiviazione. Questa procedura è nota come versione
GC. Il GC della versione recupera le versioni dopo che sono scadute dopo la data version_retention_period di un database, che per impostazione predefinita è di 1 ora, ma può essere configurata 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 riescono e generano 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.