BigQuery Pricing FAQ

Das hängt von der Workload ab. Wer bei Flat-Rate ungenutzte Slots hatte, kann seine Compute-Kosten mit Editions plus Autoscaling senken. Compressed Storage reduziert zusätzlich die Storage-Kosten. Betrachten Sie es als TCO, nicht als einzelne Position.

Nein, das ist getrennt. Ein BigQuery-Commitment bringt Ihnen einen besseren Preis pro Slot-Stunde. Ein 3-Jahres-Commitment sichert rund 40 % Rabatt auf die Analysekosten. Storage-Preise sind davon ausgenommen.

Ja. Das Verhalten von Editions – vor allem die Autoscaling-Mindestgrößen und die Scale-Down-Zeit von einer Minute – kann die Kosten auf nicht offensichtliche Weise verändern. Testen Sie im POC eine repräsentative Workload, bevor Sie sich festlegen.

Lang laufende, gleichmäßige Workloads mit großem Datenvolumen sind ideal für Editions. Kurze, sprunghafte Queries sind meist auf On-Demand günstiger, weil Autoscaling in 100er-Slot-Blöcken zuweist und mindestens eine volle Minute abrechnet.

Das hängt von der Kompressibilität ab. String-lastige Daten lassen sich gut komprimieren, integer-lastige eher schlecht. In diesem GitHub Gist finden Sie eine Query, mit der Sie Ihre Optionen vergleichen können: https://gist.github.com/sayle-doit/264d28dd990c478beb90b90ac3923681

Ja. Duplizieren Sie unser BigQuery Current Usage Analysis Tool-Sheet und folgen Sie der Anleitung: https://docs.google.com/spreadsheets/d/1Sv6SzATtAyGYID2Wg0qGdcpLfe7YdOsH4dFKHHtS59c/edit

Ja. Ein Projekt kann auf On-Demand laufen, ein anderes auf Standard Edition, ein weiteres auf Enterprise. Workloads über mehrere Projekte zu verteilen, ist einer der wirksamsten Optimierungshebel überhaupt.

SQL läuft unverändert. Falls Sie Code haben, der Flex-Slots dynamisch kauft, funktioniert das nicht mehr. Terraform-Support ist in Arbeit – nutzen Sie in der Zwischenzeit ignore_changes. Ein Refactoring zur Reduktion des gesamten Slot-Verbrauchs kann sich trotzdem lohnen.

Ja. Flat-Rate-Commitments laufen für die Restlaufzeit zum vereinbarten Preis als Enterprise Edition weiter. Slots oberhalb Ihrer Baseline werden zum Standard-Enterprise-Tarif abgerechnet. Der Autoscaler kann bis zu einem von Ihnen definierten Maximum skalieren.

Nein. Das Google-Tooling blockiert Compressed Storage aktiv, sobald eine Flat-Rate-Reservierung besteht. Sie brauchen Editions oder reine On-Demand-Projekte.

Unkomprimierte. Beim Abfragen komprimierter Daten aus einem On-Demand-Projekt gibt es keinen Kostenvorteil bei Compute. Die Einsparungen betreffen ausschließlich den Storage.

Nein. Der Long-Term-Storage-Mechanismus greift weiterhin – für komprimierte wie für unkomprimierte Daten.

Ja. Editions-Queries unterliegen wegen der Scale-Down-Zeit des Autoscalers von einer Minute einer Mindestabrechnung von einer Minute. Eine Query mit 10 Sekunden Laufzeit kostet eine Minute Slots.

Öffnen Sie in der Google Cloud Console das Monitoring, wechseln Sie in den Metric Explorer und suchen Sie nach Slot-Metriken. DoiT-Kunden können ein Ticket eröffnen und das gemeinsam mit einem BigQuery-Spezialisten prüfen.

Ja. Legen Sie eine Baseline an Slots fest, die Sie durchgängig nutzen, und ein Maximum an Ihrer Komfortgrenze. Bei längeren Leerlaufphasen setzen Sie die Baseline auf 0, damit Sie nicht für ungenutzte, aber zugewiesene Slots zahlen.

dbt auf BigQuery ist compute-lastig. Compute ist auf Editions jetzt teurer, daher werden dbt-Workloads in der Regel teurer – es sei denn, Sie optimieren die Slot-Nutzung und isolieren sie im passenden Projekt.

Time-Travel lässt sich nicht deaktivieren, aber Sie können das Fenster von 7 auf 3 Tage verkürzen. Fail-Safe können Sie deaktivieren. Ein Restore aus Fail-Safe erfordert ein Google Cloud Support-Ticket.

Ja. BigLake-Metadaten-Refreshes zum Beispiel verbrauchen Slot-Stunden, scannen aber null Bytes – auf On-Demand also kostenlos. Auf Editions zahlen Sie für die Slots. Isolieren Sie solche Jobs in einem On-Demand-Projekt.