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 a cui leggere i dati.

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

Tipi di limiti di timestamp

I tipi di vincolo del timestamp 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 a momento nel passato, anche se puoi specificare il timestamp per un'ora non è ancora passato. (se specifichi un timestamp in futuro, Spanner attenderà quel timestamp prima di fornire la lettura.)

Note:

  • Anche se le letture utilizzando queste modalità associate al timestamp non fanno parte di un sistema di lettura/scrittura transazione, possono bloccare l'attesa di transazioni simultanee di lettura e scrittura eseguire il commit. 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 livello di inattività minimo 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 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 associato per letture complesse. Le letture pesanti sono vedere gli effetti di tutte le transazioni eseguite prima l'inizio della lettura. Inoltre, tutte le righe prodotte da una singola lettura sono coerenti tra loro: se una qualsiasi parte della lettura osserva una transazione, tutte le parti lettura e visualizzazione della 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 vincolo per l'inattività limitata. Inattività limitata consentono a Spanner di scegliere il timestamp di lettura, in base all'input dell'utente fornito il limite di inattività. Spanner sceglie il timestamp più recente tra il limite di inattività che consente l'esecuzione delle letture più vicino possibile senza bloccare la replica.

Tutte le righe prodotte sono coerenti tra loro, se in qualsiasi parte del codice osserva una transazione, tutte le parti della lettura vedono la transazione. Le letture con limiti di устарелость non sono ripetibili: due letture obsolete, anche se utilizzano lo stesso limite di устарелость, possono essere eseguite in timestamp diversi e quindi restituire risultati incoerenti.

Le letture di inattività limitate sono in genere un po' più lente rispetto a quelle esatte paragonabili letture di inattività.

Inattività esatta

Spanner fornisce un tipo di limite per l'obsolescenza esatta. Questi timestamp i limiti eseguono le letture in base a un timestamp specificato dall'utente. Le letture in un timestamp sono la cronologia delle transazioni globale prevede un prefisso coerente nella cronologia delle transazioni osserva le modifiche eseguite da tutte le transazioni con un timestamp di commit inferiore a o uguale al timestamp di lettura e non osservare nessuna delle modifiche apportate transazioni con timestamp di commit più grande. 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 commit Spanner assoluto un timestamp o un'inattività rispetto all'ora corrente.

Queste modalità non richiedono una "fase di negoziazione" per scegliere un timestamp. Come vengono eseguiti leggermente più velocemente rispetto all'equivalente e diverse modalità di contemporaneità. 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 è diventato troppo vecchio durante l'esecuzione. Legge e query SQL con i timestamp di lettura troppo vecchi non riescono e generano l'errore FAILED_PRECONDITION. L'unico è un'eccezione Lettura partizione/query con di partizione, che impediscono la garbage collection dei dati scaduti la sessione rimane attiva.