Daten mit Datenbearbeitungssprache (DML) transformieren

Mit der BigQuery-Datenbearbeitungssprache (Data Manipulation Language, DML) können Sie Daten in BigQuery-Tabellen aktualisieren, einfügen und löschen.

Sie können DML-Anweisungen genau wie eine SELECT-Anweisung ausführen. Allerdings müssen folgende Bedingungen erfüllt sein:

• Sie müssen GoogleSQL verwenden. Wie Sie GoogleSQL aktivieren, erfahren Sie unter SQL-Dialekte wechseln.
• Sie können keine Zieltabelle für die Abfrage angeben.

Weitere Informationen zum Berechnen der Anzahl der von einer DML-Anweisung verarbeiteten Byte finden Sie unter On-Demand-Berechnung der Abfragegröße.

Beschränkungen

• Jede DML-Anweisung initiiert eine implizite Transaktion, was bedeutet, dass von der Anweisung vorgenommene Änderungen automatisch am Ende jeder erfolgreichen DML-Anweisung per Commit übernommen werden.

• Zeilen, die kürzlich mit der tabledata.insertall Streaming-Methode geschrieben wurden, können nicht mit Datenbearbeitungssprache (Data Manipulation Language, DML) geändert werden, darunter: UPDATE, DELETE, MERGE oder TRUNCATE-Anweisungen. Die kürzlichen Schreibvorgänge sind jene, die innerhalb der letzten 30 Minuten ausgeführt wurden. Alle anderen Zeilen in der Tabelle können weiterhin durch die Anweisungen UPDATE, DELETE, MERGE oder TRUNCATE verändert werden. Es kann bis zu 90 Minuten dauern, bis die gestreamten Daten für Kopiervorgänge verfügbar sind.

  Alternativ können Zeilen, die kürzlich mit der Storage Write API geschrieben wurden, mit den Anweisungen UPDATE, DELETE, MERGE oder TRUNCATE geändert werden. Weitere Informationen finden Sie unter Datenbearbeitungssprache (DML) mit kürzlich gestreamten Daten verwenden.

• Korrelierte Unterabfragen innerhalb einer when_clause, search_condition, merge_update_clause oder merge_insert_clause werden für MERGE-Anweisungen nicht unterstützt.

• Abfragen, die DML-Anweisungen enthalten, können keine Platzhaltertabelle als Ziel der Abfrage verwenden. Eine Platzhaltertabelle kann beispielsweise in der FROM-Klausel einer UPDATE-Abfrage verwendet werden, aber nicht als Ziel des UPDATE-Vorgangs.

DML-Anweisungen

In den folgenden Abschnitten werden die verschiedenen Arten von DML-Anweisungen und ihre Verwendung beschrieben.

INSERT-Anweisung

Mit der INSERT-Anweisung können Sie einer vorhandenen Tabelle neue Zeilen hinzufügen. Im folgenden Beispiel werden neue Zeilen mit explizit angegebenen Werten in die Tabelle dataset.Inventory eingefügt.

INSERT dataset.Inventory (product, quantity)
VALUES('whole milk', 10),
      ('almond milk', 20),
      ('coffee beans', 30),
      ('sugar', 0),
      ('matcha', 20),
      ('oat milk', 30),
      ('chai', 5)

/+-------------------+----------+
 |      product      | quantity |
 +-------------------+----------+
 | almond milk       |       20 |
 | chai              |        5 |
 | coffee beans      |       30 |
 | matcha            |       20 |
 | oat milk          |       30 |
 | sugar             |        0 |
 | whole milk        |       10 |
 +-------------------+----------+/

Weitere Informationen zu INSERT-Anweisungen finden Sie unter INSERT statement.

DELETE-Anweisung

Mit der DELETE-Anweisung können Sie Zeilen in einer Tabelle löschen. Im folgenden Beispiel werden alle Zeilen in der Tabelle dataset.Inventory gelöscht, deren quantity-Wert 0 ist.

DELETE dataset.Inventory
WHERE quantity = 0

/+-------------------+----------+
 |      product      | quantity |
 +-------------------+----------+
 | almond milk       |       20 |
 | chai              |        5 |
 | coffee beans      |       30 |
 | matcha            |       20 |
 | oat milk          |       30 |
 | whole milk        |       10 |
 +-------------------+----------+/

Wenn Sie alle Zeilen in einer Tabelle löschen möchten, verwenden Sie stattdessen die Anweisung TRUNCATE TABLE. Weitere Informationen zu DELETE Anweisungen finden Sie unter DELETE Anweisung.

TRUNCATE-Anweisung

Mit der TRUNCATE-Anweisung werden alle Zeilen aus einer Tabelle entfernt, die Metadaten der Tabelle, einschließlich Tabellenschema, Beschreibung und Labels, bleiben jedoch erhalten. Im folgenden Beispiel werden alle Zeilen aus der Tabelle dataset.Inventory entfernt.

TRUNCATE dataset.Inventory

Wenn Sie bestimmte Zeilen in einer Tabelle löschen möchten, verwenden Sie stattdessen die Anweisung DELETE. Weitere Informationen zur TRUNCATE Anweisung finden Sie unter TRUNCATE Anweisung.

UPDATE-Anweisung

Mit der UPDATE-Anweisung werden vorhandene Zeilen in einer Tabelle aktualisiert. Die Anweisung UPDATE muss auch das Schlüsselwort WHERE enthalten, um eine Bedingung anzugeben. Im folgenden Beispiel wird der Wert von quantity für Zeilen um 10 reduziert, die die String milk enthalten.

UPDATE dataset.Inventory
SET quantity = quantity - 10,
WHERE product LIKE '%milk%'

/+-------------------+----------+
 |      product      | quantity |
 +-------------------+----------+
 | almond milk       |       10 |
 | chai              |        5 |
 | coffee beans      |       30 |
 | matcha            |       20 |
 | oat milk          |       20 |
 | whole milk        |        0 |
 +-------------------+----------+/

UPDATE-Anweisungen können auch FROM-Klauseln enthalten, um verknüpfte Tabellen einzubeziehen. Weitere Informationen zu UPDATE-Anweisungen finden Sie unter UPDATE-Anweisung.

MERGE-Anweisung

Die Anweisung MERGE kombiniert die Vorgänge INSERT, UPDATE und DELETE in einer einzigen Anweisung und führt die Vorgänge atomar aus, um Daten aus einer Tabelle in eine andere zu zusammenzuführen. Weitere Informationen und Beispiele zur MERGE Anweisung finden Sie unter MERGE Anweisung.

Gleichzeitige Jobs

BigQuery verwaltet die Gleichzeitigkeit von DML-Anweisungen, mit denen Zeilen in einer Tabelle hinzugefügt, geändert oder gelöscht werden.

Hinweis: DML-Anweisungen unterliegen Ratenbegrenzungen wie etwa der maximalen Rate von Tabellenschreibvorgängen. Eine Ratenbegrenzung kann erreicht werden, wenn Sie eine große Anzahl an Jobs für eine Tabelle gleichzeitig senden. Diese Raten begrenzen nicht die Gesamtzahl der DML-Anweisungen, die ausgeführt werden können. Wenn Sie eine Fehlermeldung erhalten, die angibt, dass Sie eine Ratenbegrenzung überschritten haben, wiederholen Sie den Vorgang mit exponentiellem Backoff zwischen den Wiederholungen.

Nebenläufigkeit von INSERT-DML-Anweisungen

Innerhalb eines Zeitraums von 24 Stunden werden die ersten 1.500 INSERT-Anweisungen sofort nach dem Senden ausgeführt. Nachdem dieses Limit erreicht wurde, ist die Nebenläufigkeit von INSERT-Anweisungen zum Schreiben in eine Tabelle auf 10 beschränkt. Zusätzliche INSERT-Anweisungen werden einer PENDING-Warteschlange hinzugefügt. Es können jeweils bis zu 100 INSERT-Anweisungen für eine Tabelle in die Warteschlange gestellt werden. Wenn eine INSERT-Anweisung abgeschlossen ist, wird die nächste INSERT-Anweisung aus der Warteschlange entfernt und ausgeführt.

Wenn Sie DML-INSERT-Anweisungen häufiger ausführen müssen, können Sie Daten mit der Storage Write API in Ihre Tabelle streamen.

Gleichzeitigkeit von UPDATE-, DELETE- und MERGE-DML-Anweisungen

Die DML-Anweisungen UPDATE, DELETE und MERGE werden als sich ändernde DML-Anweisungen bezeichnet. Wenn Sie eine oder mehrere sich ändernde DML-Anweisungen für eine Tabelle senden, während noch andere sich ändernde DML-Jobs für diese ausgeführt werden (oder ausstehend sind), führt BigQuery bis zu zwei von ihnen gleichzeitig aus, danach werden bis zu 20 als PENDING in der Warteschlange platziert. Wenn ein zuvor ausgeführter Job abgeschlossen ist, wird der nächste ausstehende Job aus der Warteschlange entfernt und ausgeführt. Derzeit teilen sich mutierende DML-Anweisungen in der Warteschlange eine tabellenspezifische Warteschlange mit einer maximalen Länge von 20. Zusätzliche Anweisungen nach der maximalen Warteschlangenlänge für jede einzelne Tabelle schlagen mit der Fehlermeldung fehl: Resources exceeded during query execution: Too many DML statements outstanding against table PROJECT_ID:DATASET.TABLE, limit is 20.

Interaktive Prioritäts-DML-Jobs, die länger als sieben Stunden in der Warteschlange stehen, schlagen mit der folgenden Fehlermeldung fehl:

DML statement has been queued for too long

Konflikte mit DML-Anweisung

Mutierende DML-Anweisungen, die gleichzeitig in einer Tabelle ausgeführt werden, verursachen Konflikte mit DML-Anweisungen, wenn durch die Anweisungen versucht wird, dieselbe Partition zu mutieren. Die Anweisungen sind erfolgreich, solange sie nicht dieselbe Partition ändern. BigQuery versucht bis zu dreimal, fehlgeschlagene Anweisungen noch einmal auszuführen.

• Eine INSERT-DML-Anweisung, die Zeilen in eine Tabelle einfügt, steht nicht im Konflikt mit einer anderen gleichzeitig ausgeführten DML-Anweisung.

• Eine MERGE-DML-Anweisung steht nicht in Konflikt mit anderen gleichzeitig ausgeführten DML-Anweisungen, solange mit der Anweisung nur Zeilen eingefügt werden und vorhandene Zeilen nicht gelöscht oder aktualisiert werden. Dazu können MERGE-Anweisungen mit UPDATE- oder DELETE-Klauseln gehören, sofern diese Klauseln nicht bei der Ausführung der Abfrage aufgerufen werden.

Detaillierte DML

Vorschau

Diese Funktion unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Sie können personenbezogene Daten für diese Funktion gemäß dem Zusatz zur Verarbeitung von Cloud-Daten verarbeiten, vorbehaltlich der in der Vereinbarung beschriebenen Verpflichtungen und Einschränkungen, gemäß der Sie auf Google Cloud zugreifen. Pre-GA‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Hinweis: Wenn Sie Feedback geben oder Support für diese Funktion anfordern möchten, senden Sie eine E-Mail an [e-mail].

Die detaillierte DML ist eine Leistungsverbesserung, mit der die Ausführung von UPDATE-, DELETE- und MERGE-Anweisungen (auch als mutierende DML-Anweisungen bezeichnet) optimiert werden soll.

Hinweise zur Leistung

Wenn die detaillierte DML nicht aktiviert ist, werden DML-Mutationen auf Dateigruppenebene ausgeführt, was zu ineffizienten Datenneuschreibungen führen kann, insbesondere bei spärlichen Mutationen. Dies kann zu einem zusätzlichen Slotverbrauch und längeren Ausführungszeiten führen.

Die detaillierte DML ist eine Leistungsverbesserung, mit der diese mutierenden DML-Anweisungen optimiert werden sollen. Dazu wird ein detaillierterer Ansatz eingeführt, mit dem die Menge der Daten reduziert werden soll, die auf Dateigruppenebene neu geschrieben werden müssen. Dieser Ansatz kann die für mutierende DML-Jobs verbrauchte Verarbeitungs-, E/A- und Slotzeit erheblich reduzieren.

Bei der Verwendung der detaillierten DML sind einige Leistungsaspekte zu beachten:

• Bei detaillierten DML-Vorgängen werden gelöschte Daten mit einem hybriden Ansatz verarbeitet, bei dem die Kosten für das Neuschreiben auf zahlreiche Tabellenmutationen verteilt werden. Bei jedem DML-Vorgang wird möglicherweise ein Teil der gelöschten Daten verarbeitet und die Verarbeitung der verbleibenden gelöschten Daten an einen Hintergrundprozess zur automatischen Speicherbereinigung ausgelagert. Weitere Informationen finden Sie unter Überlegungen zu gelöschten Daten.
• Bei Tabellen mit häufigen mutierenden DML-Vorgängen kann es zu einer erhöhten Latenz bei nachfolgenden SELECT-Abfragen und DML-Jobs kommen. Um die Auswirkungen der Aktivierung dieser Funktion zu bewerten, führen Sie einen Benchmark für eine realistische Abfolge von DML-Vorgängen und nachfolgenden Lesevorgängen durch.
• Durch die Aktivierung der detaillierten DML wird die Anzahl der gescannten Byte der mutierenden DML-Anweisung selbst nicht reduziert.

Detaillierte DML aktivieren

Wenn Sie die detaillierte DML aktivieren möchten, legen Sie die enable_fine_grained_mutations Tabellenoption auf TRUE fest, wenn Sie eine CREATE TABLE oder ALTER TABLE DDL-Anweisung ausführen.

Verwenden Sie die CREATE TABLE Anweisung, um eine neue Tabelle mit detaillierter DML zu erstellen:

CREATE TABLE mydataset.mytable (
  product STRING,
  inventory INT64)
OPTIONS(enable_fine_grained_mutations = TRUE);

Verwenden Sie die ALTER TABLE Anweisung, um eine vorhandene Tabelle mit detaillierter DML zu ändern:

ALTER TABLE mydataset.mytable
SET OPTIONS(enable_fine_grained_mutations = TRUE);

Verwenden Sie die ALTER TABLE Anweisung, um alle vorhandenen Tabellen in einem Dataset mit detaillierter DML zu ändern:

FOR record IN
 (SELECT CONCAT(table_schema, '.', table_name) AS table_path
 FROM mydataset.INFORMATION_SCHEMA.TABLES)
DO
 EXECUTE IMMEDIATE
   "ALTER TABLE " || record.table_path || " SET OPTIONS(enable_fine_grained_mutations = TRUE)";
END FOR;

Nachdem die Option enable_fine_grained_mutations auf TRUE gesetzt wurde, werden mutierende DML-Anweisungen mit aktivierten detaillierten DML-Funktionen ausgeführt und verwenden die vorhandene DML-Anweisungssyntax.

Fragen Sie die INFORMATION_SCHEMA.TABLES Ansicht ab, um festzustellen, ob eine Tabelle für die detaillierte DML aktiviert wurde. Im folgenden Beispiel wird geprüft, für welche Tabellen in einem Dataset diese Funktion aktiviert wurde:

SELECT
  table_schema AS datasetId,
  table_name AS tableId,
  is_fine_grained_mutations_enabled
FROM
  DATASET_NAME.INFORMATION_SCHEMA.TABLES;

Ersetzen Sie DATASET_NAME durch den Namen des Datasets, in dem Sie prüfen möchten, ob für Tabellen die detaillierte DML aktiviert ist.

Detaillierte DML deaktivieren

Verwenden Sie die ALTER TABLE Anweisung, um die detaillierte DML für eine vorhandene Tabelle zu deaktivieren.

ALTER TABLE mydataset.mytable
SET OPTIONS(enable_fine_grained_mutations = FALSE);

Wenn Sie die detaillierte DML deaktivieren, kann es einige Zeit dauern, bis alle gelöschten Daten vollständig verarbeitet wurden. Weitere Informationen finden Sie unter Überlegungen zu gelöschten Daten. Daher können die Einschränkungen der detaillierten DML bestehen bleiben bis dies geschehen ist.

Preise

Die Aktivierung der detaillierten DML für eine Tabelle kann zusätzliche Kosten verursachen. Diese Kosten umfassen Folgendes:

• BigQuery-Speicherkosten für die Speicherung der zusätzlichen Mutationsmetadaten, die mit detaillierten DML Vorgängen verknüpft sind. Die tatsächlichen Speicherkosten hängen von der Menge der geänderten Daten ab, sind aber in den meisten Fällen im Vergleich zur Größe der Tabelle selbst vernachlässigbar.
• BigQuery-Rechenkosten für die Verarbeitung gelöschter Daten mit ausgelagerten Jobs zur automatischen Speicherbereinigungund nachfolgende SELECTAbfragen, bei denen zusätzliche Löschmetadaten verarbeitet werden, die noch nicht automatisch bereinigt wurden.

Sie können BigQuery-Reservierungen verwenden, um dedizierte BigQuery-Rechenressourcen für die Verarbeitung ausgelagerter Jobs für gelöschte Daten zuzuweisen. Mit Reservierungen können Sie die Kosten für die Ausführung dieser Vorgänge begrenzen. Dieser Ansatz ist besonders nützlich und wird häufig für sehr große Tabellen mit häufigen detaillierten mutierenden DML-Vorgängen empfohlen, da sonst hohe On-Demand-Kosten anfallen würden, weil bei jedem ausgelagerten Job zur Verarbeitung gelöschter Daten eine große Anzahl von Byte verarbeitet wird.

Die ausgelagerten Jobs zur Verarbeitung gelöschter Daten der detaillierten DML werden als Hintergrundjobs betrachtet und erfordern die Verwendung des BACKGROUND Reservierungszuweisungstyps, anstelle des QUERY Reservierungszuweisungstyps. Bei Projekten, in denen detaillierte DML-Vorgänge ohne eine BACKGROUND Zuweisung ausgeführt werden, werden die ausgelagerten Jobs zur Verarbeitung gelöschter Daten mit On-Demand-Preisen abgerechnet.

Vorgang	On-Demand-Preise	Kapazitätsbasierte Preise
Mutierende DML-Anweisungen	Verwenden Sie die Standard DML-Größenbestimmung , um die On-Demand-Berechnungen für gescannte Byte zu ermitteln. Durch die Aktivierung der detaillierten DML wird die Anzahl der gescannten Byte der DML-Anweisung selbst nicht reduziert.	Verbrauchen Sie Slots, die mit dem Typ QUERY zugewiesen wurden, während der Ausführung der Anweisung.
Ausgelagerte Jobs zur Verarbeitung gelöschter Daten	Verwenden Sie die Standard DML-Größenbestimmung , um die On-Demand-Berechnungen für gescannte Byte zu ermitteln, wenn Jobs zur Verarbeitung gelöschter Daten ausgeführt werden.	Verbrauchen Sie Slots, die mit dem Typ BACKGROUND zugewiesen wurden, wenn gelöschte Datenverarbeitungsjobs ausgeführt werden.

Überlegungen zu gelöschten Daten

Bei detaillierten DML-Vorgängen wird ein hybrider Ansatz zur Verwaltung gelöschter Daten verwendet, bei dem die Inline-Verarbeitung mit der ausgelagerten automatischen Speicherbereinigung kombiniert wird, um die Kosten für das Neuschreiben zu verteilen und die Leistung für mehrere mutierende DML-Anweisungen zu optimieren, die für eine Tabelle ausgegeben werden.

Während der Ausführung einer mutierenden DML-Anweisung versucht BigQuery, einen Teil der relevanten automatischen Speicherbereinigung aus früheren DML-Anweisungen inline durchzuführen. Alle gelöschten Daten, die nicht inline verarbeitet werden, werden zur späteren Bereinigung an einen Hintergrundprozess ausgelagert.

Bei Projekten, in denen detaillierte DML-Vorgänge mit einer BACKGROUND-Zuweisung ausgeführt werden, werden ausgelagerte Aufgaben zur automatischen Speicherbereinigung mit Slots verarbeitet. Die Verarbeitung gelöschter Daten unterliegt der Ressourcenverfügbarkeit der konfigurierten Reservierung. Wenn in der konfigurierten Reservierung nicht genügend Ressourcen verfügbar sind, kann die Verarbeitung ausgelagerter Vorgänge zur automatischen Speicherbereinigung länger als erwartet dauern.

Bei Projekten, in denen detaillierte DML-Vorgänge mit On-Demand-Preisen oder ohne BACKGROUND Zuweisung ausgeführt werden, werden ausgelagerte Aufgaben zur automatischen Speicherbereinigung mit internen BigQuery-Ressourcen verarbeitet und zu On-Demand-Preisen abgerechnet. Weitere Informationen finden Sie unter Preise.

Der Zeitpunkt der ausgelagerten Aufgaben zur automatischen Speicherbereinigung wird durch die Häufigkeit der DML-Aktivität in der Tabelle und die Verfügbarkeit von Ressourcen bestimmt, wenn eine BACKGROUND-Zuweisung verwendet wird:

• Bei Tabellen mit kontinuierlichen mutierenden DML-Vorgängen verarbeitet jede DML einen Teil der Arbeitslast für die automatische Speicherbereinigung, um eine konsistente Lese- und Schreibleistung zu gewährleisten. Daher wird die automatische Speicherbereinigung regelmäßig verarbeitet, wenn die nachfolgenden DMLs ausgeführt werden.
• Wenn in einer Tabelle keine nachfolgende DML-Aktivität erfolgt, wird die ausgelagerte automatische Speicherbereinigung automatisch ausgelöst, sobald die gelöschten Daten 5 Tage alt sind.
• In seltenen Fällen kann es länger dauern, bis gelöschte Daten vollständig verarbeitet wurden.

Fragen Sie die INFORMATION_SCHEMA.JOBS Ansicht ab, um ausgelagerte Jobs zur Verarbeitung gelöschter Daten der detaillierten DML zu ermitteln:

SELECT
  *
FROM
  region-us.INFORMATION_SCHEMA.JOBS
WHERE
  job_id LIKE "%fine_grained_mutation_garbage_collection%"

Beschränkungen

Für Tabellen, für die die detaillierte DML aktiviert ist, gelten die folgenden Einschränkungen:

• Für große Tabellen mit häufig mutierten Partitionen, die 2 TB überschreiten, wird die detaillierte DML nicht empfohlen. Bei diesen Tabellen kann es zu einer erhöhten Speicherauslastung bei nachfolgenden Abfragen kommen, was zu einer zusätzlichen Leselatenz oder zu Abfragefehlern führen kann.
• In einer Tabelle, für die die detaillierte DML aktiviert ist, kann jeweils nur eine mutierende DML-Anweisung ausgeführt werden. Nachfolgende Jobs werden als PENDING in die Warteschlange gestellt. Weitere Informationen zum Verhalten der Nebenläufigkeit mutierender DML-Anweisungen finden Sie unter Nebenläufigkeit von UPDATE-, DELETE- und MERGE-DML-Anweisungen.
• Bei einer Tabelle, für die die detaillierte DML aktiviert ist, können Partitionen nicht einzeln gelöscht oder überschriebenwerden. Wenn Sie Daten in einer Partition löschen oder ersetzen möchten, müssen Sie eine mutierende DML-Anweisung wie DELETE, UPDATE, MERGE oder TRUNCATE verwenden.
• Sie können die tabledata.list Methode nicht verwenden, um Inhalte aus einer Tabelle zu lesen, für die die detaillierte DML aktiviert ist. Fragen Sie stattdessen die Tabelle mit einer SELECT-Anweisung ab, um Tabelleneinträge zu lesen.
• Eine Tabelle, für die die detaillierte DML aktiviert ist, kann in der BigQuery-Konsole nicht in der Vorschau angezeigt werden.
• Sie können eine Tabelle, für die die detaillierte DML aktiviert ist, nicht kopieren, nachdem Sie eine UPDATE, DELETE oder MERGE Anweisung ausgeführt haben.
• Sie können keinen Tabellensnapshot oder Tabellenklon einer Tabelle erstellen, für die die detaillierte DML aktiviert ist, nachdem Sie eine UPDATE-, DELETE- oder MERGE-Anweisung ausgeführt haben.
• Sie können die detaillierte DML nicht für eine Tabelle in einem replizierten Datasetaktivieren und Sie können kein Dataset replizieren, das eine Tabelle enthält, für die die detaillierte DML aktiviert ist.
• DML-Anweisungen, die in einer Transaktion mit mehreren Anweisungen ausgeführt werden, werden nicht mit der detaillierten DML optimiert.
• Sie können die detaillierte DML nicht für temporäre Tabellen aktivieren, die mit der CREATE TEMP TABLE Anweisung erstellt wurden.
• Metadaten, die in den INFORMATION_SCHEMA.TABLE_STORAGE Ansichten und INFORMATION_SCHEMA.PARTITIONS Ansichten angezeigt werden, können vorübergehend kürzlich mit der detaillierten DML gelöschte Daten enthalten, bis die Jobs zur automatischen Speicherbereinigung im Hintergrund abgeschlossen sind.

Best Practices

Für eine optimale Leistung empfiehlt Google folgende Muster:

• Vermeiden Sie es, zu viele einzelne Zeilenaktualisierungen oder -einfügungen zu senden. Gruppieren Sie stattdessen DML-Vorgänge wo möglich. Weitere Informationen finden Sie unter DML-Anweisungen, die einzelne Zeilen aktualisieren oder einfügen.

• Wenn Aktualisierungen oder Löschvorgänge im Allgemeinen für ältere Daten oder innerhalb eines bestimmten Zeitraums durchgeführt werden, empfiehlt sich eine Partitionierung Ihrer Tabellen. Durch die Partitionierung wird dafür gesorgt, dass die Änderungen auf bestimmte Partitionen innerhalb der Tabelle beschränkt sind.

• Partitionieren Sie Tabellen nicht, wenn die Datenmenge in jeder Partition klein ist und jede Aktualisierung einen großen Teil der Partitionen ändert.

• Wenn Sie häufig Zeilen aktualisieren, in denen eine oder mehrere Spalten in einen engen Wertebereich fallen, können Sie geclusterte Tabellen verwenden. Clustering sorgt dafür, dass Änderungen auf bestimmte Gruppen von Blöcken beschränkt sind, und reduziert die zu lesende und schreibende Datenmenge. Das folgende Beispiel zeigt eine UPDATE-Anweisung, die nach einem Bereich von Spaltenwerten filtert:

  UPDATE mydataset.mytable
  SET string_col = 'some string'
  WHERE id BETWEEN 54 AND 75;

  Hier ist ein ähnliches Beispiel, das nach einer kleinen Liste von Spaltenwerten filtert:

  UPDATE mydataset.mytable
  SET string_col = 'some string'
  WHERE id IN (54, 57, 60);

  In diesen Fällen sollten Sie das Clustering auf der Spalte id vornehmen.

• Wenn Sie OLTP-Funktionen benötigen, können Sie föderierte Cloud SQL-Abfragen verwenden, mit denen BigQuery Daten abfragen kann, die in Cloud SQL gespeichert sind.

• Informationen zum Beheben und Vermeiden des Kontingentfehlers Too many DML statements outstanding against table, finden Sie unter der Anleitung für diesen Fehler auf der Seite zur Fehlerbehebung in BigQuery.

Best Practices zur Optimierung der Abfrageleistung finden Sie unter Einführung in die Optimierung der Abfrageleistung.

Nächste Schritte

• Informationen zur DML-Syntax und Beispiele finden Sie unter DML-Syntax.
• Weitere Informationen finden Sie unter Daten aus partitionierten Tabellen mithilfe von DML aktualisieren.
• Informationen zum Verwenden von DML-Anweisungen in geplanten Abfragen finden Sie unter Abfragen planen.