Limiti di timestamp

Introduzione

Durante la lettura dei dati in Spanner in una transazione di sola lettura o 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 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 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ù obsoleta 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/scrittura eseguire il commit. Le letture di inattività limitate tentano di scegliere un timestamp per evitare blocchi. ma potrebbe bloccarsi.

  • Le letture inattive (ovvero utilizzando i tipi di inattività limitate o esatte) hanno il massimo in termini di prestazioni con intervalli di inattività più lunghi. Utilizza un livello di inattività minimo 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 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.

Letture efficaci non ripetibili: due transazioni di sola lettura efficaci consecutive potrebbe restituire risultati incoerenti in presenza di scritture simultanee. Se sono coerenti tutte le letture è obbligatoria, le letture devono essere eseguite all'interno dello stesso transazione o a un timestamp di lettura esatto.

Inattività limitata

Spanner fornisce un tipo associato 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. Limitato letture obsolete non sono ripetibili: due letture non aggiornate, anche se utilizzano stesso limite di inattività, possono essere eseguiti con timestamp diversi e quindi restituiscono 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 associato per l'esatta inattività. 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. Vengono bloccati finché non vengono transazioni in conflitto a cui possono essere assegnati timestamp di commit inferiori o uguali al timestamp di lettura.

Il timestamp può essere espresso come commit Spanner assoluto un timestamp o un ritardo 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 limitate inattive di solito restituiscono risultati più recenti.

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 Garbage Collection. 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 è 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.