Conservazione dei dati con spostamento cronologico e fail-safe
Questo documento descrive le finestre di conservazione dei dati spostamento cronologico e fail-safe per i set di dati. Durante i periodi di spostamento cronologico e fail-safe, i dati modificati o eliminati in qualsiasi tabella del set di dati continuano a essere archiviati nel caso in cui sia necessario recuperarli.
Spostamento cronologico e conservazione dei dati
Puoi accedere ai dati modificati o eliminati da qualsiasi punto all'interno della finestra di spostamento cronologico, che per impostazione predefinita copre gli ultimi sette giorni. Lo spostamento cronologico ti consente di eseguire query sui dati aggiornati o eliminati, ripristinare una tabella o un set di dati eliminato, ripristinare una tabella scaduta, o ripristinare una tabella a un momento specifico.
Puoi impostare la durata della finestra di spostamento cronologico, da un minimo di due giorni a un massimo di sette giorni. Una finestra di spostamento cronologico più lunga è utile nei casi in cui è importante poter recuperare i dati aggiornati o eliminati. Una finestra di spostamento cronologico più breve consente di risparmiare sui costi di archiviazione quando si utilizza il modello di fatturazione dello spazio di archiviazione fisico. Questi risparmi non si applicano quando si utilizza il modello di fatturazione dello spazio di archiviazione logico. Per ulteriori informazioni su come il modello di fatturazione dello spazio di archiviazione influisce sui costi, consulta Fatturazione. Non puoi impostare la durata dello spostamento cronologico per meno di 2 giorni.
Configurare la finestra di spostamento cronologico
Imposta la finestra di spostamento cronologico a livello di set di dati o di progetto. Queste impostazioni vengono quindi applicate a tutte le tabelle associate al set di dati o al progetto.
Impostare la finestra di spostamento cronologico a livello di progetto
Per specificare la finestra di spostamento cronologico predefinita a livello di progetto, puoi utilizzare le istruzioni del Data Definition Language (DDL). Per scoprire come impostare la finestra di spostamento cronologico a livello di progetto, consulta Gestire le impostazioni di configurazione.
Impostare la finestra di spostamento cronologico a livello di set di dati
Per specificare o modificare la finestra di spostamento cronologico per un set di dati, puoi utilizzare la Google Cloud console, lo strumento a riga di comando bq o l'API BigQuery.
- Per specificare la finestra di spostamento cronologico predefinita per i nuovi set di dati, consulta Creare set di dati.
- Per modificare o aggiornare la finestra di spostamento cronologico per un set di dati esistente, consulta Aggiornare le finestre di spostamento cronologico.
Quando modifichi una finestra di spostamento cronologico, se il timestamp specifica un'ora al di fuori della finestra di spostamento cronologico o precedente alla creazione della tabella, la query non riesce e restituisce un errore simile al seguente:
TableIDwas created at time which is before its allowed time travel intervaltimestamp. Creation time:timestamp
Come funziona lo spostamento cronologico
BigQuery utilizza un formato di archiviazione colonnare. Ciò significa che i dati sono organizzati e archiviati per colonna anziché per riga. Quando hai una tabella con più colonne, i valori di ogni colonna in tutte le righe vengono archiviati insieme nei blocchi di archiviazione.
Quando modifichi una cella in una tabella BigQuery, stai modificando un valore specifico all'interno di una riga e di una colonna specifiche. Poiché BigQuery archivia le colonne insieme, la modifica anche di una singola cella all'interno di una colonna in genere richiede la lettura dell'intero blocco di archiviazione contenente i dati della colonna per le righe interessate, l'applicazione della modifica e la scrittura di una nuova versione del blocco di archiviazione.
La funzionalità di spostamento cronologico funziona monitorando le versioni dei blocchi di archiviazione che compongono la tabella. Quando aggiorni i dati, BigQuery non modifica semplicemente il blocco di archiviazione esistente. Crea invece una nuova versione dei blocchi di archiviazione interessati con i dati aggiornati. La versione precedente viene quindi conservata per lo spostamento cronologico.
BigQuery utilizza blocchi di archiviazione e dimensioni dei file adattivi. La dimensione dei blocchi di archiviazione non è fissa, ma può variare a seconda di fattori quali la dimensione della tabella e la distribuzione dei dati. La modifica anche di una sola cella in un blocco di archiviazione modifica i dati della colonna, potenzialmente interessando molte righe. Pertanto, l'unità di dati con controllo delle versioni e inviata allo spostamento cronologico è spesso l'intero blocco di archiviazione che contiene i dati modificati della colonna, non solo una singola cella.
Per questo motivo, la modifica di una cella può comportare l'invio di più dati allo spostamento cronologico rispetto alla sola dimensione della modifica.
In che modo la finestra di spostamento cronologico influisce sul recupero di tabelle e set di dati
Una tabella o un set di dati eliminato utilizza la durata della finestra di spostamento cronologico in vigore al momento dell'eliminazione.
Ad esempio, se la durata della finestra di spostamento cronologico è di due giorni e poi la aumenti a sette giorni, le tabelle eliminate prima di questa modifica sono recuperabili solo per due giorni. Allo stesso modo, se la durata della finestra di spostamento cronologico è di cinque giorni e la riduci a tre giorni, tutte le tabelle eliminate prima della modifica sono comunque recuperabili per cinque giorni.
Poiché le finestre di spostamento cronologico sono impostate a livello di set di dati, non puoi modificare la finestra di spostamento cronologico di un set di dati eliminato finché non viene annullata l'eliminazione.
Se riduci la durata della finestra di spostamento cronologico, elimini una tabella e poi ti rendi conto di aver bisogno di un periodo di recuperabilità più lungo per questi dati, puoi creare uno snapshot della tabella da un momento precedente all'eliminazione della tabella. Devi farlo mentre la tabella eliminata è ancora recuperabile. Per ulteriori informazioni, consulta Creare uno snapshot di una tabella utilizzando lo spostamento cronologico.
Spostamento cronologico e accesso a livello di riga
Se una tabella ha o ha avuto policy di accesso a livello di riga, solo un'entità a cui è stata concessa la seguente autorizzazione Identity and Access Management (IAM) può accedere ai dati storici della tabella:
| Autorizzazione | Risorsa |
|---|---|
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions
|
La tabella di cui si sta accedendo ai dati storici |
I seguenti ruoli IAM predefiniti forniscono l'autorizzazione bigquery.rowAccessPolicies.overrideTimeTravelRestrictions:
| Ruolo | Risorsa |
|---|---|
roles/bigquery.admin
|
La tabella di cui si sta accedendo ai dati storici |
roles/bigquery.studioAdmin
|
La tabella di cui si sta accedendo ai dati storici |
roles/iam.databasesAdmin
|
La tabella di cui si sta accedendo ai dati storici |
Puoi anche concedere
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions
l'autorizzazione utilizzando un ruolo personalizzato.
Esegui il seguente comando per ottenere l'ora equivalente dell'epoca di Unix passando il timestamp UTC:
date -d '2023-08-04 16:00:34.456789Z' +%s000
Sostituisci l'ora Unix epoch
1691164834000ricevuta dal comando precedente nello strumento a riga di comando bq. Esegui il seguente comando per ripristinare una copia della tabella eliminatadeletedTableIDin un'altra tabellarestoredTable, all'interno dello stesso set di datimyDatasetID:bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable
Fail-safe
BigQuery fornisce un periodo di fail-safe. Durante il periodo di fail-safe, i dati eliminati vengono conservati automaticamente per altri sette giorni dopo la finestra di spostamento cronologico, in modo che siano disponibili per il recupero di emergenza. I dati sono recuperabili a livello di tabella dal momento rappresentato dal timestamp di quando sono stati eliminati.
Il periodo di fail-safe non è configurabile e non può essere esteso. Devi avviare e completare il recupero della tabella prima della scadenza del periodo di fail-safe di sette giorni, lasciando un tempo sufficiente per il completamento del job di copia in base alle dimensioni della tabella.
Quando esegui le seguenti operazioni, i dati sostituiti o rimossi possono essere recuperati tramite la finestra di spostamento cronologico. Al termine della finestra di spostamento cronologico, questi dati entrano nel periodo di fail-safe per un tempo di recupero esteso:
-
Eliminazione o sostituzione della tabella: quando una tabella viene eliminata o quando i relativi dati vengono sostituiti completamente (ad esempio, utilizzando la disposizione di scrittura
WRITE_TRUNCATEin un job di caricamento o utilizzando l'istruzioneCREATE OR REPLACE TABLE), i contenuti precedenti della tabella vengono conservati. - Eliminazione o scadenza della partizione: se una partizione specifica viene eliminata o scade da una tabella partizionata, i dati appartenenti a quella partizione specifica vengono conservati. Le altre partizioni della tabella non sono interessate. Poiché non puoi ripristinare una singola partizione, devi ripristinare l'intera tabella da un timestamp precedente all'eliminazione o alla scadenza della partizione. Se la tabella originale ha una scadenza della partizione, questa impostazione viene copiata nella tabella ripristinata. Per eseguire query sulle partizioni ripristinate precedenti all'ora di scadenza della partizione, aggiorna la scadenza della partizione nella tabella ripristinata.
Recuperare i dati dallo spazio di archiviazione fail-safe
Non puoi eseguire query sui dati nello spazio di archiviazione fail-safe direttamente e non puoi copiare una tabella
dallo spazio di archiviazione fail-safe finché l'assistenza clienti Google Cloud
non concede l'accesso temporaneo al recupero fail-safe sul set di dati. Per recuperare una tabella
dallo spazio di archiviazione fail-safe, contatta l'assistenza clienti Google Cloud
per richiedere l'accesso al recupero fail-safe per il tuo set di dati, quindi
ripristina la tabella
eseguendo un job di copia della tabella con un decoratore di timestamp @TIME.
A differenza del recupero dello spostamento cronologico, che aggiorna solo i puntatori dei metadati, il recupero fail-safe deve ripristinare e replicare fisicamente i blocchi di archiviazione archiviati prima del completamento del job di copia della tabella. Quando ripristini una tabella di grandi dimensioni o con molte partizioni dallo spazio di archiviazione fail-safe, tieni presente i seguenti comportamenti:
- Tempi di copia e timeout più lunghi: il ripristino di una tabella di più terabyte o di una tabella con molte partizioni dallo spazio di archiviazione fail-safe può richiedere molto più tempo rispetto a una copia standard della tabella. Un singolo job di copia potrebbe andare in timeout o non riuscire a causa di un errore interno temporaneo prima del ripristino di tutti i blocchi di archiviazione.
- Avanzamento incrementale tra i tentativi: l'avanzamento del ripristino fail-safe viene salvato in modo incrementale. Tutti i blocchi di archiviazione ripristinati prima che un job di copia vada in timeout o non riesca rimangono ripristinati. Se un comando
bq cpnon riesce, riprova a eseguire il comando utilizzando la stessa tabella di origine e il@TIMEdecoratore di timestamp. Ogni tentativo salta i blocchi già ripristinati e continua a ripristinare i dati rimanenti fino al completamento del job di copia. - Finestra di recupero sensibile al tempo: contatta l'assistenza clienti Google Cloud il prima possibile entro il periodo di fail-safe di sette giorni, soprattutto per le tabelle di grandi dimensioni, in modo da avere tempo sufficiente per eseguire i tentativi prima della scadenza del periodo di fail-safe.
Fatturazione
Se imposti il tuo modello di fatturazione dello spazio di archiviazione in modo che utilizzi i byte fisici, ti viene addebitato un costo separato per i byte utilizzati per lo spostamento cronologico e lo spazio di archiviazione fail-safe. Lo spazio di archiviazione per lo spostamento cronologico e il fail-safe viene addebitato alla tariffa dello spazio di archiviazione fisico attivo. Puoi configurare la finestra di spostamento cronologico per bilanciare i costi di archiviazione con le tue esigenze di conservazione dei dati.
Se imposti il modello di fatturazione dello spazio di archiviazione in modo che utilizzi i byte logici, i costi totali di archiviazione per lo spostamento cronologico e lo spazio di archiviazione fail-safe sono inclusi nella tariffa base addebitata.
La tabella seguente mostra un confronto tra i costi di archiviazione fisica e logica:
| Modello di fatturazione | Cosa paghi? |
|---|---|
| Spazio di archiviazione fisico (compresso) |
|
| Spazio di archiviazione logico (non compresso) (impostazione predefinita) |
|
Se utilizzi lo spazio di archiviazione fisico, puoi visualizzare i byte utilizzati dallo spostamento cronologico e
dal fail-safe esaminando le colonne TIME_TRAVEL_PHYSICAL_BYTES e
FAIL_SAFE_PHYSICAL_BYTES nelle visualizzazioni
TABLE_STORAGE e
TABLE_STORAGE_BY_ORGANIZATION. Per un esempio di come utilizzare una di queste visualizzazioni per stimare i costi,
consulta
Prevedere la fatturazione dello spazio di archiviazione.
I costi di archiviazione si applicano ai dati di spostamento cronologico e fail-safe data, ma ti viene addebitato un costo solo se le tariffe di archiviazione dei dati non si applicano altrove in BigQuery. Si applicano i seguenti dettagli:
- Quando viene creata una tabella, non sono previsti costi di archiviazione per lo spostamento cronologico o il fail-safe.
- Se i dati vengono modificati o eliminati, ti viene addebitato il costo dell'archiviazione dei dati modificati o eliminati salvati dallo spostamento cronologico durante la finestra di spostamento cronologico e il periodo di fail-safe. Questo è simile ai prezzi di archiviazione per gli snapshot e i cloni delle tabelle.
- Le tabelle temporanee non vengono fatturate per lo spazio di archiviazione fail-safe.
Esempio di conservazione dei dati
La tabella seguente mostra come i dati eliminati o modificati si spostano tra le finestre di conservazione dello spazio di archiviazione. Questo esempio mostra una situazione in cui lo spazio di archiviazione attivo totale è di 200 GiB e 50 GiB vengono eliminati con una finestra di spostamento cronologico di sette giorni:
| Giorno 0 | Giorno 1 | Giorno 2 | Giorno 3 | Giorno 4 | Giorno 5 | Giorno 6 | Giorno 7 | Giorno 8 | Giorno 9 | Giorno 10 | Giorno 11 | Giorno 12 | Giorno 13 | Giorno 14 | Giorno 15 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Spazio di archiviazione attivo | 200 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 |
| Spazio di archiviazione per lo spostamento cronologico | 50 | 50 | 50 | 50 | 50 | 50 | 50 | |||||||||
| Spazio di archiviazione fail-safe | 50 | 50 | 50 | 50 | 50 | 50 | 50 |
L'eliminazione dei dati dallo spazio di archiviazione fisico a lungo termine funziona allo stesso modo.
Limitazioni
Il recupero dei dati con lo spostamento cronologico è soggetto alle seguenti limitazioni:
- Lo spostamento cronologico fornisce l'accesso ai dati storici solo per la durata della finestra di spostamento cronologico. Per conservare i dati delle tabelle per scopi non di emergenza per un periodo più lungo della finestra di spostamento cronologico, utilizza gli snapshot delle tabelle.
- Se una tabella ha o ha avuto in precedenza policy di accesso a livello di riga, lo spostamento cronologico può essere utilizzato solo dagli amministratori della tabella. Per ulteriori informazioni, consulta Spostamento cronologico e accesso a livello di riga.
- Lo spostamento cronologico non ripristina i metadati della tabella.
- Lo spostamento cronologico non è supportato nei seguenti tipi di tabelle:
- Tabelle esterne. Tuttavia, per
le tabelle esterne Apache Iceberg, puoi utilizzare la
FOR SYSTEM_TIME AS OFclausola per accedere agli snapshot conservati nei metadati di Iceberg. - Tabelle dei risultati delle query memorizzate nella cache temporanea.
- Tabelle di sessione temporanee.
- Tabelle temporanee con più istruzioni.
- Tabelle elencate in set di dati esterni.
- Tabelle esterne. Tuttavia, per
le tabelle esterne Apache Iceberg, puoi utilizzare la
Passaggi successivi
- Scopri come eseguire query e recuperare i dati di spostamento cronologico.
- Scopri di più sugli snapshot delle tabelle.