Kosten schätzen und kontrollieren

Auf dieser Seite werden Best Practices für die Schätzung und Kontrolle von Kosten in BigQuery beschrieben.

Die Hauptkosten in BigQuery sind die Rechenkosten für die Abfrageverarbeitung und die Speicherkosten für Daten, die in BigQuery geladen werden. BigQuery bietet zwei Arten von Preismodellen für die Abfrageverarbeitung: On-Demand- und kapazitätsbasierte Preise. Für jedes Modell gibt es unterschiedliche Best Practices zur Kostenkontrolle. Bei in BigQuery gespeicherten Daten hängen die Kosten vom für jedes Dataset konfigurierten Speicherabrechnungsmodell ab.

Wenn Sie die Kosten einzelner Abfragen im Blick behalten möchten, empfehlen wir Ihnen, zuerst die Best Practices für die Optimierung der Abfrageberechnung und die Optimierung der Speicherung zu befolgen.

In den folgenden Abschnitten werden weitere Best Practices beschrieben, mit denen Sie Ihre Abfragekosten weiter senken können.

Geschätzte Kosten vor der Ausführung einer Abfrage prüfen

Best Practice: Erstellen Sie vor dem Ausführen von Abfragen eine Vorschau, um die Kosten abzuschätzen.

Bei Verwendung des On-Demand-Preismodells werden Abfragen anhand der Anzahl der gelesenen Byte abgerechnet. So schätzen Sie die Kosten einer Abfrage vorab:

Abfragevalidierung verwenden

Wenn Sie eine Abfrage in der Google Cloud Console eingeben, überprüft die Abfragevalidierung die Abfragesyntax und liefert eine geschätzte Anzahl der gelesenen Byte. Mit dieser Information können Sie im Preisrechner die Abfragekosten einschätzen.

  • Wenn die Abfrage ungültig ist, wird bei der Abfragevalidierung eine Fehlermeldung angezeigt. Beispiel:

    Not found: Table myProject:myDataset.myTable was not found in location US

  • Wenn Ihre Abfrage gültig ist, gibt die Abfragevalidierung eine Schätzung der Anzahl an Byte an, die zum Verarbeiten der Abfrage erforderlich ist. Beispiel:

    This query will process 623.1 KiB when run.

Probelauf durchführen

So führen Sie einen Probelauf aus:

  1. Wechseln Sie zur BigQuery-Seite.

    BigQuery aufrufen

  2. Geben Sie Ihre Abfrage in den Abfrageeditor ein.

    Wenn die Abfrage gültig ist, wird automatisch ein Häkchen zusammen mit der Datenmenge angezeigt, die durch die Abfrage verarbeitet wird. Wenn die Abfrage ungültig ist, wird ein Ausrufezeichen mit einer Fehlermeldung angezeigt.

Geben Sie eine Abfrage wie die folgende zusammen mit dem Flag --dry_run ein:

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'
 

Bei einer gültigen Abfrage gibt der Befehl die folgende Antwort zurück:

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

Für einen Probelauf über die API übergeben Sie einen Abfragejob, bei dem im JobConfiguration-Typ dryRun auf true gesetzt ist.

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

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten.

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 := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

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

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten.

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());
    }
  }
}

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

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten.

// 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);
}

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

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten.

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
    'projectId' => $projectId,
]);

// Set job configs
$jobConfig = $bigQuery->query($query);
$jobConfig->useQueryCache(false);
$jobConfig->dryRun(true);

// Extract query results
$queryJob = $bigQuery->startJob($jobConfig);
$info = $queryJob->info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

Setzen Sie das Attribut QueryJobConfig.dry_run auf True. Client.query() gibt immer einen abgeschlossenen QueryJob zurück, wenn die Abfrage für einen Probelauf konfiguriert ist.

Bevor Sie dieses Beispiel ausprobieren, folgen Sie der Python-Einrichtungsanleitung in der BigQuery-Kurzanleitung zur Verwendung von Clientbibliotheken. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Python API.

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten.

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 schätzen

Wenn Sie das On-Demand-Preismodell verwenden, können Sie die Kosten für die Ausführung einer Abfrage schätzen, indem Sie die Anzahl der verarbeiteten Byte berechnen.

Berechnung der On-Demand-Abfragegröße

In den folgenden Abschnitten erfahren Sie, wie die Anzahl der Byte berechnet wird, die von den verschiedenen Abfragetypen verarbeitet werden:

Keine Abfragen ausführen, um Tabellendaten zu untersuchen

Best Practice: Führen Sie keine Abfragen aus, um Tabellendaten zu entdecken oder eine Vorschau zu erstellen.

Wenn Sie mit Daten experimentieren oder diese untersuchen, können Sie sie mit den Optionen zur Tabellenvorschau kostenlos aufrufen, ohne Ihr Kontingent zu nutzen.

In BigQuery stehen Ihnen die folgenden Optionen für eine Datenvorschau zur Verfügung:

  • Klicken Sie in der Google Cloud Console auf der Seite mit den Tabellendetails auf den Tab Vorschau, um die Daten abzufragen.
  • Verwenden Sie im bq-Befehlszeilentool den Befehl bq head und geben Sie die Anzahl der Zeilen für die Vorschau an.
  • Verwenden Sie in der API tabledata.list zum Abrufen von Tabellendaten aus einer bestimmten Gruppe von Zeilen.
  • Verwenden Sie LIMIT nicht in nicht geclusterten Tabellen. Bei nicht geclusterten Tabellen senken LIMIT-Klauseln die Rechenkosten nicht.

Anzahl der pro Abfrage abgerechneten Byte begrenzen

Best Practice:Verwenden Sie die Einstellung für maximal berechnete Bytes, um die Abfragekosten zu begrenzen, wenn Sie das On-Demand-Preismodell verwenden.

Sie können die Anzahl der berechneten Bytes für eine Abfrage mit der Einstellung für maximal berechnete Bytes begrenzen. Wenn Sie einen maximalen Wert für die berechneten Byte festlegen, wird die Anzahl der Byte, die von der Abfrage gelesen werden, vor der Abfrageausführung geschätzt. Wenn die Anzahl der geschätzten Byte die Grenze überschreitet, schlägt die Abfrage fehl, ohne dass eine Gebühr anfällt.

Bei geclusterten Tabellen liegt die Schätzung der Anzahl der Byte, die für eine Abfrage in Rechnung gestellt werden, über eine Obergrenze und kann höher sein als die tatsächliche Anzahl von Byte, die nach Ausführen der Abfrage in Rechnung gestellt werden. Wenn Sie eine Höchstmenge für abgerechnete Byte festlegen, kann die Abfrage einer geclusterten Tabelle fehlschlagen, selbst wenn die tatsächlich abgerechneten Byte die festgelegte Höchstmenge nicht überschreiten würden.

Wenn eine Abfrage aufgrund der Einstellung für maximal abgerechnete Byte fehlschlägt, wird ein Fehler wie der folgende zurückgegeben:

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

So legen Sie die maximal berechneten Byte fest:

  1. Klicken Sie im Abfrageeditor auf Mehr > Abfrageeinstellungen > Erweiterte Optionen.
  2. Geben Sie im Feld Maximale Menge abgerechneter Byte eine Ganzzahl ein.
  3. Klicken Sie auf Speichern.

Führen Sie den Befehl bq query mit dem Flag --maximum_bytes_billed aus.

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

Legen Sie das Attribut maximumBytesBilled in JobConfigurationQuery oder QueryRequest fest.

LIMIT nicht in nicht geclusterten Tabellen verwenden

Best Practice: Verwenden Sie für nicht geclusterte Tabellen nicht die LIMIT-Klausel zur Kostenkontrolle.

Bei nicht geclusterten Tabellen hat die Anwendung einer LIMIT-Klausel auf eine Abfrage keine Auswirkungen auf die Menge der gelesenen Daten. Ihnen werden damit also alle von der Abfrage in der kompletten Tabelle gelesenen Byte in Rechnung gestellt, auch wenn die Abfrage nur eine Teilmenge zurückgibt. Bei einer geclusterten Tabelle kann eine LIMIT-Klausel die Anzahl der gescannten Byte reduzieren, da der Scan beendet wird, wenn genügend Blöcke gescannt wurden, um das Ergebnis zu erhalten. Ihnen werden nur die gescannten Byte in Rechnung gestellt.

Abfrageergebnisse in Phasen erfassen

Best Practice: Erfassen Sie Abfrageergebnisse nach Möglichkeit in separaten Phasen.

Wenn Sie eine große Abfrage mit mehreren Phasen erstellen, liest BigQuery jedes Mal, wenn Sie diese ausführen, alle Daten, auf die sich die Abfrage bezieht. Bei jeder Ausführung der Abfrage werden Ihnen alle gelesenen Daten in Rechnung gestellt.

Teilen Sie stattdessen Ihre Abfrage in Phasen auf, wobei jede Phase ihre Abfrageergebnisse in eine Zieltabelle schreibt. Durch das Abfragen der kleineren Zieltabelle verringert sich die Menge der gelesenen Daten und die Kosten sinken. Der finanzielle Aufwand für die Speicherung der erfassten Ergebnisse ist deutlich geringer als der für die Verarbeitung großer Datenmengen.

Kosten für Arbeitslasten kontrollieren

In diesem Abschnitt werden Best Practices für die Kostenkontrolle innerhalb einer Arbeitslast beschrieben. Eine Arbeitslast besteht aus einer Reihe zusammenhängender Abfragen. Eine Arbeitslast kann beispielsweise eine täglich ausgeführte Datentransformationspipeline, eine Reihe von Dashboards, die von einer Gruppe von Business Analysten verwaltet werden, oder mehrere Ad-hoc-Abfragen sein, die von einer Gruppe von Data Scientists ausgeführt werden.

Google Cloud Preisrechner verwenden

Best Practice:Mit dem Google Cloud Preisrechner können Sie die monatlichen Gesamtkosten für BigQuery anhand der voraussichtlichen Nutzung schätzen. Sie können diese Schätzung dann mit Ihren tatsächlichen Kosten vergleichen, um Bereiche für die Optimierung zu ermitteln.

So schätzen Sie die Kosten im Google Cloud -Preisrechner, wenn Sie das On-Demand-Preismodell verwenden:

  1. Öffnen Sie den Google Cloud Preisrechner.
  2. Klicken Sie auf Der Schätzung hinzufügen.
  3. Wählen Sie „BigQuery“ aus.
  4. Wählen Sie für Diensttyp die Option „On-Demand“ aus.
  5. Wählen Sie den Standort aus, an dem Ihre Abfragen ausgeführt werden sollen.
  6. Geben Sie unter Abgefragte Datenmenge die geschätzten Byte ein, die beim Probelauf oder bei der Abfragevalidierung gelesen werden.
  7. Geben Sie Ihre geschätzten Speichernutzung für Aktiver Speicher, Langfristiger Speicher, Streaming-Insert-Anweisungen und Streaming-Lesevorgänge ein. Sie müssen je nach Abrechnungsmodell für die Dataset-Speicherung nur den physischen Speicher oder nur den logischen Speicher schätzen.
  8. Die Schätzung wird im Bereich Kostendetails angezeigt. Klicken Sie auf Detailansicht öffnen, um weitere Informationen zu den geschätzten Kosten zu erhalten. Sie können die Kostenschätzung auch herunterladen und teilen.

Weitere Informationen finden Sie unter On-Demand-Preise.

So schätzen Sie die Kosten im Google Cloud -Preisrechner, wenn Sie das kapazitätsbasierte Preismodell mit BigQuery-Versionen verwenden:

  1. Öffnen Sie den Google Cloud Preisrechner.
  2. Klicken Sie auf Der Schätzung hinzufügen.
  3. Wählen Sie „BigQuery“ aus.
  4. Wählen Sie für Diensttyp die Option „Versionen“ aus.
  5. Wählen Sie den Standort aus, an dem die Slots verwendet werden.
  6. Gewünschte Version auswählen
  7. Wählen Sie die Maximale Anzahl von Slots, Referenz-Slots, optional Zusicherung und Geschätzte Auslastung des Autoscalings aus.
  8. Wählen Sie den Speicherort für die Daten aus.
  9. Geben Sie Ihre geschätzten Speichernutzung für Aktiver Speicher, Langfristiger Speicher, Streaming-Insert-Anweisungen und Streaming-Lesevorgänge ein. Sie müssen je nach Abrechnungsmodell für die Dataset-Speicherung nur den physischen Speicher oder nur den logischen Speicher schätzen.
  10. Die Schätzung wird im Bereich Kostendetails angezeigt. Klicken Sie auf Detailansicht öffnen, um weitere Informationen zu den geschätzten Kosten zu erhalten. Sie können die Kostenschätzung auch herunterladen und teilen.

Weitere Informationen finden Sie unter Kapazitätsbasierte Preise.

Reservierungen und Zusicherungen verwenden

Best Practice:Verwenden Sie BigQuery-Reservierungen und ‑Verpflichtungen, um die Kosten zu kontrollieren.

Wenn Sie das On-Demand-Abrechnungsmodell verwenden, können Sie die Kosten nur durch Konfigurieren von Tageskontingenten auf Projekt- oder Nutzerebene begrenzen. Diese Kontingente erzwingen jedoch eine Obergrenze, die verhindert, dass Nutzer Abfragen über das Kontingentlimit hinaus ausführen.

Mit Slotreservierungen geben Sie die maximale Anzahl von Slots an, die für bestimmte Arbeitslasten verfügbar sind. Sie können auch Slotzusicherungen erwerben, die für einen bestimmten Zeitraum ermäßigte Preise bieten. Weitere Informationen finden Sie unter Einführung in BigQuery Reservations.

Slot-Schätzer verwenden

Best Practice:Verwenden Sie den Slot-Estimator, um die für Ihre Arbeitslasten erforderliche Anzahl von Slots zu schätzen.

Mit dem BigQuery-Slot-Schätzer können Sie die Slotkapazität auf der Grundlage historischer Leistungsmesswerte verwalten.

Außerdem können Kunden, die das On-Demand-Preismodell verwenden, beim Wechsel zu kapazitätsbasierten Preisen Empfehlungen zur Größe von Zusicherungen und Autoscaling-Reservierungen mit ähnlicher Leistung sehen.

Kosten in einem Dashboard aufrufen

Best Practice:Erstellen Sie ein Dashboard, um Ihre Cloud Billing-Daten zu analysieren, damit Sie die Nutzung von BigQuery im Blick behalten und anpassen können.

Sie können Ihre Abrechnungsdaten nach BigQuery exportieren und sie in einem Tool wie Looker Studio visualisieren. Eine Anleitung zum Erstellen eines Abrechnungsdashboards finden Sie unter Abrechnung mit BigQuery und Looker Studio visualisieren Google Cloud .

Budgets und Benachrichtigungen verwenden

Best Practice:Verwenden Sie Cloud Billing-Budgets, um Ihre BigQuery-Gebühren an einem Ort im Blick zu behalten.

Mit Cloud Billing-Budgets können Sie Ihre tatsächlichen Kosten mit Ihren geplanten Kosten vergleichen. Nachdem Sie einen Budgetbetrag festgelegt haben, legen Sie Schwellenwertregelungen für die Budgetbenachrichtigungen fest, die zum Auslösen von E-Mail-Benachrichtigungen verwendet werden. Mit E-Mail-Benachrichtigungen zu Budgets können Sie sich informieren, wie sich Ihre BigQuery-Ausgaben im Verhältnis zum Budget entwickeln.

Benutzerdefinierte Abfragequoten erstellen

Best Practice:Verwenden Sie benutzerdefinierte tägliche Abfragequoten, um die Menge der pro Tag verarbeiteten Daten zu begrenzen.

Sie können die Kosten verwalten, indem Sie ein benutzerdefiniertes Kontingent festlegen, das die Menge der pro Tag verarbeiteten Daten pro Projekt oder pro Nutzer begrenzt. Nutzer können dann keine Abfragen mehr ausführen.

Speicherkosten kontrollieren

Mit diesen Best Practices können Sie die Kosten für BigQuery-Speicherplatz optimieren. Sie können auch den Speicherplatz für die Abfrageleistung optimieren.

Langfristigen Speicher verwenden

Best Practice:Verwenden Sie Preise für die langfristige Speicherung, um die Kosten für ältere Daten zu senken.

Wenn Sie Daten in den BigQuery-Speicher laden, gelten für sie die Speicherpreise von BigQuery. Für ältere Daten können Sie automatisch die günstigen Preise für die Langzeitspeicherung in BigQuery nutzen.

Wenn Sie eine Tabelle haben, die 90 Tage lang nicht bearbeitet wurde, sinkt der Speicherpreis für diese Tabelle automatisch um 50 %. Bei einer partitionierten Tabelle wird jede Partition separat betrachtet, um für die Langzeitpreise in Frage zu kommen, und zwar nach den gleichen Regeln wie bei nicht partitionierten Tabellen.

Abrechnungsmodell für Speicher konfigurieren

Best Practice:Optimieren Sie das Abrechnungsmodell für den Speicherplatz anhand Ihrer Nutzungsmuster.

BigQuery unterstützt die Speicherabrechnung mit logischen (unkomprimierten) oder physischen (komprimierten) Byte oder einer Kombination aus beidem. Das für jedes Dataset konfigurierte Speicherabrechnungsmodell bestimmt Ihre Speicherpreise, hat aber keine Auswirkungen auf die Abfrageleistung.

Anhand der INFORMATION_SCHEMA-Ansichten können Sie das Speicherabrechnungsmodell ermitteln, das auf Grundlage Ihrer Nutzungsmuster am besten geeignet ist.

Tabellen nicht überschreiben

Best Practice:Wenn Sie das Abrechnungsmodell für physischen Speicher verwenden, sollten Sie Tabellen nicht wiederholt überschreiben.

Wenn Sie eine Tabelle überschreiben, z. B. mit dem Parameter --replace in Batchladejobs oder mit der SQL-Anweisung TRUNCATE TABLE, werden die ersetzten Daten für die Dauer der Zeitreise und des Failsafe-Zeitfensters aufbewahrt. Wenn Sie eine Tabelle häufig überschreiben, fallen zusätzliche Speicherkosten an.

Stattdessen können Sie Daten mithilfe des Parameters WRITE_APPEND in Ladejobs, der SQL-Anweisung MERGE oder der Storage Write API inkrementell in eine Tabelle laden.

Zeitreisefenster verkürzen

Best Practice:Je nach Anforderung können Sie das Zeitreisefenster verkleinern.

Wenn Sie das Zeitreisefenster vom Standardwert von sieben Tagen verringern, wird die Aufbewahrungsdauer für Daten reduziert, die aus einer Tabelle gelöscht oder in einer Tabelle geändert wurden. Ihnen wird nur dann Speicherplatz für die Zeitreise in Rechnung gestellt, wenn Sie das Abrechnungsmodell für physischen (komprimierten) Speicher verwenden.

Das Zeitreisefenster wird auf Dataset-Ebene festgelegt. Sie können das Standardzeitfenster für neue Datensätze auch mithilfe von Standardkonfigurationen festlegen.

Tabellenablauf für Zieltabellen verwenden

Best Practice: Wenn Sie große Abfrageergebnisse in eine Zieltabelle schreiben, verwenden Sie am besten die Standardablaufzeit von Tabellen, um die Daten zu löschen, sobald sie nicht mehr benötigt werden.

Das Aufbewahren großer Ergebnissets im BigQuery-Speicher ist teuer. Wenn Sie die Ergebnisse nicht dauerhaft benötigen, sollten Sie die Daten durch Festlegen der Standardablaufzeit von Tabellen automatisch löschen lassen.

Daten in Cloud Storage archivieren

Best Practice: Archivieren Sie Daten eventuell in Cloud Storage.

Sie können Daten basierend auf den geschäftlichen Anforderungen für die Archivierung von BigQuery zu Cloud Storage verschieben. Als Best Practice sollten Sie langfristige Speicherpreise und das Abrechnungsmodell für physischen Speicher in Betracht ziehen, bevor Sie Daten aus BigQuery exportieren.

Nächste Schritte