Regionsübergreifende Dataset-Replikation

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Hinweis: Wenn Sie Feedback zu dieser Vorabversion geben oder Fragen stellen möchten, wenden Sie sich an [e-mail].

Mit der BigQuery-Dataset-Replikation können Sie die automatische Replikation eines Datasets zwischen zwei verschiedenen Regionen oder Multi-Regionen einrichten.

Übersicht

Beim Erstellen eines Datasets in BigQuery wählen Sie die Region oder Multi-Region aus, in der die Daten gespeichert werden. Eine Region ist eine Sammlung von Rechenzentren innerhalb eines geografischen Bereichs. Eine Multiregion ist ein großes geografisches Gebiet, das zwei oder mehr geografische Regionen enthält. Ihre Daten werden in einer der enthaltenen Regionen gespeichert und nicht innerhalb der Multiregion repliziert. Weitere Informationen zu Regionen und Multiregionen finden Sie unter BigQuery-Standorte.

BigQuery speichert Kopien Ihrer Daten immer in zwei verschiedenen Google Cloud-Zonen innerhalb des Dataset-Standorts. Eine Zone ist ein Bereich, in dem Google Cloud-Ressourcen innerhalb einer Region bereitgestellt werden. In allen Regionen verwendet die Replikation zwischen Zonen synchrone zweifache Exporte. Die Auswahl eines multiregionalen Standorts bietet keine regionsübergreifende Replikation oder regionale Redundanz, sodass die Verfügbarkeit der Datasets im Falle eines regionalen Ausfalls nicht erhöht wird. Die Daten werden in einer einzelnen Region innerhalb des geografischen Standorts gespeichert.

Sie können Datasets für zusätzliche Georedundanzen replizieren. BigQuery erstellt ein sekundäres Replikat des Datasets in einer anderen von Ihnen angegebenen Region. Dieses Replikat wird dann asynchron zwischen zwei Zonen mit der anderen Region repliziert. Es gibt dann insgesamt vier zonale Kopien.

Dataset-Replikation

Wenn Sie ein Dataset replizieren, speichert BigQuery die Daten in der von Ihnen angegebenen Region.

• Primäre Region. Beim Erstellen eines Datasets wird das Dataset von BigQuery in der primären Region platziert.

• Sekundäre Region. Wenn Sie ein Dataset-Replikat hinzufügen, platziert BigQuery das Replikat in der sekundären Region.

Anfänglich ist das Replikat in der primären Region das primäre Replikat und das Replikat in der sekundären Region das sekundäre Replikat.

Das primäre Replikat ist beschreibbar, das sekundäre Replikat schreibgeschützt. Schreibvorgänge auf dem primären Replikat werden asynchron auf das sekundäre Replikat repliziert. In den einzelnen Regionen werden die Daten redundant in zwei Zonen gespeichert. Der Netzwerktraffic verlässt nie das Google Cloud-Netzwerk.

Das folgende Diagramm zeigt die Replikation, die bei der Replikation eines Datasets erfolgt:

Wenn die primäre Region online ist, können Sie manuell zum sekundären Replikat wechseln. Weitere Informationen finden Sie unter Sekundäres Replikat hochstufen.

Preise

Für replizierte Datasets wird Ihnen Folgendes in Rechnung gestellt:

• Storage. Speicherbyte in der sekundären Region werden als separate Kopie in der sekundären Region abgerechnet. Siehe BigQuery-Speicherpreise.
• Datenreplikation. Weitere Informationen zu den Preisen für die Datenreplikation finden Sie unter Preise für die Datenreplikation.

Rechenkapazität in der sekundären Region

Um Jobs und Abfragen für das Replikat in der sekundären Region auszuführen, müssen Sie Slots in der sekundären Region erwerben oder eine On-Demand-Abfrage ausführen.

Sie können die Slots verwenden, um schreibgeschützte Abfragen vom sekundären Replikat auszuführen. Wenn Sie das sekundäre Replikat zum primären Replikat hochstufen, können Sie diese Slots auch zum Schreiben in das Replikat verwenden.

Sie können die gleiche Anzahl von Slots wie in der primären Region oder eine andere Anzahl an Slots erwerben. Wenn Sie weniger Slots erwerben, kann dies die Abfrageleistung beeinträchtigen.

Überlegungen zum Standort

Bevor Sie ein Dataset-Replikat hinzufügen, müssen Sie das ursprüngliche Dataset erstellen, das Sie in BigQuery replizieren möchten, falls es noch nicht vorhanden ist. Der Speicherort des hinzugefügten Replikats ist auf den Standort festgelegt, den Sie beim Hinzufügen des Replikats angeben. Der Speicherort des hinzugefügten Replikats muss sich vom Speicherort des ersten Datasets unterscheiden. Dies bedeutet, dass die Daten in Ihrem Dataset kontinuierlich zwischen dem Standort, an dem das Dataset erstellt wurde, und dem Standort des Replikats repliziert werden. Für Replikate, die am selben Standort gespeichert sein müssen, z. B. Ansichten, materialisierte Ansichten oder externe Nicht-BigLake-Tabellen, fügen Sie ein Replikat an einem Speicherort hinzu, der sich von Ihrer Quelle unterscheidet oder mit dieser nicht kompatibel ist. Der Standort der Daten kann dann zu Jobfehlern führen.

Wenn Kunden ein Dataset regionenübergreifend replizieren, sorgt BigQuery dafür, dass sich Daten nur an den Standorten befinden, an denen die Replikate erstellt wurden.

Anforderungen an die Colocation

Die Verwendung der Dataset-Replikation hängt von den folgenden Colocation-Anforderungen ab.

Cloud Storage

Zum Abfragen von Daten in Cloud Storage muss sich der Cloud Storage-Bucket am selben Standort wie das Replikat befinden. Berücksichtigen Sie bei der Wahl des Speicherorts des Replikats die Überlegungen zum externen Tabellenstandort.

Beschränkungen

Die Replikation von BigQuery-Datasets unterliegt den folgenden Einschränkungen:

• Die regionenübergreifende Dataset-Replikation ist innerhalb desselben Google Cloud-Projekts verfügbar. Sie können keine Repliken erstellen, wenn sich die Quell- und Zieldatensätze in verschiedenen Google Cloud-Projekten befinden.
• Daten in Streams, die nicht bestätigt wurden, werden nicht im sekundären Replikat repliziert, wenn die Tabelle mit der BigQuery Storage Write API geschrieben wird. Die Replikation von Streamingdaten über die BigQuery Storage Write API oder tabledata.insertAll erfolgt auf Best-Effort-Basis und kann zu einer hohen Replikationsverzögerung führen.
• Die BigQuery Storage Read API unterstützt kein Lesen aus Tabellen, die im sekundären Dataset-Replikat enthalten sind. Zum Lesen aus einer Tabelle, die im sekundären Replikat enthalten ist, muss das sekundäre Replikat zuerst zum primären Replikat hochgestuft werden.
• Tabellen, die mithilfe von Change Data Capture über Datastream in BigQuery eingefügt werden, werden nicht unterstützt.
• Replikation und Switchover werden über DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) verwaltet.
• Sie sind auf jeweils ein Replikat jedes Datasets pro Region oder Multi-Region beschränkt. Sie können nicht zwei sekundäre Replikate desselben Datasets in derselben Zielregion erstellen.
• Ressourcen in Replikaten unterliegen den unter Ressourcenverhalten beschriebenen Einschränkungen.
• Richtlinien-Tags und die zugehörigen Datenrichtlinien werden nicht in das sekundäre Replikat repliziert. Alle Abfragen, die auf Spalten mit Richtlinien-Tags in anderen Regionen als der ursprünglichen Region verweisen, schlagen fehl, auch wenn das relevante Replikat hochgestuft wurde.
• Zeitreisen sind im sekundären Replikat erst verfügbar, nachdem das Erstellen des sekundären Replikats abgeschlossen wurde.
• Sie können ein Dataset nur mit weniger als 100.000 Tabellen replizieren.
• Es können maximal vier Replikate pro Dataset und Tag für dieselbe Region hinzugefügt (und später gelöscht) werden.
• Sie sind durch die Bandbreite eingeschränkt.
• Tabellen, auf die vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) angewendet werden, können in der sekundären Region nicht abgefragt werden, wenn der Wert für replica_kms_key nicht konfiguriert ist.
• BigLake-Tabellen werden nicht unterstützt.
• BigQuery Omni-Speicherorte werden nicht unterstützt.
• Die folgenden Regionspaare können nicht konfiguriert werden, wenn Sie die Datenreplikation für die Notfallwiederherstellung konfigurieren:
  • us-central1 - us Multiregional
  • Multiregion us-west1 - us
  • Multiregion eu-west1 - eu
  • eu-west4 - eu Multiregional

Ressourcenverhalten

Die folgenden Vorgänge werden für Ressourcen innerhalb des sekundären Replikats nicht unterstützt:

• Tabelle klonen
• Tabellen-Snapshot erstellen

Wenn Sie eine Kopie einer Ressource in einem sekundären Replikat erstellen müssen, müssen Sie die Ressource kopieren oder abfragen und dann die Ergebnisse außerhalb des sekundären Replikats erfassen. Verwenden Sie beispielsweise CREATE TABLE AS SELECT, um eine neue Ressource aus der sekundären Replikatressource zu erstellen.

Primäre und sekundäre Replikate unterliegen den folgenden Unterschieden:

Primäres Replikat aus Region 1	Sekundäres Replikat aus Region 2	Hinweise
BigLake-Tabelle	BigLake-Tabelle	Nicht unterstützt.
Externe Tabelle	Externe Tabelle	Nur die externe Tabellendefinition wird repliziert. Die Abfrage schlägt fehl, wenn sich der Cloud Storage-Bucket nicht am selben Standort wie ein Replikat befindet.
Logische Ansicht	Logische Ansicht	Logische Ansichten, die auf ein nicht am selben Standort wie die logische Ansicht befindlichen Dataset oder eine Ressource verweisen, schlagen bei der Abfrage fehl.
Verwaltete Tabelle	Verwaltete Tabelle	Kein Unterschied
Materialisierte Ansicht	Materialisierte Ansicht	Wenn sich eine referenzierte Tabelle nicht in derselben Region wie die materialisierte Ansicht befindet, schlägt die Abfrage fehl. Replizierte materialisierte Ansichten sind möglicherweise älter als es das maximale Verwerfsalter der Ansicht erlaubt.
Modell	Modell	Als verwaltete Tabellen gespeichert.
Remote-Funktion	Remote-Funktion	Verbindungen sind regional. Remote-Funktionen, die auf ein nicht am selben Standort wie die Remote-Funktion befindliches Dataset oder eine solche Ressource (Verbindung) verweisen, schlagen bei der Ausführung fehl.
Routinen	Benutzerdefinierte Funktion (UDFs, User-Defined Functions) oder gespeicherte Prozedur	Abläufe, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die Routine befinden, schlagen bei der Ausführung fehl. Routinen, die auf eine Verbindung verweisen, z. B. Remote-Funktionen, funktionieren nicht außerhalb der Quellregion.
Zeilenzugriffsrichtlinie	Zeilenzugriffsrichtlinie	Kein Unterschied
Google-Suchindex	Google-Suchindex	Nicht repliziert.
Gespeicherte Prozedur	Gespeicherte Prozedur	Gespeicherte Prozeduren, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die gespeicherte Prozedur befinden, schlagen bei der Ausführung fehl.
Tabellenklon	Verwaltete Tabelle	Wird als Deep-Copy im sekundären Replikat abgerechnet.
Tabellen-Snapshot	Tabellen-Snapshot	Wird als Deep-Copy im sekundären Replikat abgerechnet.
Tabellenwertfunktion (Table-valued function, TVF)	TVF	TVFs, die auf ein nicht am selben Standort wie die TVF befindliches Dataset oder eine solche Ressource verweisen, schlagen bei der Ausführung fehl.
UDF	UDF	UDFs, die auf ein nicht am selben Standort wie die UDF befindliches Dataset oder eine solche Ressource verweisen, schlagen bei der Ausführung fehl.

Ausfallszenarien

Die regionenübergreifende Replikation ist nicht als Notfallwiederherstellungsplan bei einem Gesamtausfall der Region vorgesehen. Bei einem regionalen Gesamtausfall in der Region des primären Replikats können Sie das sekundäre Replikat nicht hochstufen. Da sekundäre Replikate schreibgeschützt sind, können Sie keine Schreibjobs auf dem sekundären Replikat ausführen und die sekundäre Region erst hochstufen, wenn die Region des primären Replikats wiederhergestellt wurde. Weitere Informationen zur Vorbereitung der Notfallwiederherstellung finden Sie unter Verwaltete Notfallwiederherstellung.

In der folgenden Tabelle werden die Auswirkungen von gesamtregionalen Ausfällen auf Ihre replizierten Daten erläutert:

Region 1	Region 2	Ausfallregion	Auswirkungen
Primäres Replikat	Sekundäres Replikat	Region 2	Schreibgeschützte Jobs, die in Region 2 ausgeführt werden, schlagen fehl.
Primäres Replikat	Sekundäres Replikat	Region 1	Alle in Region 1 ausgeführten Jobs schlagen fehl. Schreibgeschützte Jobs werden weiterhin in Region 2 ausgeführt, in der sich das sekundäre Replikat befindet. Der Inhalt von Region 2 ist veraltet, bis er erfolgreich mit Region 1 synchronisiert wird.

Dataset-Replikation verwenden

In diesem Abschnitt wird beschrieben, wie Sie ein Dataset replizieren, das sekundäre Replikat hochstufen und BigQuery-Lesejobs in der sekundären Region ausführen.

Erforderliche Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die Berechtigung bigquery.datasets.update zu erteilen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von Replikaten benötigen.

Dataset replizieren

Zum Replizieren eines Datasets verwenden Sie die ALTER SCHEMA ADD REPLICA-DDL-Anweisung.

Sie können ein Replikat zu jedem Dataset hinzufügen, das sich in einer Region oder Multi-Region befindet und noch nicht in dieser Region oder Multi-Region repliziert wurde. Wenn Sie ein Replikat hinzugefügt haben, dauert es einige Zeit, bis der erste Kopiervorgang abgeschlossen ist. Sie können während der Replikation der Daten weiterhin Abfragen ausführen, die auf das primäre Replikat verweisen, ohne dass die Kapazität der Abfrageverarbeitung reduziert wird. Sie können Daten an den geografischen Standorten innerhalb einer Multi-Region nicht replizieren.

Im folgenden Beispiel wird ein Dataset mit dem Namen my_dataset in der Region us-central1 erstellt und dann ein Replikat in der Region us-east4 hinzugefügt:

-- Create the primary replica in the us-central1 region.
CREATE SCHEMA my_dataset OPTIONS(location='us-central1');

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `my_replica`
OPTIONS(location='us-east4');

Wenn Sie wissen möchten, wann das sekundäre Replikat erfolgreich erstellt wurde, können Sie in der Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS die Spalte creation_complete abfragen.

Sekundäres Replikat hochstufen

Wenn die primäre Region online ist, können Sie das sekundäre Replikat hochstufen. Eine „Hochstufung“ macht das sekundäre Replikat zur beschreibbaren primären Instanz. Dieser Vorgang ist innerhalb weniger Sekunden abgeschlossen, wenn das sekundäre Replikat mit dem primären Replikat aktuell ist. Ist das sekundäre Replikat nicht aktuell, kann das Hochstufen erst abgeschlossen werden, wenn es aktuell ist. Das sekundäre Replikat kann nicht zum primären Replikat hochgestuft werden, wenn die Region mit der primären Instanz ausfällt.

Bitte beachten Sie dabei Folgendes:

• Alle Schreibvorgänge in Tabellen geben Fehler zurück, während die Hochstufung ausgeführt wird. In das alte primäre Replikat kann ab Beginn der Hochstufung nicht mehr geschrieben werden.
• Tabellen, die zur Zeit der Initiierung der Hochstufung nicht vollständig repliziert waren, geben veraltete Lesevorgänge zurück.

Verwenden Sie die DDL-Anweisung ALTER SCHEMA SET OPTIONS und legen Sie die Option primary_replica fest, um ein Replikat zu einem primären Replikat hochzustufen.

Beachten Sie Folgendes: Sie müssen den Jobstandort in den Abfrageeinstellungen explizit auf die sekundäre Region festlegen. Siehe BigQuery-Standorte angeben.

Im folgenden Beispiel wird das Replikat us-east4 zum primären Replikat hochgestuft:

ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = 'us-east4')

Wenn Sie wissen möchten, wann das sekundäre Replikat erfolgreich hochgestuft wurde, können Sie in der Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS die Spalte replica_primary_assignment_complete abfragen.

Dataset-Replikat entfernen

Mit der DDL-Anweisung ALTER SCHEMA DROP REPLICA können Sie ein Replikat entfernen und die Replikation des Datasets beenden.

Im folgenden Beispiel wird das Replikat us entfernt:

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

Sie müssen zuerst alle sekundären Replikate löschen, um das gesamte Dataset zu löschen. Wenn Sie das gesamte Dataset löschen, z. B. mit der Anweisung DROP SCHEMA, ohne alle sekundären Replikate zu löschen, erhalten Sie eine Fehlermeldung.

Dataset-Replikate auflisten

Fragen Sie die Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS ab, um die Dataset-Replikate in einem Projekt aufzulisten.

Datasets migrieren

Mit der regionenübergreifenden Dataset-Replikation können Sie Ihre Datasets von einer Region zu einer anderen migrieren. Das folgende Beispiel zeigt den Prozess der Migration des vorhandenen Datasets my_migration von der Multi-Region US mithilfe der regionenübergreifenden Replikation auf die Multi-Region EU.

Dataset replizieren

Replizieren Sie zuerst das Dataset in der Region, in die Sie die Daten migrieren möchten, um den Migrationsprozess zu starten. In diesem Szenario migrieren Sie das Dataset my_migration zur Multi-Region EU.

-- Create a replica in the secondary region.
ALTER SCHEMA my_migration
ADD REPLICA `eu`
OPTIONS(location='eu');

Dadurch wird ein sekundäres Replikat mit dem Namen eu am multiregionalen Standort EU erstellt. Das primäre Replikat ist das Dataset my_migration am multiregionalen Standort US.

Sekundäres Replikat hochstufen

Um die Migration des Datasets zur Multi-Region EU fortzusetzen, stufen Sie das sekundäre Replikat hoch:

ALTER SCHEMA my_migration SET OPTIONS(primary_replica = 'eu')

Nach Abschluss der Hochstufung ist eu das primäre Replikat. Es ist ein beschreibbares Replikat.

Migration abschließen

Um die Migration von der US-Multi-Region zur EU-Multi-Region abzuschließen, löschen Sie das us-Replikat. Dieser Schritt ist nicht erforderlich, aber nützlich, wenn Sie für die Migration kein Dataset-Replikat benötigen.

ALTER SCHEMA my_migration
DROP REPLICA IF EXISTS us;

Ihr Dataset befindet sich in der EU-Multi-Region und es gibt keine Replikate des my_migration-Datasets. Sie haben Ihr Dataset erfolgreich in die Multi-Region EU migriert. Die vollständige Liste der migrierten Ressourcen finden Sie unter Ressourcenverhalten.

Kunden-verwaltete Verschlüsselungsschlüssel (CMEK)

Vom Kunden verwaltete Cloud Key Management Service-Schlüssel werden beim Erstellen eines sekundären Replikats nicht automatisch repliziert. Um die Verschlüsselung Ihres replizierten Datasets beizubehalten, müssen Sie replica_kms_key für den Standort des hinzugefügten Replikats festlegen. Sie können replica_kms_key mit der DDL-Anweisung ALTER SCHEMA ADD REPLICA festlegen.

Das Replizieren von Datasets mit CMEK verhält sich wie in den folgenden Szenarien beschrieben:

• Wenn das Quell-Dataset ein default_kms_key hat, müssen Sie replica_kms_key angeben, das in der Region des Replikat-Datasets erstellt wurde, wenn die DDL-Anweisung ALTER SCHEMA ADD REPLICA verwendet wird.

• Wenn im Quell-Dataset kein Wert für default_kms_key festgelegt ist, können Sie replica_kms_key nicht festlegen.

• Wenn Sie die Cloud KMS-Schlüsselrotation für default_kms_key oder replica_kms_key (oder für beide Elemente) verwenden, kann das replizierte Dataset nach der Schlüsselrotation weiterhin abgefragt werden.

  • Die Schlüsselrotation in der primären Region aktualisiert die Schlüsselversion nur in Tabellen, die nach der Rotation erstellt wurden. Tabellen, die vor der Schlüsselrotation vorhanden waren, verwenden weiterhin die Schlüsselversion, die vor der Rotation festgelegt war.
  • Die Schlüsselrotation in der sekundären Region aktualisiert alle Tabellen im sekundären Replikat auf die neue Schlüsselversion.
  • Wenn Sie das primäre Replikat auf das sekundäre Replikat umstellen, werden alle Tabellen im sekundären Replikat (das zuvor das primäre Replikat war) auf die neue Schlüsselversion aktualisiert.
  • Wenn die Schlüsselversion, die für Tabellen im primären Replikat vor der Schlüsselrotation festgelegt wurde, gelöscht wird, können Tabellen, die noch die Schlüsselversion verwenden, die vor der Schlüsselrotation festgelegt war, erst abgefragt werden, wenn die Schlüsselversion aktualisiert wurde. Damit die Schlüsselversion aktualisiert werden kann, muss die alte Schlüsselversion aktiv sein (d. h. weder deaktiviert noch gelöscht).

• Wenn im Quell-Dataset kein Wert für default_kms_key festgelegt ist, aber einzelne Tabellen im Quell-Dataset mit angewendetem CMEK vorhanden sind, können diese Tabellen im replizierten Dataset nicht abgefragt werden. So fragen Sie die Tabellen ab:

  • Fügen Sie einen default_kms_key-Wert für das Quell-Dataset hinzu.
  • Wenn Sie ein neues Replikat mit der DDL-Anweisung ALTER SCHEMA ADD REPLICA erstellen, legen Sie einen Wert für die Option replica_kms_key fest. Die CMEK-Tabellen können in der Zielregion abgefragt werden.

  Alle CMEK-Tabellen in der Zielregion verwenden denselben replica_kms_key, unabhängig vom Schlüssel, der in der Quellregion verwendet wird.

Replikat mit CMEK erstellen

Im folgenden Beispiel wird ein Replikat in der Region us-west1 mit einem festgelegten replica_kms_key-Wert erstellt. Gewähren Sie dem CMEK-Schlüssel die BigQuery-Dienstkonto-Berechtigung zum Verschlüsseln und Entschlüsseln.

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-west1`
OPTIONS(location='us-west1',
  replica_kms_key='my_us_west1_kms_key_name');

CMEK-Einschränkungen

Das Replizieren von Datasets mit angewendetem CMEK unterliegt den folgenden Einschränkungen:

• Sie können den replizierten Cloud KMS-Schlüssel nicht mehr aktualisieren, nachdem das Replikat erstellt wurde.

• Der Wert für default_kms_key kann im Quelldatensatz nicht mehr aktualisiert werden, nachdem die Dataset-Replikate erstellt wurden.

• Wenn der angegebene replica_kms_key in der Zielregion nicht gültig ist, wird das Dataset nicht repliziert.

• CMEK-verschlüsselte Tabellen, die in die Zielregion repliziert wurden, sind sichtbar, können aber nicht abgefragt oder darauf geschrieben werden, da der CMEK der Quelle in der Zielregion nicht erkannt wird.

Nächste Schritte

• Mit BigQuery-Reservierungen arbeiten.
• Weitere Informationen zu BigQuery-Zuverlässigkeitsfeatures.