Datenaufbewahrung mit Zeitreisen und Ausfallsicherheit

In diesem Dokument werden die Zeitreisen und die Fail-Safe-Datenaufbewahrungsfenster für Datasets beschrieben. Während der Zeitreise- und der Fail-Safe-Perioden werden Daten, die Sie in einer beliebigen Tabelle im Dataset geändert oder gelöscht haben, weiterhin gespeichert, falls Sie sie wiederherstellen müssen.

Zeitreisen und Datenaufbewahrung

Sie können auf geänderte oder gelöschte Daten zu jeder Zeit innerhalb des Zeitreisefensters zugreifen, das standardmäßig die letzten sieben Tage abdeckt. Sie können mit Zeitreisen Daten abfragen, die aktualisiert oder gelöscht wurden, eine gelöschte Tabelle oder einen gelöschten Datensatz oder eine abgelaufene Tabelle wiederherstellen oder eine Tabelle zu einem bestimmten Zeitpunkt wiederherstellen.

Sie können die Dauer des Zeitreisefensters von mindestens zwei Tagen auf maximal sieben Tage festlegen. Ein längeres Zeitreisefenster ist nützlich, wenn es wichtig ist, aktualisierte oder gelöschte Daten wiederherstellen zu können. Bei Verwendung eines kürzeren Zeitreisefensters können Sie unter Verwendung des Abrechnungsmodells für physische Speicher Speicherkosten sparen. Diese Einsparungen gelten nicht für die Verwendung des Abrechnungsmodells für logischen Speicher. Weitere Informationen dazu, wie sich das Speicherabrechnungsmodell auf die Kosten auswirkt, finden Sie unter Abrechnung. Sie können die Dauer der Zeitreise nicht auf weniger als zwei Tage festlegen.

Fenster für Zeitreise konfigurieren

Sie legen das Zeitreisefenster auf Dataset- oder Projektebene fest. Diese Einstellungen gelten dann für alle Tabellen, die mit dem Dataset oder Projekt verknüpft sind.

Zeitreisefenster auf Projektebene festlegen

Mit DDL-Anweisungen (Data Definition Language) können Sie das Standardzeitreisefenster auf Projektebene angeben. Informationen zum Festlegen des Zeitreisefensters auf Projektebene finden Sie unter Konfigurationseinstellungen verwalten.

Zeitreisefenster auf Dataset-Ebene festlegen

Sie können die Google Cloud Console, das bq-Befehlszeilentool oder die BigQuery API verwenden, um das Zeitreisefenster für ein Dataset anzugeben oder zu ändern.

  • Informationen zum Festlegen des Standardzeitreisefensters für neue Datasets finden Sie unter Datasets erstellen.
  • Informationen zum Ändern oder Aktualisieren des Zeitreisefensters für ein vorhandenes Dataset finden Sie unter Zeitreisefenster aktualisieren.

Wenn Sie ein Zeitreisefenster ändern und der Zeitstempel eine Zeit außerhalb des Zeitreisefensters oder vor dem Erstellen der Tabelle angibt, schlägt die Abfrage fehl und gibt einen Fehler wie den folgenden zurück:

Table ID was created at time which is
before its allowed time travel interval timestamp. Creation
time: timestamp

Funktionsweise von Zeitreisen

BigQuery verwendet ein spaltenbasiertes Speicherformat. Das bedeutet, dass Daten nach Spalten und nicht nach Zeilen organisiert und gespeichert werden. Wenn Sie eine Tabelle mit mehreren Spalten haben, werden die Werte für jede Spalte in allen Zeilen zusammen in Speicherblöcken gespeichert.

Wenn Sie eine Zelle in einer BigQuery-Tabelle ändern, ändern Sie einen bestimmten Wert in einer bestimmten Zeile und einer bestimmten Spalte. Da BigQuery Spalten zusammen speichert, muss zum Ändern einer einzelnen Zelle in einer Spalte in der Regel der gesamte Speicherblock mit den Daten dieser Spalte für die betroffenen Zeilen gelesen, die Änderung angewendet und dann eine neue Version dieses Speicherblocks geschrieben werden.

Die Zeitreisefunktion verfolgt die Versionen der Speicherblöcke, aus denen Ihre Tabelle besteht. Wenn Sie Daten aktualisieren, ändert BigQuery nicht einfach den vorhandenen Speicherblock. Stattdessen wird eine neue Version der betroffenen Speicherblöcke mit den aktualisierten Daten erstellt. Die vorherige Version wird dann für Zeitreisen aufbewahrt.

BigQuery verwendet adaptive Dateigrößen und Speicherblöcke. Die Größe der Speicherblöcke ist nicht festgelegt, sondern kann je nach Faktoren wie der Größe der Tabelle und der Datenverteilung variieren. Wenn Sie auch nur eine Zelle in einem Speicherblock ändern, werden die Daten für diese Spalte geändert, was sich möglicherweise auf viele Zeilen auswirkt. Daher ist die Dateneinheit, die versioniert und an die Zeitreise gesendet wird, oft der gesamte Speicherblock, der die geänderten Daten dieser Spalte enthält, und nicht nur eine einzelne Zelle.

Aus diesem Grund kann das Ändern einer Zelle dazu führen, dass mehr Daten an die Zeitreise gesendet werden als nur die Größe der Änderung.

Wie sich das Fenster für die Zeitreise auf die Tabellen- und Dataset-Wiederherstellung auswirkt

Eine gelöschte Tabelle oder ein gelöschtes Dataset verwendet die zur Zeit des Löschvorgangs gültige Zeitfensterdauer.

Wenn Sie beispielsweise eine Zeitreisefenster von zwei Tagen haben und die Dauer dann auf sieben Tage erhöhen, können Tabellen, die vor dieser Änderung gelöscht wurden, weiterhin nur für zwei Tage wiederhergestellt werden. Wenn Sie ein Zeitreisefenster von fünf Tagen haben und diese Dauer auf drei Tage reduzieren, können Tabellen, die vor der Änderung gelöscht wurden, weiterhin fünf Tage lang wiederhergestellt werden.

Da Zeitreisefenster auf Dataset-Ebene festgelegt werden, können Sie das Zeitreisefenster eines gelöschten Datasets erst ändern, wenn es wiederhergestellt wurde.

Wenn Sie die Dauer des Zeitreisefensters reduzieren, eine Tabelle löschen und dann feststellen, dass Sie eine längere Wiederherstellungsbarkeit für diese Daten benötigen, können Sie einen Snapshot der Tabelle zu einem Zeitpunkt vor dem Löschen der Tabellen erstellen. Dies muss erfolgen, während die gelöschte Tabelle noch wiederhergestellt werden kann. Weitere Informationen finden Sie unter Tabellen-Snapshot mit Zeitreisen erstellen.

Zeitreisen und Zugriff auf Zeilenebene

Wenn eine Tabelle Zugriffsrichtlinien auf Zeilenebene hat oder hatte, kann nur ein Hauptkonto, dem die folgende IAM-Berechtigung (Identity and Access Management) gewährt wurde, auf Verlaufsdaten für die Tabelle zugreifen:

Berechtigung Ressource
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions Die Tabelle, auf deren Verlaufsdaten zugegriffen wird

Die folgenden vordefinierten IAM-Rollen bieten die Berechtigung bigquery.rowAccessPolicies.overrideTimeTravelRestrictions:

Rolle Ressource
roles/bigquery.admin Die Tabelle, auf deren Verlaufsdaten zugegriffen wird
roles/bigquery.studioAdmin Die Tabelle, auf deren Verlaufsdaten zugegriffen wird
roles/iam.databasesAdmin Die Tabelle, auf deren Verlaufsdaten zugegriffen wird

Sie können auch die Berecht101igungbigquery.rowAccessPolicies.overrideTimeTravelRestrictions mit einer benutzerdefinierten Rolle gewähren.

  • Führen Sie den folgenden Befehl aus, um die entsprechende Unix-Epochenzeit abzurufen, indem Sie den UTC-Zeitstempel übergeben:

    date -d '2023-08-04 16:00:34.456789Z' +%s000

  • Ersetzen Sie die UNIX-Epochenzeit 1691164834000, die vom vorherigen Befehl im bq-Befehlszeilentool erhalten wurde. Führen Sie folgenden Befehl aus, um eine Kopie der gelöschten Tabelle deletedTableID in einer anderen Tabelle restoredTable innerhalb desselben Datasets myDatasetID wiederherzustellen:

    bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable

Fail-Safe

BigQuery bietet eine Fail-Safe-Periode. Während der Fail-Safe-Periode werden gelöschte Daten automatisch sieben weitere Tage nach dem Zeitreisefenster aufbewahrt, sodass die Daten für die Notfallwiederherstellung länger verfügbar bleiben. Daten können auf Tabellenebene ab dem Zeitpunkt wiederhergestellt werden, der durch den Zeitstempel des Löschvorgangs dargestellt wird.

Die Fail-Safe-Periode kann nicht konfiguriert oder verlängert werden. Sie müssen die Tabellenwiederherstellung starten und abschließen, bevor die siebentägige Fail-Safe-Periode abläuft. Planen Sie genügend Zeit ein, damit der Kopierjob je nach Größe der Tabelle abgeschlossen werden kann.

Wenn Sie die folgenden Vorgänge ausführen, können die ersetzten oder entfernten Daten über das Zeitreisefenster wiederhergestellt werden. Nach Ablauf des Zeitreisefensters werden diese Daten für eine längere Wiederherstellungszeit in die Fail-Safe-Periode verschoben:

  • Löschen oder Ersetzen von Tabellen: Wenn eine Tabelle gelöscht oder ihre Daten vollständig ersetzt werden (z. B. mit der Schreibdisposition WRITE_TRUNCATE in einem Ladejob oder mit der Anweisung CREATE OR REPLACE TABLE ), bleiben die vorherigen Inhalte der Tabelle erhalten.
  • Löschen oder Ablauf von Partitionen:Wenn eine bestimmte Partition aus einer partitionierten Tabelle gelöscht wird oder abläuft, bleiben die Daten dieser Partition erhalten. Andere Partitionen in der Tabelle sind davon nicht betroffen. Da Sie keine einzelne Partition wiederherstellen können, müssen Sie die gesamte Tabelle anhand eines Zeitstempels wiederherstellen, der vor dem Löschen oder Ablauf der Partition liegt. Wenn die ursprüngliche Tabelle einen Partitionsablauf hat, wird diese Einstellung in die wiederhergestellte Tabelle kopiert. Wenn Sie wiederhergestellte Partitionen abfragen möchten, die älter als die Ablaufzeit der Partition sind, aktualisieren Sie den Partitionsablauf in der wiederhergestellten Tabelle.

Daten aus der Fail-Safe-Speicherung wiederherstellen

Sie können Daten in der Fail-Safe-Speicherung nicht direkt abfragen und keine Tabelle aus der Fail-Safe-Speicherung kopieren, bis Cloud Customer Care den temporären Zugriff auf die Fail-Safe-Wiederherstellung für das Dataset gewährt. Wenn Sie eine Tabelle aus der Fail-Safe-Speicherung wiederherstellen möchten, wenden Sie sich an Cloud Customer Care , um Zugriff auf die Fail-Safe-Wiederherstellung für Ihr Dataset anzufordern. Stellen Sie die Tabelle dann selbst wieder her , indem Sie einen Tabellenkopierjob mit einem @TIME Zeitstempel-Decorator ausführen.

Im Gegensatz zur Wiederherstellung mit Zeitreisen, bei der nur Metadatenzeiger aktualisiert werden, müssen bei der Fail-Safe-Wiederherstellung archivierte Speicherblöcke physisch wiederhergestellt und repliziert werden, bevor der Tabellenkopierjob abgeschlossen ist. Wenn Sie eine große oder stark partitionierte Tabelle aus der Fail-Safe-Speicherung wiederherstellen, beachten Sie Folgendes:

  • Längere Kopierzeiten und Zeitüberschreitungen:Das Wiederherstellen einer Tabelle mit mehreren Terabyte oder einer Tabelle mit vielen Partitionen aus der Fail-Safe-Speicherung kann deutlich länger dauern als eine Standardtabellenkopie. Bei einem einzelnen Kopierjob kann es zu einer Zeitüberschreitung kommen oder er kann mit einem vorübergehenden internen Fehler fehlschlagen, bevor alle Speicherblöcke wiederhergestellt sind.
  • Inkrementeller Fortschritt bei Wiederholungen:Der Fortschritt der Fail-Safe-Wiederherstellung wird inkrementell gespeichert. Alle Speicherblöcke, die wiederhergestellt werden, bevor es bei einem Kopierjob zu einer Zeitüberschreitung kommt oder er fehlschlägt, bleiben wiederhergestellt. Wenn ein bq cp Befehl fehlschlägt, wiederholen Sie den Befehl mit derselben Quelltabelle und @TIME Zeitstempel-Decorator. Bei jeder Wiederholung werden die bereits wiederhergestellten Blöcke übersprungen und die restlichen Daten werden weiter wiederhergestellt, bis der Kopierjob erfolgreich ist.
  • Zeitkritisches Wiederherstellungsfenster: Wenden Sie sich Cloud Customer Care so bald wie möglich innerhalb der siebentägigen Fail-Safe-Periode an, insbesondere bei großen Tabellen, damit Sie genügend Zeit haben, Wiederholungen auszuführen, bevor die Fail-Safe-Periode abläuft.

Abrechnung

Wenn Sie Ihr Speicherabrechnungsmodell auf die Verwendung physischer Byte festlegen, werden Ihnen die für Zeitreisen und für die Fail-Safe-Speicherung verwendeten Byte separat in Rechnung gestellt. Zeitreisen und Fail-Safe-Speicher werden zum aktiven physischen Speicherpreis berechnet. Sie können das Zeitstempelfenster konfigurieren, um die Speicherkosten mit Ihren Anforderungen an die Datenaufbewahrung in Einklang zu bringen.

Wenn Sie Ihr Speicherabrechnungsmodell so einstellen, dass logische Byte verwendet werden, sind die Gesamtspeicherkosten für Zeitreisen und Fail-Safe-Speicherung im Grundpreis enthalten, der Ihnen in Rechnung gestellt wird.

Die folgende Tabelle zeigt einen Vergleich der Kosten für physischen und logischen Speicher:

Abrechnungsmodell Wofür Sie zahlen.
Physischer (komprimierter) Speicher
  • Sie zahlen für aktive Byte
  • Sie zahlen für langfristige Speicherung
  • Sie zahlen für Zeitreisenspeicher
  • Sie zahlen für Fail-Safe-Speicherung
Logischer (unkomprimierter) Speicher (Standardeinstellung)
  • Sie zahlen für aktiven Speicherplatz
  • Sie zahlen für langfristige Speicherung
  • Sie zahlen nicht für Zeitreisenspeicher
  • Sie zahlen nicht für Fail-Safe-Speicherung

Wenn Sie physischen Speicher verwenden, können Sie die von Zeitreisen und Fail-Safe-Speicherung verbrauchten Byte anhand der TIME_TRAVEL_PHYSICAL_BYTES- und FAIL_SAFE_PHYSICAL_BYTES-Spalten der Ansichten TABLE_STORAGE und TABLE_STORAGE_BY_ORGANIZATION erkennen. Ein Beispiel für die Verwendung einer dieser Ansichten zur Schätzung Ihrer Kosten finden Sie unter Speicherabrechnung prognostizieren.

Speicherkosten gelten für Zeitreise- und Fail-Safe-Daten. Sie werden Ihnen jedoch nur in Rechnung gestellt, wenn an anderer Stelle in BigQuery keine Datenspeichergebühren anfallen. Es gelten die folgenden Details:

  • Wenn eine Tabelle erstellt wird, fallen keine Kosten für die zeitübergreifende oder Fail-Safe-Speicherung an.
  • Wenn Daten geändert oder gelöscht werden, wird Ihnen der Speicherplatz für die geänderten oder gelöschten Daten in Rechnung gestellt, die während des Zeitreisezeitraums und des Ausfallsicherheitszeitraums durch die Zeitreise gespeichert wurden. Das entspricht den Speicherpreisen für Tabellen-Snapshots und ‑Klone.
  • Für temporäre Tabellen werden keine Kosten für die Fail-Safe-Speicherung berechnet.

Beispiel für die Datenaufbewahrung

In der folgenden Tabelle wird dargestellt, wie gelöschte oder geänderte Daten zwischen Speicheraufbewahrungsfenstern verschoben werden. Dieses Beispiel zeigt eine Situation, in der der gesamte aktive physische Speicher 200 GiB beträgt und 50 GiB gelöscht werden. Das Zeitreisefenster beträgt sieben Tage:

Tag 0 Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8 Tag 9 Tag 10 Tag 11 Tag 12 Tag 13 Tag 14 Tag 15
Aktiver Speicher 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
Zeitreisenspeicher 50 50 50 50 50 50 50
Ausfallsichere Speicherung 50 50 50 50 50 50 50

Das Löschen von Daten aus dem langfristigen physischen Speicher funktioniert auf die gleiche Weise.

Beschränkungen

Für den Datenabruf mit Zeitreisen gelten die folgenden Einschränkungen:

Nächste Schritte