FAQ sur la tarification BigQuery

Tout dépend du workload. Si vous aviez des slots inutilisés en flat-rate, Editions avec Autoscaling peut réduire votre facture de compute. Le Compressed Storage peut alléger la partie stockage. Raisonnez en TCO, pas sur une seule ligne de facturation.

Ils sont distincts. Un commitment BigQuery vous donne un meilleur tarif slot/heure. Un commitment de 3 ans permet d'obtenir environ 40 % de réduction sur les coûts d'analyse. La tarification du stockage n'est pas remisée.

Oui. Le comportement des Editions, en particulier les minimums d'Autoscaling et le délai de réduction d'une minute, peut modifier les coûts de façon inattendue. Lancez un POC sur un workload représentatif avant de vous engager.

Les workloads longs et stables qui analysent de gros volumes de données sont les mieux adaptés aux Editions. Les requêtes courtes et ponctuelles sont généralement moins chères en on-demand, car l'Autoscaling alloue des blocs de 100 slots et facture une minute complète au minimum.

Tout dépend de la compressibilité. Les données riches en chaînes de caractères se compressent bien. Les données composées d'entiers se compressent mal. Nous proposons une requête dans ce gist GitHub pour comparer vos options : https://gist.github.com/sayle-doit/264d28dd990c478beb90b90ac3923681

Oui. Dupliquez notre feuille BigQuery Current Usage Analysis Tool et suivez les instructions : https://docs.google.com/spreadsheets/d/1Sv6SzATtAyGYID2Wg0qGdcpLfe7YdOsH4dFKHHtS59c/edit

Oui. Un projet peut tourner en on-demand, un autre en Standard Edition, un autre en Enterprise. Répartir les workloads entre plusieurs projets est l'un des meilleurs leviers d'optimisation à votre disposition.

Le SQL fonctionne tel quel. En revanche, si du code achète dynamiquement des slots Flex, il cessera de fonctionner. Le support Terraform est en cours de développement ; utilisez ignore_changes en attendant. Un refactoring peut néanmoins rester pertinent pour réduire la consommation totale de slots.

Oui. Les commitments flat-rate sont convertis en Enterprise Edition à votre tarif engagé pour toute leur durée. Les slots au-delà de votre baseline sont facturés au tarif Enterprise standard. L'Autoscaler peut monter jusqu'au maximum que vous définissez.

Non. Les outils de Google bloquent activement le Compressed Storage lorsqu'une réservation flat-rate existe. Il vous faut des projets en Editions ou en pur on-demand.

Non compressés. Interroger des données compressées depuis un projet on-demand n'apporte aucun avantage sur le coût de compute. Les économies portent uniquement sur le stockage.

Non. Le mécanisme de stockage long terme s'applique toujours, aux données compressées comme non compressées.

Oui. Les requêtes Editions sont soumises à un minimum d'une minute en raison du délai de réduction d'une minute de l'Autoscaler. Une requête de 10 secondes coûte une minute de slots.

Dans la console Google Cloud, ouvrez Monitoring, allez dans Metric Explorer et recherchez les métriques de slots. Les clients DoiT peuvent ouvrir un ticket et analyser le sujet avec un spécialiste BigQuery.

Oui. Définissez une baseline de slots que vous utilisez en permanence et un maximum correspondant à votre plafond de confort. Si vous avez des périodes d'inactivité, fixez la baseline à 0 pour ne pas payer de slots alloués inutilisés.

dbt sur BigQuery est très gourmand en compute. Le compute est désormais plus cher sur Editions, donc les workloads dbt coûtent généralement plus cher, sauf à optimiser l'utilisation des slots et à les isoler dans le bon projet.

Le time-travel ne peut pas être désactivé, mais vous pouvez réduire la fenêtre de 7 jours à 3. Le fail-safe peut être désactivé. La restauration depuis le fail-safe nécessite un ticket auprès du support Google Cloud.

Oui. Les rafraîchissements de métadonnées BigLake, par exemple, consomment des slot-heures mais analysent zéro octet, ce qui les rend gratuits en on-demand. Sur Editions, vous payez les slots. Isolez ces jobs dans un projet on-demand.