Preis

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

Die Speicherkosten hängen bei BigQuery ausschließlich von der Menge der gespeicherten Daten ab. 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 richten sich nach der durch die Abfrage verarbeiteten Datenmenge. Sie haben zwei Optionen:

  • On-Demand: Die flexibelste Option. Hier richtet sich der Preis ausschließlich nach 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.

Preismodelle

In der dieser 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 (asia-northeast1)
Monatlich
Aktion Preis Details
Aktiver Speicher Die ersten 10 GB pro Monat sind kostenlos. Weitere Informationen finden Sie unter Speicherpreise.
Langfristige Speicherung Die ersten 10 GB pro 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 dieser Tabelle sind die in jeder Region 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 aber 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 Internet-Traffic derzeit keine Kosten.

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

  • Daten aus einem Cloud Storage-Bucket in dieser Region laden (der Bucket kann entweder ein multiregionaler Bucket sein oder ein regionaler Bucket in der gleichen Region wie das Dataset)
  • 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 im Abschnitt Tabelle kopieren.
Daten exportieren Wenn Sie Daten aus BigQuery nach Cloud Storage exportieren, werden Ihnen keine Kosten für den Exportvorgang in Rechnung gestellt. Es entstehen aber Kosten für die Speicherung der Daten in Cloud Storage. Weitere Informationen finden Sie auf der Seite mit den Cloud Storage-Preisen unter Datenspeicherung. Praktische Informationen erhalten Sie auch im Artikel Tabellendaten 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 Die Aufrufe "list", "get", "patch", "update" und "delete" werden Ihnen nicht in Rechnung gestellt. Darunter fallen beispielsweise das Auflisten von Datasets, das Aktualisieren der Access Control List eines Datasets oder das Aktualisieren einer Tabellenbeschreibung.
Pseudospalten lesen Für die Abfrage dieser Pseudospalten entstehen Ihnen keine Gebühren:

_TABLE_SUFFIX – Verwendet bei der Abfrage von Platzhaltertabellen oder zum Nachbilden der Semantik für Tabellen-Decorator in Standard-SQL
_PARTITIONDATE – Verwendet bei der Abfrage von nach Aufnahmezeit partitionierten Tabellen
_PARTITIONTIME – Verwendet bei der Abfrage von nach Aufnahmezeit partitionierten Tabellen
_FILE_NAME – Verwendet bei der Abfrage von Tabellen anhand von externen Datenquellen
Metatabellen lesen Für die Abfrage dieser Metatabellen entstehen Ihnen keine Gebühren.

__PARTITIONS_SUMMARY__ – Verwendet beim Abrufen von Metadaten über Partitionen in einer partitionierten Tabelle oder einer nach Aufnahmezeit partitionierten Tabellen
__TABLES_SUMMARY__ – Verwendet beim Abrufen von Metadaten über die Tabellen und Ansichten in einem Dataset

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 auch danach verfügbar. Wenn Sie die Nutzungskontingente überschreiten und der kostenlose Testzeitraum verstrichen ist, fallen die auf dieser Seite genannten Gebühren an.

Diese BigQuery-Ressourcen können Sie kostenlos nutzen:

  • 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 von SQL-Befehlen 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.

Für eine ausgeführte Abfrage werden Ihnen Kosten entsprechend der verarbeiteten Gesamtdaten in den ausgewählten Spalten in Rechnung gestellt. Dies gilt auch dann, wenn Sie für die Ergebnisse der Abfrage ein ausdrückliches LIMIT festlegen. Die Gesamtanzahl der Byte pro Spalte wird nach dem jeweiligen Datentyp in einer Spalte 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, weil sie auf der tatsächlichen Nutzung basieren.

On-Demand-Preise

Für On-Demand-Abfragepreise gilt Folgendes:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio (asia-northeast1)
Monatlich
Aktion Preis 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 diese 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 abgefragter Tabelle und ein Minimum von 10 MB verarbeiteter Daten pro Abfrage.
  • Wird eine laufende Abfrage abgebrochen, können trotzdem Kosten entstehen. Den Umständen entsprechend können sie auch die volle Höhe einer abgeschlossenen Abfrage erreichen.
  • BigQuery verwendet eine spaltenorientierte Datenstruktur. Ihnen werden die Kosten entsprechend der verarbeiteten Gesamtdaten in den ausgewählten Spalten in Rechnung gestellt, wobei die Gesamtdaten pro Spalte anhand des Datentyps einer 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 für Geschäftskunden, die für Abfragen einen festen monatlichen Betrag bevorzugen anstatt eines On-Demand-Preises pro TB verarbeiteter Daten. 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, die gleichbleibende monatliche Analysekosten wollen, bietet BigQuery mehrere Möglichkeiten, die Anzahl der zugewiesenen Slots zu erhöhen.

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 (asia-northeast1)
Monatlich
Monatliche Kosten Anzahl der Slots Zusätzliche Slots
2.000

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 unkomprimierte Größe der Datenmengen, 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 diese Kosten an:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio (asia-northeast1)
Monatlich
Speichertyp Preis Details
Aktiver Speicher Die ersten 10 GB pro 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 und 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 aufeinanderfolgenden 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.

Für Daten im langfristigen Speicher fallen diese Kosten an:

USA (mehrere Regionen) EU (mehrere Regionen) Tokio (asia-northeast1)
Monatlich
Speichertyp Preis Details
Langfristige Speicherung Die ersten 10 GB pro 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
Datendefinitionssprache (DDL) verwenden Einsatz einer DDL-Anweisung CREATE OR REPLACE TABLE, um eine Tabelle zu ersetzen
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 bei Langzeitspeicherung separat abgerechnet. Wenn eine Partition in den letzten 90 Tagen nicht geändert wurde, gehen die Daten in dieser Partition in die Langzeitspeicherung über und werden zum ermäßigten Tarif in Rechnung gestellt.

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

Die ermäßigten 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 diese 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 mit 0 Byte berechnet.

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

Streamingpreise

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

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

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

Preisvorschau für BigQuery ML

Die Preise für BigQuery ML befinden sich in der Entwicklung. Informationen zu Preisankündigungen finden Sie auf der Produktseite von BigQuery.

Wenn Sie BigQuery on demand verwenden, richten sich Ihre BigQuery ML-Kosten derzeit nach den Daten, die von einzelnen Abfragen verarbeitet werden. Bei BigQuery ML-Abfragen ist die Menge der verarbeiteten Daten in der Regel größer als die Eingabedaten für die Anweisung CREATE MODEL. Flatrate-Kunden können ihre vorhandenen Slots für BigQuery ML bis zum 31. Juli 2019 nutzen.

Preise für die Datenbearbeitungssprache (DML)

Bei BigQuery werden DML-Abfragen anhand der bei einer Abfrage verarbeiteten Anzahl von Byte abgerechnet.

DML-Preise für nicht partitionierte Tabellen

Für nicht partitionierte Tabellen wird die Anzahl der verarbeiteten Byte so berechnet:

DML-Anweisung Verarbeitete Byte
INSERT Die Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Tabellen, die bei der Abfrage gescannt werden.
UPDATE Die Summe der Byte in allen abgefragten Spalten in allen Tabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte in allen Spalten der aktualisierten Tabelle zu Beginn des UPDATE-Vorgangs.
DELETE Die Summe der Byte in allen abgefragten Spalten in allen Tabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte in allen Spalten der geänderten Tabelle zu Beginn des DELETE-Vorgangs.
MERGE Wenn die MERGE-Anweisung nur INSERT-Befehle umfasst, entsprechen die Kosten der Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Tabellen, die bei der Abfrage gescannt werden.
Wenn die Anweisung MERGE einen Befehl UPDATE oder DELETE umfasst, entsprechen die Kosten der Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Quelltabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte in allen Spalten der Zieltabelle (zu Beginn des MERGE-Vorgangs).

DML-Preise für partitionierte Tabellen

Für partitionierte Tabellen wird die Anzahl der verarbeiteten Byte so berechnet:

DML-Anweisung Verarbeitete Byte
INSERT Die Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Partitionen, die bei der Abfrage gescannt werden.
UPDATE Die Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Partitionen der Tabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte in allen Spalten in den aktualisierten oder gescannten Partitionen der Tabelle, die aktualisiert wird (zu Beginn des UPDATE-Vorgangs).
DELETE Die Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Partitionen der Tabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte in allen Spalten in den geänderten oder gescannten Partitionen der Tabelle, die geändert wird (zu Beginn des DELETE-Vorgangs).
MERGE Wenn die MERGE-Anweisung nur INSERT-Befehle umfasst, entsprechen die Kosten der Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Partitionen, die gescannt werden.
Wenn die Anweisung MERGE einen Befehl UPDATE oder DELETE umfasst, entsprechen die Kosten der Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Partitionen der Quelltabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte in allen Spalten in den aktualisierten, gelöschten oder gescannten Partitionen der Zieltabelle (zu Beginn des MERGE-Vorgangs).

Preise für die Datendefinitionssprache (DDL)

Bei BigQuery werden DDL-Abfragen anhand der bei einer Abfrage verarbeiteten Anzahl von Byte abgerechnet. So wird die Anzahl der verarbeiteten Byte für DDL-Anweisungen berechnet:

DDL-Anweisung Verarbeitete Byte
CREATE TABLE Keine
CREATE TABLE ... AS SELECT ... Die Summe der verarbeiteten Byte in allen abgefragten Spalten in allen Tabellen, die bei der Abfrage gescannt werden.
CREATE VIEW Keine
DROP TABLE Keine
DROP VIEW Keine

Preise für geclusterte Tabellen

Wenn Sie in BigQuery geclusterte Tabellen erstellen und verwenden, hängen die Kosten davon ab, welche Datenvolumen in den Tabellen und Partitionen gespeichert werden und welche Abfragen für die Daten ausgeführt werden. Geclusterte Tabellen können Ihre Abfragekosten reduzieren. Sie bereinigen die Daten, damit nicht alle Daten von der Abfrage verarbeitet werden. Dieser Prozess wird als Blockbereinigung bezeichnet.

Blockbereinigung

BigQuery sortiert die Daten in einer geclusterten Tabelle nach den Werten in den Clustering-Spalten und organisiert sie in Blöcken.

Wenn Sie eine Abfrage senden, die einen Filter für eine geclusterte Spalte enthält, verwendet BigQuery die Clusterinformationen, um zu ermitteln, ob ein Block für die Abfrage relevante Daten enthält. So kann BigQuery ausschließlich relevante Blöcke scannen – ein Prozess, der als Blockbereinigung bezeichnet wird.

Die Preise für Abfragen richten sich nach der Anzahl der verarbeiteten Byte. Wenn Sie eine Abfrage für eine geclusterte Tabelle ausführen und die Abfrage einen Filter für die geclusterten Spalten enthält, verwendet BigQuery den Filterausdruck und die Blockmetadaten, um die von der Abfrage gescannten Blöcke zu bereinigen.

Bereinigte Blöcke werden nicht gescannt. Nur die gescannten Blöcke werden zur Berechnung der von der Abfrage verarbeiteten Byte verwendet. Die Anzahl der Byte, die von einer Abfrage für eine geclusterte Tabelle verarbeitet werden, entspricht der Summe der gelesenen Byte in den einzelnen Spalten, auf die sich die Abfrage bezieht, und zwar in allen gescannten Blöcken.

Wenn sich eine Abfrage mit mehreren Filtern mehrmals auf dieselbe geclusterte Tabelle bezieht, berechnet BigQuery die gescannten Spalten in den entsprechenden Blöcken, und zwar für jeden einzelnen Filter.

Preisbeispiel für geclusterte Tabellen

Sie haben eine geclusterte Tabelle mit dem Namen ClusteredSalesData. Die Tabelle wird nach der Spalte timestamp partitioniert und nach der Spalte customer_id geclustert. Die Daten sind in diese Blöcke unterteilt:

Partitionsbezeichner Block-ID Niedrigster Wert für customer_id im Block Höchster Wert für customer_id im Block
20160501 B1 10.000 19.999
20160501 B2 20.000 24.999
20160502 B3 15.000 17.999
20160501 B4 22.000 27.999

Sie führen die folgende Abfrage für die Tabelle aus. Die Abfrage enthält einen Filter für die Spalte customer_id.

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

Diese Abfrage:

  • Scannt die Spalten timestamp, customer_id und totalSale in den Blöcken B2 und B4.
  • Bereinigt den Block B3 aufgrund des Filterprädikats DATE(timestamp) = "2016-05-01" in der Partitionierungsspalte timestamp.
  • Bereinigt den Block B1 aufgrund des Filterprädikats customer_id BETWEEN 20000 AND 23000 in der Clustering-Spalte customer_id.

Preise für den 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 Kundennummer, also ExternalCustomerID in der Tabelle Customer, einschließlich Kundennummern ohne Impressionen

DoubleClick Campaign Manager

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

DoubleClick for Publishers

100 $ für jede Netzwerk-ID

Google Play

Kostenlos bis 31. August 2018. Gültig ab 1. September 2018:

25 $ pro eindeutigem Paketnamen in der Tabelle Installs_country

YouTube-Kanal

Kostenlos bis 31. Juli 2018. Gültig ab 1. August 2018:
5 $ pro Kanal

YouTube-Rechteinhaber

Kostenlos bis 31. Juli 2018. Gültig ab 1. August 2018:
5 $ pro 1.000 einzelne Kanäle (0,005 $ pro einzelnem Kanal), also Kanal-IDs in der Tabelle content_owner_basic_a3

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 dieselben eindeutigen 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 für jeden Tag ein Übertragungsdurchlauf geplant. Ihre Gebühren werden dann wie unter Eindeutige IDs berechnen beschrieben 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-Vorgang bei einer nicht partitionierten Tabelle

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

UPDATE table1 SET col1 = 1 WHERE col1 = 2;

Verarbeitete Byte in diesem Beispiel =

  • Anzahl Byte in col1 +
  • Anzahl Byte in col2

Beispiel 2: UPDATE-Vorgang bei einer nicht partitionierten Tabelle

table1 hat 2 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 =

  • Anzahl Byte in table1.col1 vor dem UPDATE-Vorgang +
  • Anzahl Byte in table1.col2 vor dem UPDATE-Vorgang +
  • 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 und nach Aufnahmezeit partitionierte Tabellen 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 bei einer nach Aufnahmezeit partitionierten Tabelle

mytable2 hat 2 Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mytable hat 2 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 =

  • Anzahl Byte in mytable2.ts +
  • 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 bei einer partitionierten Tabelle

mytable2 hat 2 Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mycolumntable hat 4 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 =

  • Anzahl Byte in mytable2.ts +
  • 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 bei einer nach Aufnahmezeit partitionierten Tabelle

DML-Anweisung 1: Einzelne Partition aktualisieren

mytable2 hat 2 Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mytable hat 2 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 =

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

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

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 =

  • Anzahl Byte in mytable.field1 in der Partition "2017-05-01" +
  • Anzahl Byte in mytable.field2 in der Partition "2017-05-01" +
  • Anzahl Byte in mytable.field1 in der Partition "2017-06-01" +
  • 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 bei einer partitionierten Tabelle

DML-Anweisung 1: Einzelne Partition aktualisieren

mytable2 hat 2 Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mycolumntable hat 4 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 =

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

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

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 =

  • Anzahl Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • Anzahl Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • Anzahl Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • Anzahl Byte in mycolumntable.ts in der Partition "2017-05-01" +
  • Anzahl Byte in mycolumntable.field1 in der Partition "2017-06-01" +
  • Anzahl Byte in mycolumntable.field2 in der Partition "2017-06-01" +
  • Anzahl Byte in mycolumntable.field3 in der Partition "2017-06-01" +
  • 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 bei einer nach Aufnahmezeit partitionierten Tabelle

mytable2 hat 2 Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mytable hat 2 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 =

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

Beispiel 6: DELETE-Vorgang bei einer partitionierten Tabelle

mytable2 hat 2 Spalten: id vom Typ INTEGER und ts vom Typ TIMESTAMP. mycolumntable hat 4 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 =

  • Anzahl Byte in mytable2.id +
  • Anzahl Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • Anzahl Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • Anzahl Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • 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. Bei den Durchläufen werden diese eindeutigen IDs aufgezeichnet:

  • 1. Durchlauf: A, B und C
  • 2. Durchlauf: A
  • 3. Durchlauf: C und D

Alle Durchläufe wurden am selben Tag abgeschlossen, deshalb werden Ihnen die Kosten für 4 eindeutige IDs (A, B, C, D) in Rechnung gestellt. ID A und ID C wurden zwar in zwei verschiedenen Durchläufen aufgezeichnet, da diese aber am selben Tag abgeschlossen wurden, werden die IDs A und C jeweils nur einmal gezählt. Wenn diese 3 Übertragungsdurchläufe einen Monat lang jeden Tag abgeschlossen werden, entstehen Ihnen monatliche Kosten für 4 eindeutige IDs. 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, deren Durchläufe am selben Tag abgeschlossen werden. Bei den Übertragungen werden diese eindeutigen IDs aufgezeichnet:

  • 1. Übertragung: A, B und C
  • 2. Übertragung: A
  • 3. Übertragung: C und D

Die eindeutigen IDs wurden in Durchläufen für verschiedene Übertragungen aufgezeichnet, deshalb entstehen Ihnen Kosten für 6 eindeutige IDs. Gemeint sind 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...