Speicher- und Abfragekosten kalkulieren

On-Demand-Abfragen werden nach der Anzahl der gelesenen Byte berechnet. Informationen zu den aktuellen Preisen für On-Demand-Abfragen finden Sie auf der Seite "Preise".

Mithilfe einer der folgenden Möglichkeiten können Sie die Kosten einer Abfrage vorab schätzen:

  • Abfragevalidierung in der Cloud Console
  • Flag --dry_run im bq-Befehlszeilentool
  • Parameter dryRun beim Senden eines Abfragejobs über die API
  • Google Cloud-Preisrechner
  • Clientbibliotheken

Abfragekosten schätzen

So schätzen Sie Abfragekosten:

Console

Wenn Sie eine Abfrage in der Cloud Console eingeben, überprüft die Abfragevalidierung die Abfragesyntax und liefert die geschätzte Anzahl der gelesenen Byte. Anhand dieser Informationen lassen sich die Abfragekosten im Preisrechner ermitteln.

Abfragevalidierung

bq

Wenn Sie eine Abfrage mit dem bq-Befehlszeilentool ausführen, können Sie mit dem Flag --dry_run die Anzahl der gelesenen Byte schätzen. Anhand dieser Informationen lassen sich die Abfragekosten im Preisrechner ermitteln.

Eine bq-Tool-Abfrage mit dem Flag --dry_run sieht in etwa so aus:

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
  column1,
  column2,
  column3
FROM
  `project_id.dataset.table`
LIMIT
  1000'

Die Antwort für den ausgeführten Befehl enthält dann die geschätzten gelesenen Byte: Query successfully validated. Assuming the tables are not modified, running this query will process 10918 bytes of data.

API

Für einen Probelauf über die API übergeben Sie einen Abfragejob, bei dem dryRun auf true gesetzt wurde.

go

Bevor Sie dieses Beispiel ausprobieren, folgen Sie den Schritten zur Einrichtung von Go in der BigQuery-Kurzanleitung: Clientbibliotheken verwenden. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Go API.

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

Java

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von Java in der BigQuery-Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur BigQuery Java API.

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

Node.js

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von Node.js in der BigQuery-Kurzanleitung: Clientbibliotheken verwenden. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Node.js API.

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

Python

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von Python in der BigQuery-Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur  Python API.

Für einen Probelauf mit der Python-Clientbibliothek legen Sie das Attribut QueryJobConfig.dry_run auf True fest. Client.query() gibt immer einen abgeschlossenen QueryJob zurück, wenn die Abfrage für einen Probelauf konfiguriert ist.
from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

Abfragekosten mit dem Google Cloud-Preisrechner schätzen

Geben Sie zum Schätzen der Kosten für On-Demand-Abfragen im Google Cloud-Preisrechner die Anzahl der von der Abfrage verarbeiteten Byte in B, KB, MB, GB, TB oder TB ein. Wenn durch die Abfrage weniger als 1 TB verarbeitet wird, ergibt die Schätzung 0, da BigQuery pro Monat 1 TB an On-Demand-Abfrageverarbeitung zur Verfügung stellt.

Preisrechner

So schätzen Sie die Kosten einer Abfrage mit dem Preisrechner:

  1. Öffnen Sie den Google Cloud-Preisrechner,
  2. Klicken Sie auf "BigQuery".
  3. Klicken Sie auf den Tab On-Demand.
  4. Geben Sie bei Tabellenname den Namen der Tabelle ein. Beispiel: airports.
  5. Geben Sie unter Speicherpreis im Feld Speicher den Wert 0 ein.
  6. Geben Sie bei Abfragepreis die geschätzten Byte ein, die beim Probelauf oder bei der Abfragevalidierung gelesen werden. Preisrechner
  7. Klicken Sie auf Der Schätzung hinzufügen.
  8. Die Schätzung wird auf der rechten Seite angezeigt. Sie können die Schätzung speichern oder per E-Mail senden. On-Demand-Rechner

In diesem Fall liegt die Anzahl der von der Abfrage gelesenen Byte unter der On-Demand-Verarbeitung von 1 TB, die als kostenloses Kontingent bereitgestellt wird. Infolgedessen betragen die geschätzten Kosten 0 $.

Pauschalpreise im Preisrechner berücksichtigen

Wenn für Ihr Rechnungskonto Pauschalpreise gelten, können Sie auf den Tab Pauschalpreis klicken, Ihren Tarif auswählen und der Schätzung die Speicherkosten hinzufügen.

Pauschalpreisrechner

Weitere Informationen finden Sie unter Pauschalpreise.

Speicherkosten mit dem Google Cloud-Preisrechner schätzen

Zum Schätzen der Speicherkosten im Google Cloud-Preisrechner, geben Sie den Umfang der gespeicherten Byte in B, KB, MB, GB, TB oder PB ein. In BigQuery stehen Ihnen monatlich 10 GB Speicherplatz kostenlos zur Verfügung.

So schätzen Sie die Speicherkosten mit dem Preisrechner:

  1. Öffnen Sie den Google Cloud-Preisrechner,
  2. Klicken Sie auf "BigQuery".
  3. Klicken Sie auf den Tab On-Demand.
  4. Geben Sie bei Tabellenname den Namen der Tabelle ein. Beispiel: airports.
  5. Geben Sie unter Speicherpreis im Feld Speicher den Wert 100 ein. Belassen Sie die Maßeinheit bei GB.
  6. Klicken Sie auf Der Schätzung hinzufügen.
  7. Die Schätzung wird auf der rechten Seite angezeigt. Sie können die Schätzung speichern oder per E-Mail senden. Preisrechner

Berechnung der Abfragegröße

In diesem Abschnitt wird beschrieben, wie Sie die Anzahl der Byte, die von verschiedenen Abfragetypen verarbeitet wurden, mit dem On-Demand-Abrechnungsmodell berechnen.

DML-Anweisungen

Wenn Sie die On-Demand-Abrechnung verwenden, berechnet BigQuery die Kosten für DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) basierend auf der Anzahl der Byte, die von der Anweisung verarbeitet werden.

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,
+ der Summe der Byte für alle Spalten in der Zieltabelle (zu Beginn des MERGE-Vorgangs).

Für 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 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,
+ der Summe der Byte für alle Spalten in den aktualisierten, gelöschten oder gescannten Partitionen für die Zieltabelle (zu Beginn des MERGE-Vorgangs).

DDL-Anweisungen

Wenn Sie die On-Demand-Abrechnung verwenden, berechnet BigQuery DDL-Abfragen (Data Definition Language, Datendefinitionssprache) anhand der Anzahl der von der Abfrage verarbeiteten Byte.

DDL-Anweisung Verarbeitete Byte
CREATE TABLE Keine
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 Keine
DROP TABLE Keine
DROP VIEW

Skripterstellung

Wenn Sie die On-Demand-Abrechnung verwenden, berechnet BigQuery die Skripterstellung basierend auf der Anzahl der während der Ausführung des Skripts verarbeiteten Byte.

Die folgenden Preise gelten für skriptspezifische Anweisungstypen:

  • DECLARE: die Summe der Byte, die für alle im Ausdruck DEFAULT referenzierten Tabellen gescannt wurden. Für DECLARE-Anweisungen, bei denen 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 SET-Anweisungen, bei denen 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 IF-Bedingungsausdrücke, bei denen 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 WHILE-Anweisungen, bei denen keine Tabellen referenziert werden, fallen keine Kosten an. Für Anweisungen im WHILE-Block, die nicht ausgeführt werden, fallen keine Kosten an.
  • CONTINUE oder ITERATE: nicht mit Kosten verbunden.
  • BREAK oder LEAVE: nicht mit Kosten verbunden.
  • BEGIN oder END: nicht mit Kosten verbunden.

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.

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

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;

Geclusterte Tabellen

Mit geclusterten Tabellen können Sie 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 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. So kann BigQuery ausschließlich relevante Blöcke scannen.

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. 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 10000 19999
20160501 B2 20000 24999
20160502 B3 15000 17999
20160501 B4 22000 27999

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.

Abfragen von Spaltenformaten in Cloud Storage

Wenn Ihre externen Daten in ORC oder Parquet gespeichert sind, wird die Anzahl der berechneten Byte auf die von BigQuery gelesenen Spalten beschränkt. Da die Datentypen aus einer externen Datenquelle von der Abfrage in BigQuery-Datentypen konvertiert werden, wird die Anzahl der gelesenen Byte basierend auf der Größe der BigQuery-Datentypen berechnet. Informationen zu Datentypen und -konvertierungen finden Sie auf den folgenden Seiten: