Preise

BigQuery bietet skalierbare, flexible Preismodelle, die sich an Ihr Projekt und Budget anpassen lassen.

Die Speicherkosten basieren bei BigQuery ausschließlich auf der Menge der gespeicherten Daten. Es gibt zwei Varianten:

  • Aktiv: Für Daten in Tabellen, die Sie in den letzten 90 Tagen bearbeitet haben, fällt eine monatliche Gebühr an.
  • Langfristig: Für Daten in Tabellen, die in den letzten 90 Tagen nicht bearbeitet wurden, wird eine geringere monatliche Gebühr fällig.

Die Abfragekosten basieren auf der durch die Abfrage verarbeiteten Datenmenge. Sie haben zwei Optionen:

  • On-Demand: Dies ist die flexibelste Möglichkeit. Hier basiert der Preis ausschließlich auf der Nutzung.
  • Pauschalpreis: Unternehmen ziehen in der Regel Pauschalpreise für Abfragen vor, da sie so die monatlichen Kosten besser vorhersagen können.

Weitere Informationen zu den Preisen für Speicherplatz und Abfragen finden Sie unter Google Cloud Platform SKUs.

Preismodellzusammenfassung

In der folgenden Tabelle werden die BigQuery-Preise zusammengefasst: Die Kontingente und Limits von BigQuery gelten für diese Vorgänge.

USA (mehrere Regionen) EU (mehrere Regionen) Tokio
Monatlich
Aktion Preise Details
Aktiver Speicher Die ersten 10 GB in jedem Monat sind kostenlos. Weitere Informationen finden Sie unter Speicherpreise.
Langfristige Speicherung Die ersten 10 GB in jedem Monat sind kostenlos. Weitere Informationen finden Sie unter Speicherpreise.
Streaming-Insert-Anweisungen Abgerechnet werden die erfolgreich eingefügten Zeilen. Einzelne Zeilen werden mit einer Mindestgröße von 1 KB berechnet. Weitere Informationen finden Sie unter Streamingpreise.
Abfragen (Analyse) Das erste Terabyte (1 TB) pro Monat ist kostenlos. Weitere Informationen finden Sie unter On-Demand-Preise. Für Kunden mit großem Datenvolumen sind auch Pauschalpreise verfügbar.

Wenn Sie in einer anderen Währung als USD bezahlen, gelten die Preise, die in Cloud Platform SKUs in Ihrer Währung angegeben sind.

Abrechnung der Kosten

Jedes von Ihnen erstellte Projekt ist mit einem Rechnungskonto verknüpft. Alle Kosten, die für BigQuery-Jobs (z. B. Abfragejobs) im Rahmen eines Projekts entstehen, werden vom verknüpften Rechnungskonto abgebucht. Dies gilt auch dann, wenn es sich um gemeinsame Projektressourcen mit Personen außerhalb Ihres Unternehmens handelt. Speicherkosten für BigQuery werden ebenfalls dem verknüpften Konto in Rechnung gestellt.

Abrechnungsdaten analysieren

Auf der Seite mit den Cloud-Abrechnungsberichten in der Cloud Console erhalten Sie eine Übersicht über die BigQuery-Kosten und -Trends. Weitere Informationen zum Analysieren von Abrechnungsdaten anhand von Berichten finden Sie unter Kostentrends mit Abrechnungsberichten einsehen.

Informationen zum Analysieren der Abrechnungsdaten in BigQuery finden Sie unter Abrechnungsdaten in BigQuery exportieren in der Cloud Billing-Dokumentation.

Kostenlose Vorgänge

In der folgenden Tabelle sind die in jeder Zone kostenlosen BigQuery-Vorgänge aufgeführt. Hierfür gelten die Kontingente und Limits von BigQuery.

Aktion Details
Daten laden

Wenn Sie Daten aus Cloud Storage in BigQuery laden, werden Ihnen keine Kosten für den Ladevorgang in Rechnung gestellt. Es entstehen jedoch Kosten für die Speicherung der Daten in Cloud Storage. Weitere Informationen finden Sie auf der Seite mit den Cloud Storage-Preisen unter Datenspeicherung. Sobald die Daten in BigQuery geladen wurden, unterliegen sie den Speicherpreisen von BigQuery. Weitere Informationen finden Sie unter Daten in BigQuery laden.

Beim Erstellen eines Datasets in BigQuery müssen Sie einen Standort für die Daten auswählen. Wenn Sie US auswählen, können Sie Daten aus einem Cloud Storage-Bucket in einer beliebigen anderen Region in Tabellen in diesem Dataset laden. Werden Daten aus einer anderen Region in ein US-Dataset geladen, entstehen für den ausgehenden Internetdatenverkehr derzeit keine Kosten.

Falls Sie einen anderen Standort als US auswählen, müssen Sie einen der folgenden Schritte ausführen:

  • Daten aus einem Cloud Storage-Bucket in dieser Region laden (der Bucket kann entweder ein multiregionaler Bucket oder ein regionaler Bucket in der gleichen Region wie das Dataset sein)
  • Daten in einen Bucket in dieser Region kopieren

Wenn Sie Daten von einer Cloud Storage-Region in eine andere Region kopieren, gelten die Netzwerkpreise für Cloud Storage.

Daten kopieren Das Kopieren einer Tabelle kostet nichts, aber für das Speichern der neuen Tabelle und der Tabelle, die Sie kopiert haben, fallen Gebühren an. Weitere Informationen finden Sie unter Vorhandene Tabelle kopieren.
Daten exportieren Wenn Sie Daten aus BigQuery in Cloud Storage exportieren, werden Ihnen keine Kosten für den Exportvorgang in Rechnung gestellt. Es entstehen jedoch Kosten für die Speicherung der Daten in Cloud Storage. Weitere Informationen finden Sie auf der Seite mit den Cloud Storage-Preisen unter Datenspeicherung. Hilfreiche Informationen enthält auch der Artikel Daten aus BigQuery exportieren.
Datasets löschen Für das Löschen eines Datasets fallen keine Kosten an.
Tabellen, Ansichten und Partitionen löschen Für das Löschen von Tabellen, Ansichten oder einzelnen Tabellenpartitionen fallen keine Kosten an.
Metadatenvorgänge List-, get-, patch-, update- und delete-Aufrufe werden Ihnen nicht in Rechnung gestellt. Darunter fallen beispielsweise das Auflisten von Datasets, das Aktualisieren einer Access Control List eines Datasets oder das Aktualisieren einer Tabellenbeschreibung.

Beschränkungen der kostenlosen Nutzung

Im Rahmen der kostenlosen Stufe der Google Cloud Platform bietet BigQuery einige Ressourcen bis zu einem bestimmten Limit kostenlos an. Diese kostenlosen Nutzungskontingente sind während des kostenlosen Testzeitraums und danach verfügbar. Wenn Sie die Nutzungskontingente überschreiten und der kostenlose Testzeitraum verstrichen ist, fallen die auf dieser Seite genannten Gebühren an.

Die folgenden BigQuery-Ressourcen können kostenlos genutzt werden:

  • Die ersten 10 GB Speicher pro Monat (pro Rechnungskonto)
  • Das erste Terabyte (1 TB) an verarbeiteten Abfragedaten pro Monat (pro Rechnungskonto)

Abfragepreise

Die Abfragepreise beziehen sich auf das Ausführen der SQL-Befehle und benutzerdefinierten Funktionen. Bei BigQuery werden Abfragen mithilfe eines einzigen Messwerts abgerechnet: der Anzahl der verarbeiteten Byte. Diese werden auch als gelesene Byte bezeichnet. Unabhängig davon, ob die Daten in BigQuery oder in einer externen Datenquelle wie Cloud Storage, Google Drive oder Cloud Bigtable gespeichert sind, wird Ihnen immer die Menge der verarbeiteten Byte in Rechnung gestellt.

Beim Ausführen einer Abfrage werden Ihnen die Kosten entsprechend der verarbeiteten Gesamtdaten in den ausgewählten Spalten selbst dann in Rechnung gestellt, wenn Sie ein ausdrückliches LIMIT für die Ergebnisse festlegen. Die Gesamtanzahl der Byte pro Spalte wird basierend auf den Datentypen in den Spalten berechnet. Weitere Informationen darüber, wie die Datengröße berechnet wird, finden Sie unter Berechnung der Datengröße.

Die Abfragepreise hängen von Ihrer Nutzung ab. Sie können entweder einen monatlichen Pauschalpreis für Abfragen zahlen oder die Kosten für einzelne interaktive Abfragen. Unternehmen ziehen in der Regel Pauschalpreise für Abfragen vor, da so die Kosten jeden Monat gleich hoch sind. On-Demand-Preise (bzw. interaktive Preise) sind flexibler, da sie auf der tatsächlichen Nutzung basieren.

On-Demand-Preise

Für On-Demand-Abfragepreise gilt Folgendes:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio
Monatlich
Aktion Preise Details
Abfragen (Analyse) Das erste Terabyte (1 TB) im Monat ist kostenlos. Für Kunden mit großem Datenvolumen, die gleichbleibende monatliche Kosten vorziehen, sind auch Pauschalpreise verfügbar.

Wenn Sie in einer anderen Währung als USD bezahlen, gelten die Preise, die in Cloud Platform SKUs in Ihrer Währung angegeben sind.

Beachten Sie außerdem die folgenden Hinweise zu den Abfragegebühren:

  • Abfragen, die einen Fehler oder Ergebnisse aus dem Cache zurückgeben, werden Ihnen nicht in Rechnung gestellt.
  • Die Kosten werden auf das nächste MB aufgerundet. Dabei gilt ein Minimum von 10 MB verarbeiteter Daten pro Tabelle, auf die die Abfrage verweist, und ein Minimum von 10 MB verarbeiteter Daten pro Abfrage.
  • Durch das Abbrechen einer aktuell laufenden Abfrage entstehen möglicherweise Kosten in der vollen Höhe, die anfallen würde, wenn die Abfrage abgeschlossen worden wäre.
  • BigQuery verwendet eine spaltenbasierte Datenstruktur. Ihnen werden die Kosten entsprechend der verarbeiteten Gesamtdaten in den ausgewählten Spalten in Rechnung gestellt, wobei die Gesamtdaten pro Spalte anhand der Datentypen in der Spalte berechnet werden. Weitere Informationen zur Berechnung der Datengröße finden Sie unter Berechnung der Datengröße.

Kontrollen für On-Demand-Abfragekosten

Mit den Kostenkontrollmechanismen von BigQuery lassen sich Ihre Abfragekosten auf einen bestimmten Betrag begrenzen. Sie können Folgendes festlegen:

Pauschalpreise

BigQuery bietet Pauschalpreise für Kunden mit hohem Datenvolumen oder Geschäftskunden, die für Abfragen anstelle eines On-Demand-Preises pro TB verarbeiteter Daten einen festen monatlichen Betrag bevorzugen. Wenn Sie sich für den Pauschalpreis entscheiden, sind die Kosten für alle verarbeiteten Byte im monatlichen Pauschalpreis enthalten.

BigQuery verwaltet automatisch das Slot-Kontingent anhand von Verlauf, Nutzung und Ausgaben des Kunden. Für Kunden mit Ausgaben für Analysen in Höhe von mindestens 40.000 $ pro Monat bietet BigQuery mehrere Möglichkeiten zur Erhöhung der Anzahl von zugewiesenen Slots.

Pauschalpreis:

  • Gilt nur für Abfragekosten und nicht für die Speicherung. Weitere Informationen zu den Speicherkosten finden Sie unter Speicherpreise.
  • Gilt für alle Projekte, die mit dem Rechnungskonto verknüpft sind und für die Pauschalpreise in Anspruch genommen werden.
  • Stellt zusätzliche BigQuery-Slots bereit. Weitere Informationen finden Sie in der folgenden Tabelle.
  • Stellt zusätzliche Abfrage-Parallelität für interaktive Abfragen bereit.

USA (mehrere Regionen) EU (mehrere Regionen) Tokio
Monatlich
Monatliche Kosten Zugewiesene Slots Details
2.000 Pro 10.000 $ über dem Basispreis werden Ihnen 500 zusätzliche Slots zugewiesen.

Wenn Sie in einer anderen Währung als USD bezahlen, gelten die Preise, die in Cloud Platform SKUs in Ihrer Währung angegeben sind.

Kontaktieren Sie Ihren Vertriebsmitarbeiter, wenn Sie sich für Pauschalpreise interessieren.

Speicherpreise

Sobald Ihre Daten in BigQuery geladen wurden, wird Ihnen die Speicherung in Rechnung gestellt. Die Speicherpreise beziehen sich auf die Menge der unkomprimierten Daten, die in Ihren Tabellen gespeichert sind.

Die Datengröße wird anhand der Datentypen der einzelnen Spalten berechnet. Eine ausführliche Erläuterung dazu finden Sie unter Berechnung der Datengröße.

Aktiver Speicher

Für Daten im aktiven Speicher fallen die folgenden Kosten an:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio
Monatlich
Speichertyp Preise Details
Aktiver Speicher Die ersten 10 GB in jedem Monat sind kostenlos.

Wenn Sie in einer anderen Währung als USD bezahlen, gelten die Preise, die in Cloud Platform SKUs in Ihrer Währung angegeben sind.

Die Preise für die Speicherung werden pro MB pro Sekunde anteilig berechnet. Beispiele:

  • Bei Speicherung von 100 MB für einen halben Monat zahlen Sie 0,001 $ (ein Zehntel Cent).
  • Bei Speicherung von 500 GB für einen halben Monat zahlen Sie 5 $.
  • Bei Speicherung von 1 TB für einen ganzen Monat zahlen Sie 20 $.

Langfristige Speicherung

Wenn eine Tabelle innerhalb von 90 aufeinander folgenden Tagen nicht bearbeitet wird, reduziert sich der Preis für die Speicherung dieser Tabelle automatisch um etwa 50 %. Es kommt zu keiner Beeinträchtigung der Leistung, Langlebigkeit, Verfügbarkeit oder anderer Funktionen, wenn eine Tabelle in die Langzeitspeicherung übergeht.

Die Daten im langfristigen Speicher fallen die folgenden Kosten an:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio
Monatlich
Speichertyp Preise Details
Langfristige Speicherung Die ersten 10 GB in jedem Monat sind kostenlos.

Wird die Tabelle bearbeitet, gilt wieder der reguläre Speicherpreis und der 90-Tage-Timer wird auf null zurückgesetzt. Durch jede Aktion, bei der die Daten in einer Tabelle geändert werden, wird der Timer zurückgesetzt. Beispiele:

Aktion Details
Daten in eine Tabelle laden Jeder Lade- oder Abfragejob, bei dem Daten an eine Zieltabelle angefügt werden oder eine Zieltabelle überschrieben wird
Daten in eine Tabelle kopieren Jeder Kopierjob, bei dem Daten an eine Zieltabelle angefügt werden oder eine Zieltabelle überschrieben wird
Abfrageergebnisse in eine Tabelle schreiben Jeder Abfragejob, bei dem Daten an eine Zieltabelle angefügt werden oder eine Zieltabelle überschrieben wird
Datenbearbeitungssprache (DML) verwenden Einsatz einer DML-Anweisung, um Tabellendaten zu bearbeiten
Daten in eine Tabelle streamen Aufnahme von Daten mithilfe des API-Aufrufs tabledata.insertAll

Alle anderen Aktionen setzen den Timer nicht zurück. Dazu gehören:

  • Eine Tabelle abfragen
  • Eine Ansicht erstellen, mit der eine Tabelle abgefragt wird
  • Daten aus einer Tabelle exportieren
  • Eine Tabelle (in eine andere Zieltabelle) kopieren
  • Eine Tabellenressource patchen oder aktualisieren

Jede Partition einer partitionierten Tabelle wird separat zu den Kosten der Langzeitspeicherung berechnet. Wenn eine Partition in den letzten 90 Tagen nicht geändert wurde, werden die Daten in dieser Partition als in der Langzeitspeicherung erachtet und zum ermäßigten Tarif in Rechnung gestellt.

Für Tabellen, die den 90-Tage-Schwellenwert während eines Abrechnungszeitraums erreichen, wird der Preis entsprechend anteilig berechnet.

Die Kosten für die Langzeitspeicherung gelten nur für den BigQuery-Speicher und nicht für Daten in externen Datenquellen wie Cloud Bigtable, Cloud Storage oder Google Drive.

Berechnung der Datengröße

Beim Laden von Daten in BigQuery oder beim Abfragen von Daten werden die Kosten gemäß der Datengröße berechnet. Dazu wird die Größe des Datentyps der einzelnen Spalte herangezogen.

Die Größe der gespeicherten Daten und die Größe der Daten, die durch Ihre Abfragen verarbeitet werden, wird in Gigabyte (GB) berechnet, wobei 1 GB 230 Byte entspricht. Diese Maßeinheit wird auch als Gibibyte (GiB) bezeichnet. Ähnlich entspricht 1 TB 240 Byte, also 1.024 GB.

Die Datentypen in BigQuery haben folgende Größe:

Datentyp Größe
INT64/INTEGER 8 Byte
FLOAT64/FLOAT 8 Byte
NUMERIC 16 Byte
BOOL/BOOLEAN 1 Byte
STRING 2 Byte + UTF-8-codierte Stringgröße
BYTES 2 Byte + UTF-8-codierte Stringgröße
DATE 8 Byte
DATETIME 8 Byte
TIME 8 Byte
TIMESTAMP 8 Byte
STRUCT/RECORD 0 Byte + Größe der enthaltenen Felder

Nullwerte für jeden Datentyp werden als 0 Byte berechnet.

Eine wiederkehrende Spalte wird als Array gespeichert und die Größe wird basierend auf der Anzahl der Werte berechnet. Zum Beispiel wird eine Integer-Spalte (INT64), die wiederholt wird (ARRAY<INT64>) und vier Einträge enthält, als 32 Byte (4 Einträge × 8 Byte) berechnet.

Streamingpreise

Das Laden von Daten in BigQuery ist mit Ausnahme einer geringen Gebühr für gestreamte Daten kostenlos.

Für Streaming-Insert-Anweisungen gelten folgende Preise:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio
Monatlich
Aktion Preise Details
Streaming-Insert-Anweisungen Abgerechnet werden die erfolgreich eingefügten Zeilen. Einzelne Zeilen werden mit einer Mindestgröße von 1 KB berechnet.

Preise für die Datenbearbeitungssprache (DML)

Bei BigQuery sind DML-Abfragen basierend auf der Anzahl von Byte kostenpflichtig, die von der Abfrage verarbeitet werden.

DML-Preise für nicht partitionierte Tabellen

Bei nicht partitionierten Tabellen wird die Anzahl der verarbeiteten Byte so berechnet:

DML-Anweisung Verarbeitete Byte
INSERT Die Summe der verarbeiteten Byte für alle Spalten, auf die durch die bei der Abfrage gescannten Tabellen verwiesen wird.
UPDATE Die Summe der Byte in allen Spalten, auf die durch die bei der Abfrage gescannten Tabellen verwiesen wird
+ die Summe der Byte für alle Spalten in der aktualisierten Tabelle zu Beginn des UPDATE-Vorgangs.
DELETE Die Summe der Byte in allen Spalten, auf die durch die bei der Abfrage gescannten Tabellen verwiesen wird
+ die Summe der Byte für alle Spalten in der geänderten Tabelle zu Beginn des DELETE-Vorgangs.
MERGE Wenn die MERGE-Anweisung nur INSERT-Befehle umfasst, wird Ihnen die Summe der verarbeiteten Byte für alle Spalten, auf die durch die bei der Abfrage gescannten Tabellen verwiesen wird, in Rechnung gestellt.
Wenn die MERGE-Anweisung einen UPDATE- oder DELETE-Befehl umfasst, wird Ihnen die Summe der verarbeiteten Byte für alle Spalten, auf die durch die bei der Abfrage gescannten Tabellen verwiesen wird, in Rechnung gestellt
+ die Summe der Byte für alle Spalten in der Zieltabelle (zu Beginn des MERGE-Vorgangs).

DML-Preise für partitionierte Tabellen

Für partitionierte Tabellen wird die Anzahl der verarbeiteten Byte folgendermaßen berechnet:

DML-Anweisung Verarbeitete Byte
INSERT Die Summe der verarbeiteten Byte für alle Spalten, auf die sämtliche bei der Abfrage gescannten Partitionen verweisen.
UPDATE Die Summe der verarbeiteten Byte für alle Spalten, auf die sämtliche Partitionen für die bei der Abfrage gescannten Tabellen verweisen
+ die Summe der Byte für alle Spalten in den aktualisierten oder gescannten Partitionen für die Tabelle, die aktualisiert wird (zu Beginn des UPDATE-Vorgangs).
DELETE Die Summe der verarbeiteten Byte für alle Spalten, auf die sämtliche Partitionen für die bei der Abfrage gescannten Tabellen verweisen
+ die Summe der Byte für alle Spalten in den geänderten oder gescannten Partitionen für die Tabelle, die geändert wird (zu Beginn des DELETE-Vorgangs).
MERGE Wenn die MERGE-Anweisung nur INSERT-Befehle umfasst, wird Ihnen die Summe der verarbeiteten Byte für alle Spalten, auf die die bei der Abfrage gescannten Partitionen verweisen, in Rechnung gestellt.
Wenn die MERGE-Anweisung einen UPDATE- oder DELETE-Befehl umfasst, wird Ihnen die Summe der verarbeiteten Byte für alle Spalten, auf die sämtliche Partitionen für die bei der Abfrage gescannten Quelltabellen verweisen, in Rechnung gestellt
+ die Summe der Byte für alle Spalten in den aktualisierten, gelöschten oder gescannten Partitionen für die Zieltabelle (zu Beginn des MERGE-Vorgangs).

Preise des BigQuery Data Transfer Service

Die Gebühren für den BigQuery Data Transfer Service werden monatlich anteilsmäßig in Rechnung gestellt. Die Kosten werden wie folgt berechnet:

Quellanwendung Monatliche Gebühr (anteilig)
Google AdWords

2,50 $ für jede eindeutige Kunden-ID – ExternalCustomerIDs in der Tabelle "Customer", darunter auch Kunden-IDs ohne Impressionen

DoubleClick Campaign Manager

2,50 $ für jede eindeutige Werbetreibenden-ID – Werbetreibenden-IDs in der Tabelle "impression"

DoubleClick for Publishers

100 $ für jede Netzwerk-ID

YouTube-Kanal und YouTube-Rechteinhaber

Kostenlos bis 1. Juli 2018. Preise für YouTube werden zu einem späteren Zeitpunkt bekannt gegeben.

Nach der Übertragung von Daten in BigQuery gelten die Standardpreise für das Speichern und Abfragen in BigQuery. Weitere Informationen erhalten Sie, wenn Sie den Vertrieb kontaktieren.

Eindeutige IDs berechnen

Jede Übertragung, die Sie erstellen, generiert einen oder mehrere Durchläufe pro Tag. Bei jedem Durchlauf werden alle vorkommenden eindeutigen IDs und das jeweilige Datum gespeichert, an dem der Durchlauf abgeschlossen wurde. IDs werden nur an dem Tag gezählt, an dem die Übertragung abgeschlossen wird. Wenn beispielsweise ein Übertragungsdurchlauf am 14. Juli beginnt, aber erst am 15. Juli abgeschlossen wird, werden die eindeutigen IDs am 15. Juli gezählt.

Kommt eine eindeutige ID an einem bestimmten Tag in mehr als einem Übertragungsdurchlauf vor, wird sie nur einmal gezählt. Bei unterschiedlichen Übertragungen werden eindeutige IDs separat gezählt. Kommt eine eindeutige ID in den Durchläufen zweier unterschiedlicher Übertragungen vor, wird die ID zweimal gezählt.

Berechnung von Backfill-Gebühren

Wenn Sie einen Backfill planen, wird eine Übertragungsdurchführung für jeden Tag geplant. Ihnen werden dann die Gebühren basierend auf der unter Eindeutige IDs berechnen beschriebenen Methode in Rechnung gestellt.

Gebühren für BigQuery Data Transfer Service verhindern

Deaktivieren oder löschen Sie die Übertragung, um die Gebührenberechnung zu stoppen.

Preisbeispiele

Abfragekosten schätzen

Beispiele für Abfragepreise finden Sie unter Abfragekosten schätzen.

Speicherkosten schätzen

Beispiele für Speicherpreise finden Sie unter Speicherkosten schätzen.

Beispiele für DML-Preise für nicht partitionierte Tabellen

Die folgenden Beispiele veranschaulichen, wie BigQuery die Byte berechnet, die für DML-Anweisungen gelesen werden, mit denen nicht partitionierte Tabellen geändert werden.

Beispiel 1: UPDATE einer nicht partitionierten Tabelle

table1 enthält zwei Spalten: col1 vom Typ INTEGER und col2 vom Typ STRING

UPDATE table1 SET col1 = 1 WHERE col1 = 2;

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in col1 +
  • Summe der Anzahl Byte in col2

Beispiel 2: UPDATE einer nicht partitionierten Tabelle

table1 hat zwei Spalten: col1 vom Typ INTEGER und col2 vom Typ STRING. table2 hat eine Spalte: field1 vom Typ INTEGER.

UPDATE table1 SET col1 = 1 WHERE col1 in (SELECT field1 from table2)

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in table1.col1 vor dem UPDATE-Vorgang +
  • Summe der Anzahl Byte in table1.col2 vor dem UPDATE-Vorgang +
  • Summe der Anzahl Byte in table2.field1

Beispiele für DML-Preise für partitionierte Tabellen

Die folgenden Beispiele veranschaulichen, wie BigQuery die Byte berechnet, die für DML-Anweisungen gelesen werden, mit denen partitionierte Tabellen mit Aufnahmezeit geändert werden. Informationen zur JSON-Schemadarstellung für die in den Beispielen verwendeten Tabellen finden Sie unter In Beispielen verwendete Tabellen auf der Seite "Daten partitionierter Tabellen mithilfe von DML-Anweisungen aktualisieren".

Beispiel 1: INSERT-Vorgang einer partitionierten Tabelle mit Aufnahmezeit

mytable2 hat zwei Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mytable hat zwei Spalten: field1 vom Typ INTEGER und field2 vom Typ STRING.

INSERT INTO mytable (_PARTITIONTIME, field1) AS SELECT TIMESTAMP(DATE(ts)), id from mytable2

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable2.ts +
  • Summe der Anzahl Byte in mytable2.id

Die Größe der Tabelle mytable, in die die Zeilen eingefügt werden, hat keinen Einfluss auf die Kosten der Abfrage.

Beispiel 2: INSERT-Vorgang einer partitionierten Tabelle

mytable2 hat zwei Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mycolumntable hat vier Spalten: field1 vom Typ INTEGER, field2 vom Typ STRING, field3 vom Typ BOOLEAN und ts vom Typ TIMESTAMP.

INSERT INTO mycolumntable (ts, field1) AS SELECT ts, id from mytable2

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable2.ts +
  • Summe der Anzahl Byte in mytable2.id

Die Größe der Tabelle mycolumntable, in die die Zeilen eingefügt werden, hat keinen Einfluss auf die Kosten der Abfrage.

Beispiel 3: UPDATE-Vorgang einer partitionierten Tabelle mit Aufnahmezeit

DML-Anweisung 1: Aktualisieren einer einzelnen Partition

mytable2 hat zwei Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mytable hat zwei Spalten: field1 vom Typ INTEGER und field2 vom Typ STRING.

UPDATE project.mydataset.mytable T SET T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable2.id +
  • Summe der Anzahl Byte in mytable.field1 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mytable.field2 in der Partition "2017-05-01"

DML-Anweisung 2: Aktualisieren einer Partition basierend auf einer anderen Partition in der Tabelle

UPDATE project.mydataset.mytable T SET T._PARTITIONTIME = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT 1 from project.mydataset.mytable S WHERE S.field1 = T.field1 AND S._PARTITIONTIME = TIMESTAMP("2017-06-01") )

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable.field1 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mytable.field2 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mytable.field1 in der Partition "2017-06-01" +
  • Summe der Anzahl Byte in mytable.field2 in der Partition "2017-06-01"

Die Kosten der UPDATE-Anweisung berechnen sich in diesem Fall aus der Summe der Größen aller Felder in den Partitionen, die "2017-05-01" und "2017-06-01" entsprechen.

Beispiel 4: UPDATE-Vorgang einer partitionierten Tabelle

DML-Anweisung 1: Aktualisieren einer einzelnen Partition

mytable2 hat zwei Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mycolumntable hat vier Spalten: field1 vom Typ INTEGER, field2 vom Typ STRING, field3 vom Typ BOOLEAN und ts vom Typ TIMESTAMP.

UPDATE project.mydataset.mycolumntable T SET T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable2.id +
  • Summe der Anzahl Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.ts in der Partition "2017-05-01"

DML-Anweisung 2: Aktualisieren einer Partition basierend auf einer anderen Partition in der Tabelle

UPDATE project.mydataset.mycolumntable T SET T.ts = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT 1 from project.mydataset.mycolumntable S WHERE S.field1 = T.field1 AND DATE(S.ts) = "2017-06-01")

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.ts in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field1 in der Partition "2017-06-01" +
  • Summe der Anzahl Byte in mycolumntable.field2 in der Partition "2017-06-01" +
  • Summe der Anzahl Byte in mycolumntable.field3 in der Partition "2017-06-01" +
  • Summe der Anzahl Byte in mycolumntable.ts in der Partition "2017-06-01"

Die Kosten der UPDATE-Anweisung berechnen sich in diesem Fall aus der Summe der Größen aller Felder in den Partitionen, die "2017-05-01" und "2017-06-01" entsprechen.

Beispiel 5: DELETE-Vorgang einer partitionierten Tabelle mit Aufnahmezeit

mytable2 hat zwei Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mytable hat zwei Spalten: field1 vom Typ INTEGER und field2 vom Typ STRING.

DELETE project.mydataset.mytable T WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable2.id +
  • Summe der Anzahl Byte in mytable.field1 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mytable.field2 in der Partition "2017-05-01"

Beispiel 6: DELETE-Vorgang einer partitionierten Tabelle

mytable2 hat zwei Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mycolumntable hat vier Spalten: field1 vom Typ INTEGER, field2 vom Typ STRING, field3 vom Typ BOOLEAN und ts vom Typ TIMESTAMP.

DELETE project.mydataset.mycolumntable T WHERE DATE(T.ts) =“2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Verarbeitete Byte in diesem Beispiel =

  • Summe der Anzahl Byte in mytable2.id +
  • Summe der Anzahl Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • Summe der Anzahl Byte in mycolumntable.ts in der Partition "2017-05-01"

Preisbeispiele für BigQuery Data Transfer Service

Beispiel 1: Sie haben 1 Übertragung mit 3 Durchläufen, die am selben Tag abgeschlossen werden.

  • Im ersten Durchlauf werden die folgenden eindeutigen IDs aufgezeichnet: A, B und C
  • Im zweiten Durchlauf wird Folgendes aufgezeichnet: A
  • Im dritten Durchlauf wird Folgendes aufgezeichnet: C und D

Da alle Durchläufe am selben Tag abgeschlossen wurden, werden Ihnen Kosten basierend auf vier eindeutigen IDs (A, B, C, D) in Rechnung gestellt. Da ID A und ID C in zwei verschiedenen, am gleichen Tag abgeschlossenen Durchläufen erfasst wurden, werden die IDs A und C nur einmal gezählt. Wenn diese drei Übertragungsdurchläufe einen Monat lang jeden Tag abgeschlossen werden, werden Ihre monatlichen Kosten basierend auf vier eindeutigen IDs berechnet. Wenn die Anzahl der abgeschlossenen Übertragungsdurchläufe geringer ist als die Anzahl der Tage im Monat, werden die Kosten anteilig in Rechnung gestellt.

Beispiel 2: Sie haben mehrere Übertragungen mit Durchläufen, die am selben Tag abgeschlossen werden.

  • Übertragung 1 wird ausgeführt und zeichnet die folgenden eindeutigen IDs auf: A, B und C
  • Übertragung 2 wird ausgeführt und zeichnet Folgendes auf: A
  • Übertragung 3 wird ausgeführt und zeichnet Folgendes auf: C und D

Da die eindeutigen IDs in Durchläufen für verschiedene Übertragungen gezählt werden, werden Ihnen Kosten basierend auf sechs eindeutigen IDs berechnet – A, B und C aus den Durchläufen von Übertragung 1, A aus dem Durchlauf von Übertragung 2 sowie C und D aus dem Durchlauf von Übertragung 3. Wenn die Anzahl der abgeschlossenen Übertragungsdurchläufe geringer ist als die Anzahl der Tage im Monat, werden die Kosten anteilig in Rechnung gestellt.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...