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.

Überblick

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 jede 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 der SKUs als Analysepreise bezeichnet werden.

Preismodelle

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

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Vorgang Preise 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.
BigQuery Storage API Die BigQuery Storage API ist in der kostenlosen Stufe nicht enthalten.
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 (On-Demand) Das erste Terabyte (1 TB) pro Monat ist kostenlos. Weitere Informationen finden Sie unter On-Demand-Preise.
Abfragen (monatlicher Pauschalpreis) Sie können zusätzliche Slots in Schritten von 500 erwerben. Weitere Informationen finden Sie unter Monatlicher Pauschalpreis.
Abfragen (jährlicher Pauschalpreis) Sie können zusätzliche Slots in Schritten von 500 erwerben. Die Rechnungsstellung erfolgt monatlich. Weitere Informationen finden Sie unter Jährlicher Pauschalpreis.

Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre 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

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

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

Kostenlose Vorgänge

In folgender 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 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. Lesen Sie auch 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 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: 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 dieser 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.

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
Speicherplatz 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. Das kostenlose Analysekontingent umfasst Abfragen, die in BigQuery ML Vorhersage-, Prüfungs- und Bewertungsfunktionen nutzen. Für BigQuery ML-Abfragen, die CREATE MODEL-Anweisungen enthalten, gilt dies nicht.
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 an verarbeiteten Daten von Abfragen, die CREATE MODEL-Anweisungen enthalten, pro Monat 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 (Datenbearbeitungssprache) und DDL-Anweisungen (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:

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Vorgang Preise Details
Abfragen (On-Demand) 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 US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

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 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 in die Warteschlange gestellt, bis die im Pauschalpreis enthaltenen Ressourcen verfügbar sind.

Pauschalpreis:

  • Bezieht sich auf Abfragekosten, einschließlich DML- und DDL-Anweisungen.
  • Bezieht sich nicht auf 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 vom 31. Tag 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, vor Jahresende zum monatlichen Pauschaltarif zu wechseln. 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. Zum Verwenden von Slots an mehreren Standorten 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 basierend auf Ihrem monatlichen Pauschalpreis erhalten.

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Monatliche Kosten Anzahl der Slots
500

Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

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 basierend auf Ihrem jährlichen Pauschalpreis erhalten. Wenn Sie sich für einen jährlichen Pauschaltarif entscheiden, erfolgt die Rechnungsstellung monatlich.

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Monatliche Kosten Anzahl der Slots
500

Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

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:

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Speichertyp Preise Details
Aktiver Speicher Die ersten 10 GB pro Monat sind kostenlos.

Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre 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 $.
  • 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) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Speichertyp Preise 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 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", um eine Tabelle zu ersetzen.
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 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.

BigQuery Storage API – Preise

Die Preise der BigQuery Storage API richten sich nach den Daten, die einem Stream während der ReadRows-Streamingvorgänge zugeordnet werden. Die Kosten werden entsprechend der Größe der eingehenden Daten, nicht der übertragenen Byte, berechnet.

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.

On-Demand-Preise

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

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Preise Details
Die BigQuery Storage API ist in der kostenlosen Stufe nicht enthalten.

Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

Pauschalpreise

Kunden, die sich für den Pauschalpreis entschieden haben, können derzeit die BigQuery Storage API nutzen, um bis zu 300 TB Daten pro Monat kostenlos zu lesen. Für Lesevorgänge, die die 300 TB pro Monat übersteigen, wird der On-Demand-Preis berechnet.

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, 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 + 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
GEOGRAPHY 16 Byte + 24 Byte * die Anzahl der Vertices im Geography-Typ (die Anzahl der Vertices können Sie mit der Funktion ST_NumPoints prüfen)

Nullwerte werden für jeden Datentyp 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 4 Einträge enthält, 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 die folgenden Preise:

USA (mehrere Regionen) EU (mehrere Regionen) Los Angeles (us-west2) Montreal (northamerica-northeast1) Northern Virginia (us-east4) São Paulo (southamerica-east1) Finnland (europe-north1) London (europe-west2) Zürich (europe-west6) Hongkong (asia-east2) Mumbai (asia-south1) Taiwan (asia-east1) Tokio (asia-northeast1) Singapur (asia-southeast1) Sydney (australia-southeast1)
Monatlich
Vorgang 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 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, welches Datenvolumen in den Tabellen gespeichert 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.

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 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 zwei 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 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 =

  • 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. 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 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 zwei 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 zwei 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 zwei 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 zwei 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 zwei 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"

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 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 Partitionierungsspalte timestamp.
  • Sie bereinigt den Block B1 aufgrund des Filterprädikats customer_id BETWEEN 20000 AND 23000 in der Clustering-Spalte customer_id.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...