Der Wechsel auf Physical Storage in BigQuery kann bares Geld sparen – aber Vorsicht bei den Kosten für Time Travel und Fail-safe Storage. Wir zeigen Ihnen, wie diese Funktionen Ihre Rechnung aufblähen können und welche Möglichkeiten Sie haben, das zu vermeiden: etwa indem Sie das Time-Travel-Fenster verkürzen oder vor dem Löschen von Daten auf Logical Storage umstellen.
Der Wechsel von Logical Storage auf Physical Storage in BigQuery kann Ihre Speicherkosten drastisch senken – das hat sich bei vielen unserer Kunden bestätigt.
Rechnet man jedoch die Kosten für BigQuery Time Travel und Fail-safe mit ein, kann Physical Storage am Ende deutlich teurer werden als Logical Storage – oder zumindest höhere Speicherkosten verursachen, als Sie erwartet hätten.
In diesem Beitrag geht es um:
- die Fallstricke bei BigQuery Time Travel und Fail-safe Storage, die Ihre Kosten in die Höhe treiben
- Ihre Optionen, um diese Fallstricke zu umgehen
Die Fallstricke bei BigQuery Time Travel und Fail-safe
Mit Time Travel können Sie in BigQuery auf Daten zugreifen, die innerhalb eines bestimmten Zeitfensters geändert oder gelöscht wurden. Standardmäßig umfasst dieses Fenster sieben Tage, lässt sich aber auf bis zu zwei Tage verkürzen.
Die Fail-safe-Funktion von BigQuery hält gelöschte Daten nach Ablauf des Time-Travel-Fensters weitere sieben Tage für eine Notfallwiederherstellung vor (bis vor Kurzem waren es 14 Tage). Anders als bei Time Travel lässt sich diese Aufbewahrungsdauer nicht anpassen. Um Fail-safe-Daten wiederherzustellen, müssen Sie zudem ein Ticket beim Google Support eröffnen.
Time-Travel- und Fail-safe-Speicher werden bei Physical Storage zu den Tarifen für aktiven Physical Storage berechnet, während bei Logical Storage für beides keine Kosten anfallen.
Das folgende Diagramm zeigt ein Beispielszenario:
- Insgesamt 200 GiB Long-Term Physical Storage, von denen 50 GiB gelöscht werden,
- ein Time-Travel-Fenster von sieben Tagen, gefolgt von
- einer Fail-safe-Phase von sieben Tagen.
Dazu eine Geschichte aus einer Live-BigQuery-Q&A, die wir vor Kurzem veranstaltet haben:
Ein Kunde löschte eine große Tabelle, die in Long-Term Physical Storage lag. Time Travel sicherte die gelöschte Tabelle für eine eventuelle Wiederherstellung. Mit dem Löschen wurden die Tabellendaten innerhalb von Time Travel und Fail-safe Storage in aktiven Speicher überführt. Über insgesamt 21 Tage (sieben Tage Time Travel, 14 Tage Fail-safe – damals waren es noch 14 Tage) zahlte der Kunde unwissentlich den Tarif für aktiven Speicher – mit einer unerwartet hohen Speicherrechnung als Folge.
Option 1: BigQuery-Time-Travel-Einstellungen anpassen
Standardmäßig steht BigQuery Time Travel auf sieben Tage und lässt sich auf bis zu zwei Tage reduzieren. Wenn Sie mit einer geringeren Datenresilienz leben können, senken Sie damit die Kosten für die in Time Travel gespeicherten Daten.
Wenn Sie etwa einen soliden Backup-Prozess von BQ in andere Quellen wie GCS haben, ist eine Verkürzung des Time-Travel-Zeitraums auf zwei Tage in der Regel unproblematisch. Einige unserer Kunden setzen Auto-Archive-Policies bzw. -Pipelines ein, um ihre Daten regelmäßig zu sichern. In solchen Fällen sind kürzere Time-Travel-Zeiträume besonders sinnvoll, da die Daten ohnehin außerhalb von BigQuery gesichert werden.
Aus unserer Erfahrung brauchen die meisten Kunden die vollen sieben Tage Time Travel gar nicht – selbst nach einer Reduzierung auf zwei Tage stehen ja zusätzlich noch sieben Tage Fail-safe zur Verfügung. Wenn Kostensenkung also wichtiger ist als sieben volle Tage Datenhistorie, werden Sie eine Verkürzung auf zwei Tage kaum spüren.
Alternativ kann es sich lohnen, vor dem Löschen großer Datenmengen den Time-Travel-Zeitraum vorübergehend auf zwei Tage zu reduzieren, um den Speicher-Footprint im Time Travel kurzfristig zu verringern. Denken Sie nur daran, den Wert anschließend wieder auf den ursprünglichen Stand zu setzen, falls Sie ihn benötigen!
Option 2: Tabelle vor dem Löschen auf BigQuery Logical Storage umstellen
Die andere Lösung: Stellen Sie das Abrechnungsmodell Ihres Datasets auf Logical Storage um, bevor Sie die Daten löschen – denn in diesem Modell werden weder Time Travel noch Fail-safe Storage in Rechnung gestellt.
Beachten Sie, dass Sie diese Umstellung nur einmal alle 14 Tage vornehmen können – Sie müssen also 14 Tage warten, bevor Sie zurückwechseln können. Außerdem kann es bis zu 24 Stunden dauern, bis der Wechsel des Speichermodells wirksam wird.
Bevor Sie umstellen, sollten Sie unbedingt diese Query ausführen und Ihre Kosten für 14 Tage Logical Storage mit denen für neun Tage aktiven Physical Storage (mindestens 2 Tage Time Travel + 7 Tage Fail-safe Storage) vergleichen.
Unten sehen Sie ein Beispielergebnis dieser Query. Die Spalte "additional_costs_for_physical_storage" enthält dabei sowohl die Kosten für Time Travel als auch für Fail-safe Storage:
dataset
logical_active_price
base_physical_price
logical_long_term_price
base_long_term_price
additional_costs_for_physical_storage
logical_storage_price
physical_storage_price
difference_in_price_if_physical_is_chosen
recommendation
warehouse
$ 0.57
$ 0.07
$ 0.00
$ 0.00
$ 62.27
$ 0.57
$ 62.34
$ -61.77
Keep dataset on logical storage
Option 3: Gar nicht erst auf BigQuery Physical Storage wechseln
Wenn Sie ständig Daten hinzufügen und löschen, sind Ihre Time-Travel- und Fail-safe-Volumen vermutlich ohnehin hoch – ein Wechsel zu Physical Storage ergibt dann von vornherein womöglich keinen Sinn.
Der Grund: Im Logical-Storage-Modell werden Time-Travel- und Fail-safe-Daten nicht berechnet, im Physical-Storage-Modell hingegen schon.
Liegen in diesen Bereichen also große Datenmengen, können die Kosten so weit anwachsen, dass sie über denen von Logical Storage liegen. Es lohnt sich, genau diese Datenvolumen zu prüfen, bevor Sie sich für einen Wechsel zu Physical Storage entscheiden.
Die oben verlinkte Query durchläuft ein Projekt (in einer einzelnen Region) und analysiert jedes Dataset, um Ihnen eine Kostenaufschlüsselung samt Empfehlung zu liefern.
Ein Wechsel zu BigQuery Physical Storage ist in folgenden Szenarien sinnvoll:
- Der Großteil Ihrer Daten besteht aus Text bzw. Strings (z. B. JSON, Adressen, Logs etc.), da diese die höchsten Komprimierungsraten erreichen.
- Es gibt einen soliden Data-Lifecycle-Plan (etwa eine nach Tagen partitionierte Tabelle, deren Partitionen jeweils nach X Tagen ablaufen).
- Daten in Tabellen oder Partitionen werden nicht ständig verändert (wie oben erwähnt, treibt das die Time-Travel- und Fail-safe-Speichermengen in die Höhe).
Fazit
In vielen Fällen senkt ein Wechsel von Logical Storage auf Physical Storage in BigQuery tatsächlich Ihre Speicherkosten. Es lohnt sich aber, die potenziellen Fallstricke zu kennen, die diesen Spareffekt zunichtemachen können.