BigQuery Pricing FAQ

Das hängt vom Workload ab. Wer bei Flat-Rate ungenutzte Slots hatte, kann mit Editions plus Autoscaling die Compute-Kosten senken. Compressed Storage kann die Storage-Seite reduzieren. Betrachten Sie das Ganze als TCO, nicht als einzelnen Kostenpunkt.

Nein, die beiden sind voneinander unabhängig. Ein BigQuery-Commitment sichert Ihnen einen besseren Preis pro Slot-Stunde. Ein 3-Jahres-Commitment bringt rund 40 % Rabatt auf die Analysekosten. Storage-Preise werden nicht rabattiert.

Ja. Das Verhalten von Editions – insbesondere die Autoscaling-Minima und die einminütige Scale-down-Phase – kann die Kosten auf nicht offensichtliche Weise verändern. Führen Sie vor dem Commitment einen POC mit einem repräsentativen Workload durch.

Lang laufende, gleichmäßige Workloads, die viele Daten scannen, sind für Editions am besten geeignet. Kurze Queries mit Lastspitzen sind On-Demand meist günstiger, weil das Autoscaling Blöcke à 100 Slots zuweist und mindestens eine volle Minute abrechnet.

Das hängt von der Komprimierbarkeit ab. String-lastige Daten lassen sich gut komprimieren, Integer-lastige schlecht. In diesem GitHub-Gist finden Sie eine Query, die Ihre Optionen vergleicht: https://gist.github.com/sayle-doit/264d28dd990c478beb90b90ac3923681

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

Ja. Ein Projekt kann On-Demand laufen, ein anderes auf der Standard Edition, ein weiteres auf Enterprise. Workloads auf mehrere Projekte aufzuteilen ist einer der wirkungsvollsten Optimierungshebel, die Sie haben.

SQL läuft unverändert weiter. Code, der dynamisch Flex-Slots kauft, funktioniert allerdings nicht mehr. Terraform-Support ist in Arbeit – nutzen Sie in der Zwischenzeit ignore_changes. Ein Refactoring kann sich dennoch lohnen, um den gesamten Slot-Verbrauch zu senken.

Ja. Flat-Rate-Commitments werden für die Restlaufzeit zum vereinbarten Preis in die Enterprise Edition überführt. Slots über Ihrer Baseline werden zum Standard-Enterprise-Preis abgerechnet. Der Autoscaler skaliert bis zu einem von Ihnen festgelegten Maximum.

Nein. Googles Tooling blockiert Compressed Storage aktiv, sobald eine Flat-Rate-Reservierung existiert. Sie benötigen Editions oder reine On-Demand-Projekte.

Nach unkomprimierten. Bei Queries auf komprimierte Daten aus einem On-Demand-Projekt gibt es keinen Compute-Kostenvorteil. Die Ersparnis betrifft ausschließlich den Storage.

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

Ja. Editions-Queries unterliegen wegen der einminütigen Scale-down-Phase des Autoscalers einem Minimum von einer Minute. Eine 10-Sekunden-Query kostet eine Minute an Slots.

Öffnen Sie in der Google Cloud Console das Monitoring, gehen Sie zum Metric Explorer und suchen Sie nach Slot-Metriken. DoiT-Kunden können ein Ticket eröffnen und das Thema mit einem BigQuery-Spezialisten durchgehen.

Ja. Legen Sie eine Baseline an Slots fest, die Sie durchgehend nutzen, und ein Maximum als Obergrenze. Bei längeren Leerlaufphasen setzen Sie die Baseline auf 0, damit Sie nicht für ungenutzte zugewiesene Slots zahlen.

dbt auf BigQuery ist Compute-intensiv. Da Compute auf Editions jetzt teurer ist, kosten dbt-Workloads in der Regel mehr – es sei denn, Sie optimieren den Slot-Verbrauch und isolieren sie im passenden Projekt.

Time-Travel lässt sich nicht deaktivieren, aber Sie können das Zeitfenster von 7 auf 3 Tage verkürzen. Fail-safe kann deaktiviert werden. Eine Wiederherstellung aus dem Fail-safe erfordert ein Support-Ticket bei Google Cloud.

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