Passer au stockage physique de BigQuery permet de réduire les coûts, mais attention aux frais liés au time travel et au fail-safe storage. Nous vous expliquons comment ces fonctionnalités peuvent alourdir votre facture, et les options pour l'éviter : raccourcir la fenêtre de time travel ou basculer vers le stockage logique avant de supprimer des données.
Passer du stockage logique au stockage physique de BigQuery peut réduire considérablement vos coûts de stockage, comme nous l'avons constaté chez de nombreux clients que nous avons accompagnés.
Mais une fois pris en compte les coûts du time travel et du fail-safe de BigQuery, la facture peut s'avérer bien plus élevée que celle du stockage logique – ou dépasser largement vos prévisions.
Au programme de cet article :
- Les pièges du time travel et du fail-safe storage de BigQuery qui font grimper vos coûts
- Les options pour les contourner
Les pièges du time travel et du fail-safe de BigQuery
Le time travel de BigQuery vous permet d'accéder aux données modifiées ou supprimées à n'importe quel instant dans une fenêtre donnée. Par défaut, cette fenêtre est de sept jours, mais vous pouvez la réduire jusqu'à deux jours.
De son côté, le fail-safe de BigQuery conserve les données supprimées pendant sept jours supplémentaires après la fenêtre de time travel, à des fins de récupération d'urgence (cette durée était encore récemment de 14 jours). Contrairement au time travel, sa période de rétention n'est pas modifiable. Pour récupérer des données depuis le fail-safe, il faut ouvrir un ticket auprès du support Google.
En stockage physique, le time-travel et le fail-safe vous sont facturés au tarif du stockage physique actif, alors qu'en stockage logique, ils ne vous coûtent rien.
Le graphique ci-dessous illustre le scénario suivant :
- Stockage physique long terme total de 200 Gio, dont 50 Gio sont ensuite supprimés,
- Fenêtre de time-travel de sept jours, suivie par
- Une période de fail-safe de sept jours.
Voici un cas concret tiré d'une session live BigQuery Q&A que nous avons récemment animée :
Un client a supprimé une table volumineuse stockée en physique long terme, et le time-travel a conservé cette table au cas où il faudrait la restaurer. Une fois supprimées, ses données sont passées en stockage actif au sein du time-travel puis du fail-safe, soit un total de 21 jours (sept jours en time-travel, 14 jours en fail-safe à l'époque où cette durée était de 14 jours). Le client a ainsi payé sans le savoir le tarif du stockage actif, d'où une facture de stockage anormalement élevée.
Option n°1 : ajustez les paramètres du time travel BigQuery
Par défaut, le time travel BigQuery est réglé sur sept jours et peut descendre jusqu'à deux jours. Si une résilience moindre des données est acceptable pour vous, abaisser ce paramètre permet de diminuer les coûts liés aux données conservées dans le time-travel.
Par exemple, si vous disposez d'un processus de sauvegarde solide depuis BQ vers d'autres sources comme GCS, ramener la période de time travel à deux jours ne devrait poser aucun problème. Certains de nos clients mettent en place des pipelines ou politiques d'archivage automatique pour sauvegarder régulièrement leurs données. Dans ce type de configuration, raccourcir la période de time travel a tout son sens, puisque les données sont déjà sauvegardées en dehors de BigQuery.
D'expérience, la plupart des clients n'ont pas réellement besoin des sept jours complets de time travel : même en passant à deux jours, ils conservent en plus les sept jours de fail-safe. Si la maîtrise des coûts prime sur un historique complet de sept jours, ramener le time travel à deux jours ne devrait pas vous pénaliser outre mesure.
Autre approche : avant de supprimer un volume important de données, il peut être judicieux de réduire la période de time-travel à deux jours pour limiter temporairement l'empreinte de stockage. Pensez simplement à rétablir la valeur précédente si vous en avez besoin par la suite !
Option n°2 : convertissez votre table en stockage logique BigQuery avant suppression
L'autre solution consiste à basculer le modèle de facturation du stockage de votre dataset vers le stockage logique avant de supprimer les données, car ce modèle ne facture ni le time-travel ni le fail-safe storage.
Attention : ce changement n'est possible qu'une fois tous les 14 jours ; il faut donc patienter 14 jours avant de revenir en arrière. De plus, le basculement entre modèles de stockage peut prendre jusqu'à 24 heures avant de prendre effet.
Avant de vous lancer, pensez à exécuter cette requête pour comparer vos coûts entre 14 jours de stockage logique et neuf jours de stockage physique actif (au minimum 2 jours de time travel + 7 jours de fail-safe).
Voici un exemple de résultat de cette requête, où la colonne additional_costs_for_physical_storage regroupe à la fois les coûts du time travel et du 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
Conserver le dataset en stockage logique
Option n°3 : ne basculez pas vers le stockage physique BigQuery
Si vous ajoutez et supprimez des données en permanence, vos volumes de time travel et de fail-safe risquent d'être très élevés. Dans ce cas, basculer vers le stockage physique n'a peut-être tout simplement aucun intérêt.
Et pour cause : ces données ne sont pas facturées en stockage logique, mais elles le sont en stockage physique.
Si les volumes concernés sont importants, les coûts peuvent dépasser ceux du stockage logique. Il est donc essentiel d'examiner précisément ces volumes avant d'envisager le passage au stockage physique.
La requête partagée plus haut parcourt un projet (et une seule région) et passe en revue chaque dataset pour vous fournir un détail des coûts et une recommandation.
Le passage au stockage physique BigQuery se justifie dans les cas suivants :
- Vos données sont majoritairement du texte ou des chaînes (json, adresses, logs, etc.), qui offrent les meilleurs taux de compression.
- Un plan de cycle de vie des données solide est en place (par exemple, une table partitionnée par jour avec expiration de chaque partition après X jours).
- Les données ne sont pas modifiées en permanence dans les tables ou partitions (comme indiqué plus haut, cela alourdit le stockage en time-travel et fail-safe).
En résumé
Dans bien des cas, passer du stockage logique au stockage physique BigQuery permet effectivement de réduire vos coûts de stockage. Reste à connaître les pièges susceptibles d'annuler ces économies.