Passare al physical storage di BigQuery può far risparmiare, ma occorre tenere d'occhio i costi di time travel e fail-safe storage. In questo articolo vediamo come queste funzionalità possono gonfiare la fattura e come evitarlo, ad esempio riducendo la finestra di time travel o passando al logical storage prima di eliminare i dati.
Passare dal logical al physical storage di BigQuery può ridurre drasticamente i costi di archiviazione, come abbiamo visto con molti clienti con cui abbiamo lavorato.
Se però si tiene conto dei costi di time travel e fail-safe di BigQuery, il conto finale potrebbe risultare ben più salato del logical storage, oppure produrre costi di archiviazione superiori alle attese.
In questo articolo vedremo:
- Le insidie di time travel e fail-safe storage di BigQuery che fanno lievitare i costi
- Come aggirare queste insidie
Le insidie di time travel e fail-safe in BigQuery
La funzionalità time travel di BigQuery permette di accedere ai dati modificati o eliminati in un qualunque istante all'interno di una finestra temporale prestabilita. Per impostazione predefinita questa finestra è di sette giorni, ma può essere ridotta fino a un minimo di due.
La funzionalità fail-safe di BigQuery, invece, conserva i dati eliminati per ulteriori sette giorni dopo la finestra di time travel, a scopo di ripristino di emergenza (fino a poco tempo fa erano 14 giorni). A differenza del time travel, il periodo di conservazione non è modificabile e, per recuperare i dati in fail-safe, è necessario aprire un ticket al supporto Google.
Sul physical storage si pagano sia i costi di time travel sia quelli di fail-safe storage alle tariffe di physical storage active, mentre sul logical storage non si paga né l'uno né l'altro.
Il grafico qui sotto simula uno scenario in cui:
- Il long-term physical storage totale è di 200 GiB e ne vengono eliminati 50 GiB,
- La finestra di time travel è di sette giorni, seguita da
- Un periodo di fail-safe di sette giorni.
Prenda ad esempio il caso descritto qui sotto, raccontato durante una sessione live di Q&A su BigQuery che abbiamo tenuto di recente:
Un cliente ha eliminato una tabella di grandi dimensioni che si trovava in long-term physical storage; la tabella eliminata è stata mantenuta in time-travel nel caso fosse stato necessario ripristinarla. Una volta eliminati, i dati sono stati convertiti in active storage all'interno di time-travel e poi di fail-safe storage: per un totale di 21 giorni (sette in time-travel e 14 in fail-safe, all'epoca in cui erano 14) il cliente ha pagato inconsapevolmente la tariffa active storage, ritrovandosi con una fattura di archiviazione molto più alta del previsto.
Opzione 1: ottimizzi le impostazioni di time travel di BigQuery
Per impostazione predefinita, il time travel di BigQuery è impostato a sette giorni e può essere ridotto fino a un minimo di due. Se ritiene di potersi permettere una resilienza dei dati inferiore, può abbassare questo valore per ridurre i costi dei dati conservati in time-travel.
Ad esempio, se dispone di un solido processo di backup da BQ verso altre destinazioni come GCS, ridurre la finestra di time travel a due giorni dovrebbe essere più che sufficiente. Alcuni nostri clienti configurano policy o pipeline di auto-archiviazione per eseguire backup periodici dei dati: in scenari di questo tipo ha senso adottare finestre di time travel più brevi, perché i dati sono già salvati al di fuori di BigQuery.
Dalla nostra esperienza, la maggior parte dei clienti non ha davvero bisogno dell'intera finestra di sette giorni di time travel: anche riducendola a due giorni, resta comunque l'opzione fail-safe di sette giorni in aggiunta. Quindi, se contenere i costi è più importante di mantenere lo storico completo di sette giorni, l'impatto di una riduzione a due giorni sarà minimo.
In alternativa, se sta per eliminare una grande quantità di dati, può valere la pena ridurre temporaneamente la finestra di time-travel a due giorni prima della cancellazione, così da contenere il volume archiviato al suo interno. Si ricordi però di ripristinare il valore precedente quando le servirà di nuovo!
Opzione 2: converta la tabella in logical storage di BigQuery prima di eliminarla
L'altra soluzione consiste nel cambiare il modello di fatturazione dello storage del dataset in logical storage prima di eliminare i dati, perché con questo modello non vengono fatturati i costi di time-travel né di fail-safe storage.
Tenga presente che questa modifica può essere effettuata una sola volta ogni 14 giorni: dovrà quindi attendere 14 giorni prima di poter tornare al modello precedente. Il passaggio al nuovo modello di storage, inoltre, può richiedere fino a 24 ore per diventare effettivo.
Prima di effettuare il cambio, però, si assicuri di eseguire questa query per confrontare i costi di 14 giorni di logical storage con quelli di nove giorni di active physical storage (minimo 2 giorni di time travel + 7 di fail-safe storage).
Di seguito un esempio di output, in cui "additional_costs_for_physical_storage" comprende sia i costi di time travel sia quelli di 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
Mantieni il dataset su logical storage
Opzione 3: non passi affatto al physical storage di BigQuery
Se aggiunge ed elimina dati di continuo, è probabile che i volumi di dati in time travel e fail-safe siano piuttosto consistenti: in questi casi, passare al physical storage potrebbe non avere alcun senso.
Il motivo è semplice: con il modello logical storage non si paga per i dati in time travel e fail-safe, mentre con il physical storage sì.
Quindi, se in queste aree ha grandi volumi di dati, i costi rischiano di superare quelli del logical storage. Quando si valuta il passaggio al physical storage, è quindi fondamentale analizzare proprio questi volumi.
La query condivisa sopra analizza un progetto (e una singola region), passando in rassegna ciascun dataset per restituire il dettaglio dei costi e una raccomandazione.
Il passaggio al physical storage di BigQuery ha senso nei seguenti scenari:
- La maggior parte dei dati è costituita da testo/stringhe (ad esempio json, indirizzi, log, ecc.), che presentano i tassi di compressione più alti.
- È in essere un piano solido di gestione del ciclo di vita dei dati (ad esempio, una tabella partizionata per giorno con scadenza di ogni partizione dopo X giorni).
- I dati nelle tabelle/partizioni non vengono modificati di continuo (come detto sopra, ciò comporta un aumento dei dati in time-travel e fail-safe storage).
Considerazioni finali
In molti casi il passaggio dal logical al physical storage di BigQuery può effettivamente ridurre i costi di archiviazione, ma è bene essere consapevoli delle potenziali insidie che possono vanificare il risparmio.