BigQuery-Preise

Die Preise für BigQuery finden Sie auf dieser Seite.

Die Preise für BigQuery ML finden Sie auf der Seite BigQuery ML – Preise.

Die Preise für BigQuery Data Transfer Service finden Sie auf der Seite BigQuery Data Transfer Service – Preise.

Übersicht über die Preisstruktur

BigQuery bietet skalierbare, flexible Preismodelle, die sich an Ihre technischen Anforderungen und Ihr Budget anpassen lassen.

Speicherkosten basieren auf der in BigQuery gespeicherten Datenmenge. Es gibt zwei Varianten:

  • Aktiv: Eine monatliche Gebühr für Daten, die in Tabellen oder Partitionen gespeichert sind und in den letzten 90 Tagen geändert wurden.
  • Langfristig: Eine niedrigere monatliche Gebühr für Daten, die in Tabellen oder Partitionen gespeichert sind und in den letzten 90 Tagen nicht geändert wurden.

Bei Abfragekosten können Sie zwischen zwei Preismodellen wählen:

  • On-Demand: Diese Option bietet die größte Flexibilität. Die Preise richten sich nach der Datenmenge, die durch die jeweils ausgeführte Abfrage verarbeitet wird.
  • Pauschal: Diese kalkulierbare Preisoption eignet sich für Kunden mit festem Budget. Pauschalpreiskunden kaufen dedizierte Ressourcen zur Abfrageverarbeitung. Die Abrechnung erfolgt also nicht pro einzeln ausgeführter Abfrage.

Weitere Informationen zu den Preisen für Speicherplatz und Abfragen finden Sie unter Google Cloud Platform SKUs. Beachten Sie, dass On-Demand-Abfragepreise auf der Seite "Google Cloud Platform SKUs" als "Analysis" (Analysepreise) bezeichnet werden.

Preismodelle

In dieser Tabelle sind die Preise für BigQuery aufgeführt. Für die genannten Vorgänge gelten die Kontingente und Limits von BigQuery.

Abrechnung der Kosten

Jedes von Ihnen erstellte Projekt ist mit einem Rechnungskonto verknüpft. Alle Kosten, die für BigQuery-Jobs im Rahmen dieses Projekts entstehen, werden vom verknüpften Rechnungskonto abgebucht. Speichergebühren für BigQuery werden ebenfalls dem verknüpften Konto in Rechnung gestellt.

Abrechnungsdaten analysieren

Sie können BigQuery-Kosten und -Trends auf der Seite mit den Cloud-Abrechnungsberichten der GCP Console aufrufen. Weitere Informationen zum Analysieren von Abrechnungsdaten anhand von Berichten finden Sie unter Abrechnungsberichte und Kostentrends ansehen.

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

Kostenlose Vorgänge

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

Vorgang 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, gelten für sie die Speicherpreise 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, der sich in einer beliebigen anderen Region befindet, in Tabellen in diesem Dataset laden. Werden Daten aus einer anderen Region in ein US-Dataset geladen, entstehen für den ausgehenden Internettraffic 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 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. Lesen Sie auch Daten aus BigQuery exportieren.
Datasets löschen Für das Löschen eines Datasets fallen keine Kosten an.
Tabellen, Ansichten, Partitionen und Funktionen löschen Für das Löschen von Tabellen, Ansichten, einzelnen Tabellenpartitionen oder benutzerdefinierten Funktionen 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, das Aktualisieren einer Tabellenbeschreibung oder das Auflisten benutzerdefinierter Funktionen in einem Dataset.
Pseudospalten lesen Für die Abfrage der folgenden Pseudospalten entstehen Ihnen keine Gebühren:
_TABLE_SUFFIX: wird bei der Abfrage von Platzhaltertabellen oder zum Nachbilden der Semantik für Tabellen-Decorators in Standard-SQL verwendet _PARTITIONDATE: wird bei der Abfrage von nach Aufnahmezeit partitionierten Tabellen verwendet _PARTITIONTIME: wird bei der Abfrage von nach Aufnahmezeit partitionierten Tabellen verwendet _FILE_NAME: wird bei der Abfrage von Tabellen basierend auf externen Datenquellen verwendet
Metatabellen lesen Für die Abfrage der folgenden Metatabellen entstehen Ihnen keine Gebühren:
__PARTITIONS_SUMMARY__: wird beim Abrufen von Metadaten über Partitionen in einer partitionierten Tabelle oder einer nach Aufnahmezeit partitionierten Tabelle verwendet __TABLES_SUMMARY__: wird beim Abrufen von Metadaten über die Tabellen und Ansichten in einem Dataset verwendet.
UDFs erstellen, ersetzen oder aufrufen Für das Erstellen, Ersetzen oder Aufrufen nichtflüchtiger benutzerdefinierter Funktionen (User-Defined Functions, UDFs) fallen keine Kosten an. Nichtflüchtige UDFs befinden sich derzeit in der Betaphase. Die Preise können sich ändern.

Limits für kostenlose 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 abgelaufen ist, fallen die auf dieser Seite genannten Gebühren an.

Ressource Monatliche Limits für kostenlose Nutzung Details
Speicher Die ersten 10 GB pro Monat sind kostenlos. Das kostenlose Speicherkontingent beinhaltet BigQuery ML-Modelle und in BigQuery gespeicherte Trainingsdaten.
Abfragen (Analyse) Das erste Terabyte (1 TB) an verarbeiteten Abfragedaten pro Monat ist kostenlos. Zum kostenlosen Analysekontingent gehören Abfragen, die in BigQuery ML Vorhersage-, Prüfungs- und Evaluierungsfunktionen nutzen. Nicht dazu gehören BigQuery ML-Abfragen, die CREATE MODEL-Anweisungen enthalten.
BigQuery bietet auch Pauschalpreise für Kunden mit hohem Datenvolumen, die für Abfragen einen festen monatlichen Betrag bevorzugen.
CREATE MODEL-Abfragen in BigQuery ML Die ersten 10 GB pro Monat an verarbeiteten Abfragedaten, die CREATE MODEL-Anweisungen enthalten, sind kostenlos. CREATE MODEL-Abfragen in BigQuery ML sind unabhängig vom kostenlosen BigQuery-Analysekontingent.

Abfragepreise

Die Abfragepreise beziehen sich auf das Ausführen von SQL-Befehlen, benutzerdefinierten Funktionen sowie bestimmten DML-Anweisungen (Data Manipulation Language – Datenbearbeitungssprache) und DDL-Anweisungen (Data Definition Language – Datendefinitionssprache).

BigQuery bietet zwei Preismodelle:

  • On-Demand-Preise: eine flexible und effiziente Option. Sie bezahlen nur für die ausgeführten Abfragen.
  • Pauschalpreise: bietet kalkulierbare und gleichbleibende monatliche Kosten.

Abfragen werden standardmäßig gemäß dem On-Demand-Preismodell abgerechnet. Wählen Sie das Preismodell aus, das Ihren Anforderungen am besten entspricht. Sie können auch beide Preismodelle für jedes Projekt und jeden Standort Ihren Anforderungen entsprechend kombinieren.

On-Demand-Preise

Bei On-Demand-Preisen werden Abfragen von BigQuery mithilfe eines einzigen Messwerts abgerechnet: die Anzahl der verarbeiteten Byte (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 immer die Menge der verarbeiteten Byte in Rechnung gestellt. Bei On-Demand-Preisen richtet sich die Abrechnung ausschließlich nach der Nutzung.

Für On-Demand-Abfragepreise gilt Folgendes:

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

  • BigQuery verwendet eine spaltenbasierte Datenstruktur. Es werden Ihnen die Kosten entsprechend den verarbeiteten Gesamtdaten in den ausgewählten Spalten in Rechnung gestellt, wobei die Gesamtdaten pro Spalte anhand der Datentypen in der Spalte berechnet werden. Unter Berechnung der Datengröße finden Sie weitere Informationen dazu.
  • 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.
  • Wird eine laufende Abfrage abgebrochen, können trotzdem Kosten entstehen. Unter Umständen können diese auch die volle Höhe einer abgeschlossenen Abfrage erreichen.
  • Beim Ausführen einer Abfrage erfolgt die Abrechnung entsprechend den Daten, die in den ausgewählten Spalten verarbeitet werden. Dies gilt auch, wenn Sie ein explizites LIMIT für die Ergebnisse festlegen.
  • Durch Partitionierung und Clustering Ihrer Tabellen können Sie die durch Abfragen verarbeitete Datenmenge reduzieren. Verwenden Sie Partitionierung und Clustering wann immer möglich.
  • On-Demand-Abfragepreise werden auf der Seite Google Cloud Platform SKUs als "Analysis" (Analysepreise) bezeichnet.

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, die für Abfragen einen festen monatlichen Betrag bevorzugen anstatt eines On-Demand-Preises pro TB verarbeiteter Daten.

Wenn Sie sich für das Pauschalpreismodell entscheiden, erwerben Sie eine bestimmte Anzahl von BigQuery-Slots für die Abfrageverarbeitung. Die Kosten für alle verarbeiteten Byte sind im monatlichen Pauschalpreis enthalten. Wenn Ihre Abfragen das im Pauschalpreis enthaltene Kontingent überschreiten, werden sie entsprechend langsamer ausgeführt, bis mehr von den im Pauschalpreis inbegriffen Ressourcen verfügbar sind.

Pauschalpreis:

  • Bezieht sich auf Abfragekosten, einschließlich DML- und DDL-Anweisungen.
  • Gilt nicht für Speicherkosten. Weitere Informationen dazu finden Sie unter Speicherpreise.
  • Wird als regionale Ressource gekauft. Die in einer bestimmten Region erworbene Pauschalpreis-Kapazität kann nicht in einer anderen Region verwendet werden.
  • Kunden haben die Möglichkeit, projektbasierte Gleichzeitigkeitskontingente über den Google Cloud Platform-Support anzufordern.
  • Ist in Form von monatlichen und jährlichen Commitments verfügbar.

Informationen zu Pauschalpreisen

Wenn Sie sich für einen Pauschalpreis entscheiden:

  • Kündigungen und Downgrades von monatlichen Commitments sind in den ersten 30 Kalendertagen nach Kaufbestätigung nicht möglich.

    Nach Ablauf der ersten 30 Kalendertage können Sie das Commitment jederzeit kündigen oder ein Downgrade durchführen. Wenn Sie ein Commitment kündigen oder ein Downgrade durchführen, werden die Kosten zum monatlichen Tarif anteilig pro Sekunde berechnet.

    Beispiel:

    • Sie können nicht am 29. Tag kündigen.
    • Wenn Sie in der ersten Sekunde des 31. Tages kündigen, werden 30 Tage und 1 Sekunde berechnet.
    • Wenn Sie in der Mitte des dritten Monats kündigen, werden 50 % des monatlichen Tarifs für diesen Monat berechnet.
  • Kündigungen und Downgrades von jährlichen Commitments sind im ersten Kalenderjahr nicht möglich.

    Jährliche Commitments können vor dem Jahrestag des Commitment-Datums für ein weiteres Jahr verlängert werden. Außerdem haben Sie die Möglichkeit, zum monatlichen Pauschaltarif zu wechseln, der nach Ablauf des jährlichen Commitments beginnt. Wenn Sie zum monatlichen Tarif wechseln, erfolgt die Abrechnung pro Sekunde zum monatlichen Tarif. Eine Kündigung ist jederzeit möglich.

    Beispiel:

    • Wenn Sie nach Ablauf des jährlichen Commitments für ein weiteres Jahr verlängern, gehen Sie ein neues jährliches Commitment ein. Die Abrechnung erfolgt weiterhin zum jährlichen Commitment-Tarif.
    • Wenn Sie nach Ablauf des jährlichen Commitments nicht für ein weiteres Jahr verlängern, erfolgt die Abrechnung anteilig pro Sekunde zum monatlichen Tarif und eine Kündigung ist jederzeit möglich.
  • Wenn Sie zusätzliche BigQuery-Slots erwerben möchten, müssen Sie ein neues Commitment eingehen.

  • Pauschalpreise werden für einen bestimmten BigQuery-Standort erworben.
    Wenn Sie einen Pauschaltarif erwerben, können Sie die Zuteilung von Slots nach Standort angeben. Möchten Sie Slots an mehreren Standorten verwenden, müssen Sie die Slots an jedem Standort erwerben.
  • Pauschalpreise und On-Demand-Preise können zusammen verwendet werden.
    Ein Projekt kann entweder mit Pauschalpreisen oder mit On-Demand-Preisen abgerechnet werden. Wenn Sie mehrere Projekte an einem bestimmten Standort haben, können Sie festlegen, welche Projekte Pauschalpreise und welche Projekte On-Demand-Preise verwenden.
  • Um einen Pauschaltarif zu beenden, müssen Sie das Commitment kündigen oder ein Downgrade durchführen.

Monatlicher Pauschalpreis

Wenn Sie sich für den Pauschalpreis anmelden, wird die erworbene Kapazität in BigQuery-Slots gemessen. Die folgende Tabelle zeigt die Anzahl der Slots, die Sie entsprechend Ihrem monatlichen Pauschalpreis erhalten.

Jährlicher Pauschalpreis

Wenn Sie sich für den Pauschalpreis anmelden, wird die erworbene Kapazität in BigQuery-Slots gemessen. Die folgende Tabelle zeigt die Anzahl der Slots, die Sie entsprechend Ihrem jährlichen Pauschalpreis erhalten. Wenn Sie sich für einen jährlichen Pauschaltarif entscheiden, erfolgt die Rechnungsstellung monatlich.

Der Kauf von Slots für monatliche und jährliche Commitments befindet sich derzeit in der Alphaphase. Wenn Sie an der Alphaphase teilnehmen möchten, füllen Sie dieses Formular aus.

Für Kunden, die bereits einen Pauschaltarif haben und diesen beibehalten möchten, ändert sich nichts. Wenn Sie Ihren Pauschaltarif beibehalten möchten, wenden Sie sich an Ihren Vertriebsmitarbeiter.

Speicherpreise

Nachdem 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 in den 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:

Die Preise für 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 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:

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

Vorgang 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" zum Ersetzen einer Tabelle.
Daten in eine Tabelle streamen Aufnahme von Daten mithilfe des API-Aufrufs tabledata.insertAll.

Alle anderen Vorgänge 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 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.

BigQuery Storage API – Preise

Für die BigQuery Storage API gilt ein On-Demand-Preismodell. Ihnen werden die gelesenen Daten in Rechnung gestellt. Kunden, die sich für den Pauschalpreis entschieden haben, können mit der BigQuery Storage API bis zu 300 TB an Daten pro Monat kostenlos lesen. Für Lesevorgänge, die die 300 TB pro Monat übersteigen, wird der On-Demand-Preis berechnet.

On-Demand-Preise

Bei der Abrechnung nach On-Demand-Preisen basieren die Kosten für die BigQuery Storage API auf der Anzahl der Byte, die durch Aufrufe von ReadRows aus dem BigQuery-Speicher gelesen werden.

Die Zahl der gelesenen Byte beinhaltet auch Daten, die für das Filtern verwendet, aber nicht als Ausgabe von ReadRows an Sie zurückgegeben werden. Für Daten, die aus temporären Tabellen gelesen werden, müssen Sie nichts bezahlen.

Für die On-Demand BigQuery Storage API fallen folgende Kosten an:

Beachten Sie außerdem diese Hinweise zu den BigQuery Storage API-Kosten:

  • Ihnen wird die gesamte gelesene Datenmenge in Rechnung gestellt. Die insgesamt pro Spalte gelesenen Daten werden anhand des Datentyps in der Spalte berechnet und die Datengröße wird ebenfalls anhand des Datentyps in der Spalte ermittelt. Eine ausführliche Erläuterung dazu finden Sie unter Berechnung der Datengröße.
  • Ihnen werden alle während einer Lesesitzung gelesenen Daten in Rechnung gestellt, auch wenn ein ReadRows-Aufruf fehlschlägt.
  • Wenn Sie einen ReadRows-Aufruf abbrechen, bevor das Ende des Streams erreicht ist, werden Ihnen alle Daten in Rechnung gestellt, die bis dahin gelesen wurden. Dies betrifft auch Daten, die vor dem Abbruch des ReadRows-Aufrufs gelesen, aber nicht an Sie zurückgegeben wurden.
  • Sie sollten wann immer möglich partitionierte und geclusterte Tabellen verwenden. Sie können die gelesene Datenmenge reduzieren, indem Sie Partitionen mit einer WHERE-Klausel bereinigen. Weitere Informationen finden Sie unter Partitionierte Tabellen abfragen.

Berechnung der Datengröße

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

Die Größe der gespeicherten Daten und die Größe der Daten, die durch Ihre Abfragen verarbeitet werden, werden in Gigabyte (GB) berechnet. 1 GB entspricht dabei 230 Byte. 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ößen:

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 + die Anzahl von Byte im Feld "Value" (Wert)
DATE 8 Byte
DATETIME 8 Byte
TIME 8 Byte
TIMESTAMP 8 Byte
STRUCT/RECORD 0 Byte + Größe der enthaltenen Felder
GEOGRAPHY 16 Byte + 24 Byte × die Anzahl der Eckpunkte im Geography-Typ (die Anzahl der Eckpunkte können Sie mit der Funktion ST_NumPointsprüfen)

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

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

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:

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 für alle referenzierten Spalten in den Tabellen, die bei der Abfrage gescannt werden.
UPDATE Die Summe der Byte für alle referenzierten Spalten in den Tabellen, die bei der Abfrage gescannt werden
+ die Summe der Byte für alle Spalten in der aktualisierten Tabelle zu Beginn des UPDATE-Vorgangs.
DELETE Die Summe der Byte für alle referenzierten Spalten in den Tabellen, die bei der Abfrage gescannt werden
+ 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, entsprechen die Kosten der Summe der verarbeiteten Byte für alle referenzierten Spalten in allen Tabellen, die bei der Abfrage gescannt werden.
Wenn die MERGE-Anweisung UPDATE- oder DELETE-Befehle umfasst, entsprechen die Kosten der Summe der verarbeiteten Byte für alle referenzierten Spalten in den Quelltabellen, die bei der Abfrage gescannt werden
+ 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 wie folgt berechnet:

DML-Anweisung Verarbeitete Byte
INSERT Die Summe der verarbeiteten Byte für alle referenzierten Spalten in allen Partitionen, die bei der Abfrage gescannt werden.
UPDATE Die Summe der verarbeiteten Byte für alle referenzierten Spalten in allen Partitionen für die Tabellen, die bei der Abfrage gescannt werden
+ 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 referenzierten Spalten in allen Partitionen, die bei der Abfrage gescannt werden
+ 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, entsprechen die Kosten der Summe der verarbeiteten Byte für alle referenzierten Spalten in allen Partitionen, die gescannt werden.
Wenn die MERGE-Anweisung UPDATE- oder DELETE-Befehle enthält, entsprechen die Kosten der Summe der verarbeiteten Byte für alle referenzierten Spalten in allen Partitionen der Quelltabellen, die bei der Abfrage gescannt werden
+ 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 für die Datendefinitionssprache (DDL)

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

DDL-Anweisung Verarbeitete Byte
CREATE TABLE
CREATE TABLE ... AS SELECT ... Die Summe der verarbeiteten Byte für alle referenzierten Spalten in den Tabellen, die bei der Abfrage gescannt werden.
CREATE VIEW
DROP TABLE
DROP VIEW

Preise für geclusterte Tabellen

Wenn Sie in BigQuery geclusterte Tabellen erstellen und verwenden, hängen die Kosten davon ab, welches Datenvolumen in den Tabellen gespeichert wird und welche Abfragen für die Daten ausgeführt werden. Geclusterte Tabellen können Ihre Abfragekosten reduzieren, weil darin Daten bereinigt werden, 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.

Preise für Skripts

Während der Betaphase für BigQuery-Skripts sollten Sie Projekte mit Pauschalreservierungen verwenden, um ungeplante Abfragekosten zu vermeiden. Das liegt daran, dass die Anzahl der von einem Skript gescannten Byte vor der Ausführung gewöhnlich nicht bekannt ist. Alternativ können Sie die BigQuery-Sandbox nutzen, damit Sie Skripts unbegrenzt kostenlos ausführen können. Das BigQuery-Team wird im Laufe der Zeit eine detailliertere Kontrolle über die Gesamtzahl der Byte bieten, die von Skripts oder einzelnen Anweisungen in den Skripts gescannt werden. Dies ist ein Betarelease. Neuigkeiten zu den Preisen finden Sie in den Versionshinweisen zu BigQuery.

Schlägt ein Skript fehl, werden die Kosten berechnet, die bis zu diesem Zeitpunkt für Anweisungen angefallen sind. Für die fehlgeschlagene Anweisung entstehen Ihnen keine Kosten.

Für veröffentlichte Anweisungstypen wie SELECT, INSERT, UPDATE usw. gelten die Preise für die Ausführung der Anweisung, die in der Dokumentation zur öffentlichen Preisgestaltung angegeben sind. Für skriptspezifische Anweisungstypen werden folgende Preise berechnet:

  • DECLARE: die Summe der Byte, die für alle im Ausdruck DEFAULT referenzierten Tabellen gescannt wurden. Für Anweisungen vom Typ DECLARE, bei dem keine Tabellen referenziert werden, fallen keine Kosten an.
  • SET: die Summe der Byte, die für alle im Ausdruck referenzierten Tabellen gescannt wurden. Für Anweisungen vom Typ SET, bei dem keine Tabellen referenziert werden, fallen keine Kosten an.
  • IF: die Summe der Byte, die für alle im Bedingungsausdruck referenzierten Tabellen gescannt wurden. Für Bedingungsausdrücke vom Typ IF, bei dem keine Tabellen referenziert werden, fallen keine Kosten an. Für Anweisungen im IF-Block, die nicht ausgeführt werden, fallen keine Kosten an.
  • WHILE: die Summe der Byte, die für alle im Bedingungsausdruck referenzierten Tabellen gescannt wurden. Für Anweisungen vom Typ WHILE, bei dem keine Tabellen referenziert werden, fallen keine Kosten an. Für Anweisungen im WHILE-Block, die nicht ausgeführt werden, fallen keine Kosten an.
  • CONTINUE/ITERATE: keine verbundenen Kosten.
  • BREAK/LEAVE: keine verbundenen Kosten.
  • BEGIN/END: keine verbundenen Kosten.

Bei temporären Tabellen fallen während der Ausführung des Skripts keine Kosten für die Speicherung an. Für alle Anweisungen, nach denen die Tabellen erstellt, geändert oder abgefragt werden, werden jedoch die üblichen Preise berechnet.

BigQuery – 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 bei nicht partitionierten 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 hat zwei Spalten: col1 vom Typ INTEGER und col2 vom Typ STRING.

UPDATE table1 SET col1 = 1 WHERE col2 = 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 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 =

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

Beispiele für DML-Preise bei partitionierten 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. Auf der Seite "Daten partitionierter Tabellen mithilfe von DML-Anweisungen aktualisieren" finden Sie Informationen zur JSON-Schemadarstellung für die In Beispielen verwendeten Tabellen.

Beispiel 1: INSERT-Vorgang bei einer nach Aufnahmezeit partitionierten Tabelle

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 =

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

Die Größe der Tabelle mytable, in die die Zeilen eingefügt werden, wirkt sich nicht auf die Abfragekosten aus.

Beispiel 2: INSERT-Vorgang bei 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 =

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

Die Größe der Tabelle mycolumntable, in die die Zeilen eingefügt werden, wirkt sich nicht auf die Abfragekosten aus.

Beispiel 3: UPDATE-Vorgang bei einer nach Aufnahmezeit partitionierten Tabelle

DML-Anweisung 1: Einzelne Partition aktualisieren

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 =

  • die Summe der Anzahl der Byte in mytable2.id +
  • die Summe der Anzahl der Byte in mytable.field1 in der Partition "2017-05-01" +
  • die Summe der Anzahl der 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 =

  • die Summe der Anzahl der Byte in mytable.field1 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mytable.field2 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mytable.field1 in der Partition "2017-06-01" +
  • die Summe der Anzahl der 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 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 =

  • die Summe der Anzahl der Byte in mytable2.id +
  • die Summe der Anzahl der Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • die Summe der Anzahl der 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 =

  • die Summe der Anzahl der Byte in mycolumntable.field1 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field2 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field3 in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mycolumntable.ts in der Partition "2017-05-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field1 in der Partition "2017-06-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field2 in der Partition "2017-06-01" +
  • die Summe der Anzahl der Byte in mycolumntable.field3 in der Partition "2017-06-01" +
  • die Summe der Anzahl der 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 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 =

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

Beispiel 6: DELETE-Vorgang bei 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 =

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

Preisbeispiel für geclusterte Tabellen

Sie haben eine geclusterte Tabelle mit dem Namen ClusteredSalesData. Diese Tabelle ist nach der Spalte timestamp partitioniert und nach der Spalte customer_id geclustert. Die Daten sind in folgende 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 bewirkt Folgendes:

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

Preisbeispiel für Skripts

Im folgenden Beispielskript befinden sich über den einzelnen Anweisungen Kommentare, in denen erläutert wird, welche Kosten ggf. durch die folgende Anweisung anfallen.

-- No cost, since no tables are referenced.
DECLARE x DATE DEFAULT CURRENT_DATE();
-- Incurs the cost of scanning string_col from dataset.table.
DECLARE y STRING DEFAULT (SELECT MAX(string_col) FROM dataset.table);
-- Incurs the cost of copying the data from dataset.big_table.  Once the
-- table is created, you are not charged for storage while the rest of the
-- script runs.
CREATE TEMP TABLE t AS SELECT * FROM dataset.big_table;
-- Incurs the cost of scanning column1 from temporary table t.
SELECT column1 FROM t;
-- No cost, since y = 'foo' doesn't reference a table.
IF y = 'foo' THEN
  -- Incurs the cost of scanning all columns from dataset.other_table, if
  -- y was equal to 'foo', or otherwise no cost since it is not executed.
  SELECT * FROM dataset.other_table;
ELSE
  -- Incurs the cost of scanning all columns from dataset.different_table, if
  -- y was not equal to 'foo', or otherwise no cost since it is not executed.
  UPDATE dataset.different_table
  SET col = 10
  WHERE true;
END IF;
-- Incurs the cost of scanning date_col from dataset.table for each
-- iteration of the loop.
WHILE x < (SELECT MIN(date_col) FROM dataset.table) DO
  -- No cost, since the expression does not reference any tables.
  SET x = DATE_ADD(x, INTERVAL 1 DAY);
  -- No cost, since the expression does not reference any tables.
  IF true THEN
    -- LEAVE has no associated cost.
    LEAVE;
  END IF;
  -- Never executed, since the IF branch is always taken, so does not incur
  -- a cost.
  SELECT * FROM dataset.big_table;
END WHILE;
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...