Speicher in BigQuery optimieren

Auf dieser Seite finden Sie Best Practices zum Optimieren des BigQuery-Speichers. BigQuery speichert Daten im Spaltenformat. Spaltenorientierte Datenbanken sind für Analysearbeitslasten optimiert, die Daten aus einer sehr großen Anzahl von Datensätzen aggregieren. Da Spalten in der Regel mehr Redundanz als Zeilen haben, ermöglicht diese Eigenschaft eine größere Datenkomprimierung mithilfe von Verfahren wie der Lauflängencodierung. Weitere Informationen zum Speichern von Daten in BigQuery finden Sie unter BigQuery-Speicher. Durch die Optimierung von BigQuery-Speicher werden die Abfrageleistung verbessert und die Kosten optimiert.

BigQuery enthält Details zum Speicherverbrauch Ihrer Ressourcen. Fragen Sie die folgenden INFORMATION_SCHEMA-Ansichten ab, um die Metadaten des Tabellenspeichers aufzurufen:

Clustertabellendaten

Best Practice: Erstellen Sie geclusterte Tabellen.

Beginnen Sie zur Optimierung des Speichers für Abfragen mit dem Clustering von Tabellendaten. Durch das Clustering häufig verwendeter Spalten können Sie das Gesamtvolumen der von der Abfrage gescannten Daten reduzieren. Informationen zum Erstellen von Clustern finden Sie unter Geclusterte Tabellen erstellen und verwenden.

Partitionstabellendaten

Best Practice: Teilen Sie große Tabellen mit Partitionen auf.

Mit Partitionen können Sie Ihre Daten nach einer Reihe von definierten Spalteneigenschaften gruppieren und sortieren, z. B. eine Ganzzahlspalte, eine Spalte für eine Zeiteinheit oder die Aufnahmezeit. Partitionierung verbessert die Abfrageleistung und optimiert die Kosten, da die Anzahl der von einer Abfrage gelesenen Byte verringert wird.

Weitere Informationen zu Partitionen finden Sie unter Einführung in partitionierte Tabellen.

Einstellungen für den Tabellen- und Partitionsablauf verwenden

Best Practice: Konfigurieren Sie zum Optimieren des Speichers die Standardeinstellungen für den Ablauf von Datasets, Tabellen und partitionierten Tabellen.

Sie können die Speicherkosten kontrollieren und die Speichernutzung optimieren, wenn Sie für die neu in einem Dataset erstellten Tabellen den Standardablauf festlegen. Wenn eine Tabelle abläuft, wird sie zusammen mit allen Daten gelöscht, die die Tabelle enthält. Wenn Sie die Property beim Erstellen des Datasets festlegen, werden alle im Dataset erstellen Tabellen nach dem Ablaufzeitraum gelöscht. Wenn Sie die Property erst später festlegen, werden nur die neu erstellten Tabellen nach dem Ablaufzeitraum gelöscht.

Wenn Sie beispielsweise den Standardablauf für Tabellen auf sieben Tage setzen, werden alle Daten, die älter als eine Woche sind, automatisch gelöscht.

Diese Option ist nützlich, wenn Sie nur Zugriff auf die neuesten Daten benötigen. Sie ist auch sinnvoll, um mit Daten zu experimentieren, die nicht aufbewahrt werden müssen.

Wenn Ihre Tabellen datumspartioniert sind, gilt der Standardablauf für Tabellen des Datasets für die jeweiligen Partitionen. Sie können den Ablauf der Partition auch mit dem Flag time_partitioning_expiration im bq-Befehlszeilentool oder mit der Konfigurationseinstellung expirationMs in der API steuern. Wenn eine Partition abläuft, werden Daten in der Partition gelöscht. Die partitionierte Tabelle wird jedoch auch dann nicht gelöscht, wenn die Tabelle leer ist. Mit dem folgenden Befehl laufen Partitionen beispielsweise nach drei Tagen ab:

bq mk \
--time_partitioning_type=DAY \
--time_partitioning_expiration=259200 \
project_id:dataset.table

Daten in BigQuery speichern

Best Practice: Speichern Sie Ihre Daten in BigQuery.

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. Nachdem die Daten in BigQuery geladen wurden, unterliegen sie den Speicherpreisen von BigQuery. Ihnen werden der physische oder logische Speicher, der von Ihrer Tabelle genutzt wird, einschließlich der Speicherblöcke für die Zeitreise in Rechnung gestellt.

Nutzen Sie den Vorteil der günstigen Kosten der Langzeitspeicherung von BigQuery, statt ältere Daten mit einer anderen Speicheroption wie Cloud Storage zu exportieren.

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 hinsichtlich der Eignung für die Langzeitpreise betrachtet, und zwar nach den gleichen Regeln wie bei nicht partitionierten Tabellen.

Langfristige oder kurzfristige Daten identifizieren

Best Practice: Stellen Sie fest, ob Daten auf Zeilenebene langfristig gespeichert werden müssen, und speichern Sie nur aggregierte Daten langfristig.

In vielen Fällen sind Details, die in Transaktions- oder Zeilendaten enthalten sind, kurzfristig hilfreich, werden aber langfristig weniger referenziert. In solchen Situationen können Sie Aggregationsabfragen erstellen, um die mit diesen Daten verknüpften Messwerte zu berechnen und zu speichern. Anschließend verwenden Sie den Tabellen- oder Partitionsablauf, um die Daten auf Zeilenebene systematisch zu entfernen. Dies reduziert die Speichergebühren, während die Messwerte für die langfristige Nutzung verfügbar bleiben.

Zeitreisefenster verkürzen

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

Wenn Sie die Zeitreisetage vom Standardwert sieben verringern, wird die Gesamtzahl der für ein Objekt gespeicherten Speicherblöcke reduziert. Das Zeitreisefenster wird auf Dataset-Ebene festgelegt.

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 BigQuery-Preise in Betracht ziehen, bevor Sie Daten aus BigQuery exportieren.

Nächste Schritte