Tarifs

Présentation

BigQuery propose des tarifs souples et évolutifs, adaptés à vos exigences techniques et à votre budget.

Les coûts de stockage sont basés sur la quantité de données que vous stockez dans BigQuery. Les tarifs de stockage se divisent en deux catégories :

  • Stockage actif : frais mensuels facturés pour les données stockées dans des tables ou dans des partitions que vous avez modifiées au cours des 90 derniers jours
  • Stockage à long terme : frais mensuels plus faibles facturés pour les données stockées dans des tables ou dans des partitions qui n'ont pas été modifiées au cours des 90 derniers jours

Vous avez le choix entre deux modèles de tarification pour les coûts des requêtes :

  • Tarifs à la demande : il s'agit de l'option la plus flexible. Les tarifs à la demande sont basés sur la quantité de données traitées par chaque requête exécutée.
  • Tarifs forfaitaires : cette option est idéale pour les clients qui souhaitent prévoir leurs coûts. Les clients qui optent pour ce modèle de tarification achètent des ressources dédiées au traitement des requêtes. Les requêtes individuelles ne sont pas facturées.

Pour en savoir plus sur les tarifs liés au stockage et aux requêtes, consultez la page sur les codes SKU de Google Cloud. Notez que les tarifs des requêtes à la demande sont appelés tarifs d'analyse sur la page des codes SKU.

Synthèse des tarifs

Vous trouverez un récapitulatif des tarifs de BigQuery dans le tableau suivant. Les quotas et limites de BigQuery s'appliquent à ces opérations.

Facturation des frais

Chaque projet que vous créez est associé à un compte de facturation. Tous les coûts liés aux tâches BigQuery exécutées dans le projet sont facturés sur le compte de facturation associé. Les coûts de stockage BigQuery sont également facturés sur le compte de facturation associé.

Analyser les données de facturation

Vous pouvez afficher les coûts de BigQuery et analyser les tendances sur la page des rapports Cloud Billing dans Cloud Console. Pour découvrir comment analyser les données de facturation à l'aide des rapports, consultez la section Afficher les rapports de facturation et l'évolution des coûts.

Pour en savoir plus sur l'analyse des données de facturation dans BigQuery, consultez la section Exporter des données Cloud Billing vers BigQuery dans la documentation sur Cloud Billing.

Opérations gratuites

Le tableau suivant présente les opérations BigQuery gratuites dans toutes les zones. Les quotas et limites de BigQuery s'appliquent à ces opérations.

Opération Détails
Chargement de données

Le chargement de données depuis Cloud Storage ou des fichiers locaux dans BigQuery est gratuit. Toutefois, vous devrez payer des frais pour le stockage des données dans Cloud Storage. Pour plus de détails, consultez la section Stockage de données sur la page des tarifs de Cloud Storage. Une fois les données chargées dans BigQuery, elles sont soumises aux tarifs de stockage de BigQuery.

Si l'ensemble de données cible se trouve dans l'emplacement multirégional US, les sorties réseau ne vous sont pas facturées lorsque vous chargez des données depuis un bucket Cloud Storage situé dans n'importe quelle autre région. Pour en savoir plus, consultez la section Considérations relatives aux zones.

Copie de données Lorsque vous copiez une table, nous ne facturons pas l'opération de copie proprement dite, mais vous encourez des frais pour le stockage de la nouvelle table et de la table que vous avez copiée. Pour en savoir plus, consultez la section Copier une table existante.
Exportation de données Lorsque vous exportez des données depuis BigQuery vers Cloud Storage, nous ne facturons pas l'opération d'exportation proprement dite, mais vous encourez des frais pour le stockage de données dans Cloud Storage. Pour plus de détails, consultez la section Stockage de données sur la page des tarifs de Cloud Storage. Pour en savoir plus, consultez la page Exporter des données de table.
Suppression d'ensembles de données La suppression d'un ensemble de données n'est pas facturée.
Suppression de tables, de vues, de partitions et de fonctions La suppression d'une table, d'une vue, de partitions de tables spécifiques ou d'une fonction définie par l'utilisateur n'est pas facturée.
Opérations associées aux métadonnées Les appels list, get, patch, update et delete ne sont pas facturés. Exemples (liste non exhaustive) : répertorier des ensembles de données, mettre à jour la liste de contrôle d'accès à un ensemble de données, mettre à jour la description d'une table ou répertorier des fonctions définies par l'utilisateur dans un ensemble de données.
Lecture de pseudo-colonnes L'interrogation des contenus des pseudo-colonnes suivantes n'est pas facturée :

_TABLE_SUFFIX : utilisée lors de l'interrogation de tables génériques ou pour obtenir une sémantique de décorateur de table en SQL standard
_PARTITIONDATE : utilisée lors de l'interrogation de tables partitionnées par date d'ingestion
_PARTITIONTIME : utilisée lors de l'interrogation de tables partitionnées par date d'ingestion
_FILE_NAME : utilisée lors de l'interrogation de tables basées sur des sources de données externes
Lecture de métatables L'interrogation des contenus des métatables suivantes n'est pas facturée :

__PARTITIONS_SUMMARY__ : utilisée lors de l'obtention de métadonnées sur les partitions d'une table partitionnée ou d'une table partitionnée par date d'ingestion
__TABLES_SUMMARY__ : utilisée lors de l'obtention de métadonnées sur les tables et les vues d'un ensemble de données
Création, remplacement ou appel de fonctions définies par l'utilisateur La création, le remplacement ou les appels de fonctions définies par l'utilisateur persistantes ne sont pas facturés.

Limites d'utilisation Always Free

Dans le cadre de la version gratuite de Google Cloud, vous bénéficiez d'un quota de ressources gratuites avec BigQuery dans la limite des conditions fixées. Ce quota est disponible pendant et après l'essai gratuit. Si vous dépassez les limites d'utilisation et que l'essai gratuit est terminé, le service vous sera facturé selon les tarifs figurant sur cette page.

Ressource Limites mensuelles d'utilisation gratuite Détails
Stockage Les 10 premiers Go par mois sont gratuits. Les modèles et les données d'entraînement BigQuery ML stockés dans BigQuery sont inclus dans la version de stockage gratuite de BigQuery.
Requêtes (analyse) Le premier To de données de requêtes traitées chaque mois est gratuit. Les requêtes utilisant les fonctions de prédiction, d'inspection et d'évaluation de BigQuery ML sont incluses dans la version d'analyse gratuite de BigQuery. Ce n'est pas le cas des requêtes BigQuery ML qui contiennent des instructions CREATE MODEL.
BigQuery propose également des tarifs forfaitaires pour les clients ayant un volume de requêtes important et préférant un coût mensuel fixe.
Requêtes CREATE MODEL BigQuery ML Les 10 premiers Go de données traitées chaque mois par des requêtes contenant des instructions CREATE MODEL sont gratuits. Les requêtes CREATE MODEL BigQuery ML sont indépendantes de la version d'analyse gratuite de BigQuery. Elles ne s'appliquent qu'aux modèles BigQuery ML intégrés (modèles entraînés dans BigQuery).

Tarifs des requêtes

Le tarif d'une requête fait référence au coût d'exécution de vos commandes SQL et des fonctions définies par l'utilisateur, ainsi qu'au coût de déclaration des instructions LMD (langage de manipulation de données) et LDD (langage de définition de données).

BigQuery propose deux modèles de tarification :

  • Les tarifs à la demande sont flexibles et économiques. Seules les requêtes que vous exécutez vous sont facturées.
  • Les tarifs forfaitaires permettent de bénéficier de coûts mensuels identiques et prévisibles.

Par défaut, BigQuery est facturé en fonction du modèle de tarification à la demande. Vous pouvez modifier votre modèle de facturation et choisir une facturation forfaitaire, ou choisir entre la facturation à la demande ou forfaitaire pour chaque combinaison de projet et d'emplacement.

Tarification à la demande

Dans le cadre de la tarification à la demande, BigQuery facture les requêtes en se basant sur une métrique : le nombre d'octets traités (également appelés "octets lus"). Ce nombre d'octets vous est facturé, que les données soient stockées dans BigQuery ou dans une source de données externe comme Cloud Storage, Drive ou Cloud Bigtable. Les tarifs à la demande sont uniquement basés sur l'utilisation.

Les tarifs de requêtes à la demande sont les suivants :

Notez les points suivants concernant les frais de requêtes :

  • BigQuery utilise une structure en colonne de données. Vous êtes facturé en fonction du nombre total de données traitées dans les colonnes que vous sélectionnez, et le nombre total de données par colonne est calculé en fonction des types de données de la colonne. Pour plus d'informations sur le mode de calcul de la taille de vos données, consultez la section Calcul de la taille des données.
  • Les requêtes renvoyant une erreur et les requêtes qui récupèrent les résultats depuis le cache ne vous sont pas facturées.
  • Les frais sont arrondis au Mo le plus proche, avec un minimum de 10 Mo de données traitées par table référencée par la requête, et avec un minimum de 10 Mo de données traitées par requête.
  • L'annulation d'une tâche de requête en cours d'exécution peut entraîner des frais s'élevant jusqu'au coût total de la requête si vous la laissez se terminer.
  • Lors de l'exécution d'une requête, vous êtes facturé en fonction du nombre de données traitées dans les colonnes que vous sélectionnez, même si vous définissez une valeur LIMIT explicite dans les résultats.
  • Le partitionnement et le clustering des tables permettent de réduire la quantité de données traitées par les requêtes. Nous vous recommandons d'y avoir recours autant que possible.
  • Les tarifs des requêtes à la demande sont appelés tarifs d'analyse sur la page des codes SKU de Google Cloud.

Maîtrise des coûts des requêtes à la demande

BigQuery fournit des systèmes de maîtrise des coûts qui vous permettent de plafonner les coûts de vos requêtes. Vous pouvez définir les options suivantes :

Interroger des données Cloud Storage

Lorsque vous interrogez une source de données externe depuis BigQuery, le nombre d'octets lus par la requête vous est facturé. Pour plus d'informations, consultez la section Tarifs des requêtes. Le stockage des données dans Cloud Storage vous est également facturé. Pour en savoir plus, consultez la page Tarifs de Cloud Storage.

Interroger des formats en colonnes dans Cloud Storage

Si vos données externes sont stockées aux formats de type ORC ou Parquet, le nombre d'octets facturés est limité aux colonnes lues par BigQuery. Les types de données d'une source de données externe étant convertis en types de données BigQuery par la requête, le nombre d'octets lus est calculé en fonction de la taille des types de données BigQuery. Pour en savoir plus sur les conversions de types de données, consultez les pages suivantes :

Tarifs forfaitaires

BigQuery propose des tarifs forfaitaires pour les clients qui préfèrent un coût mensuel fixe pour les requêtes plutôt qu'un prix à la demande par To de données traitées.

Vous pouvez opter pour les tarifs forfaitaires en utilisant BigQuery Reservations.

Lorsque vous souscrivez à la tarification forfaitaire, vous vous procurez des emplacements sur engagement, c'est-à-dire une capacité dédiée au traitement de requêtes, qui est mesurée en nombre d'emplacements BigQuery. Vos requêtes utilisent cette capacité, mais les octets traités ne vous sont pas facturés. Si vos besoins dépassent la capacité allouée par l'engagement, BigQuery met les emplacements en file d'attente. Aucuns frais supplémentaires ne s'appliquent. Pour découvrir comment BigQuery traite les requêtes à l'aide des emplacements, consultez la section Emplacements.

Voici les conditions des tarifs forfaitaires :

  • Ces tarifs s'appliquent aux coûts des requêtes (instructions BigQuery ML, LMD et LDD, par exemple).
  • Ces tarifs ne s'appliquent pas aux coûts engendrés par le stockage, les ingestions en flux continu ou BI Engine.
  • Il s'agit d'une ressource régionale. Les emplacements sur engagement acquis dans une région ou un ensemble multirégional ne peuvent pas être utilisés ni transférés dans une autre région ou un autre ensemble multirégional.
  • Ils permettent aux clients d'augmenter leurs quotas de simultanéité par projet en contactant l'assistance Google Cloud.
  • Ils sont disponibles sous la forme d'engagements à la seconde, mensuels ou annuels.
  • Les engagements d'emplacements peuvent être partagés par l'ensemble de votre organisation. Il n'est pas nécessaire d'acquérir des emplacements sur engagement pour chaque projet.
  • Le nombre minimal d'emplacements est de 100 par engagement, et ils s'acquièrent par incréments de 100.
  • Ils sont facturés à la seconde pour la durée de l'engagement.

Engagements forfaitaires mensuels

Le tableau ci-dessous indique le coût de vos emplacements sur engagement mensuel.

Engagements forfaitaires annuels

Le tableau ci-dessous indique le coût de vos emplacements sur engagement annuel.

Emplacements Flex : engagements à court terme

Les emplacements Flex correspondent à un type d'engagement spécial :

  • La durée de l'engagement n'est que de 60 secondes.
  • Vous pouvez annuler les emplacements Flex à tout moment par la suite.
  • Vous ne payez que pour les secondes de déploiement de votre engagement.

L'attribution des emplacements Flex dépend de la disponibilité en capacité. Lorsque vous tentez d'acheter des emplacements Flex, vous ne pouvez pas être sûr que vous les obtiendrez. Cependant, une fois que votre engagement est accepté, votre capacité est garantie jusqu'à ce que vous annuliez vos emplacements.

Le tableau suivant indique le coût de vos emplacements sur engagement Flex.

Emplacements d'essai (promotion)

Le 20 mai 2020, BigQuery a lancé une promotion à durée limitée pour les nouveaux clients BigQuery et ceux qui se réinscrivent. Les clients éligibles peuvent acquérir des emplacements d'essai, qui correspondent à un engagement de 500 emplacements sur six mois, à un tarif fortement réduit.

Les emplacements d'essai sont soumis à certaines caractéristiques :

  • Vous devez souscrire un engagement de six mois.
  • Une fois votre engagement actif, son annulation est impossible pendant 182 jours.
  • Vous ne pouvez acheter que 500 emplacements.
  • Vous pouvez souscrire d'autres types d'engagements et les combiner aux emplacements d'essai.
  • Les emplacements d'essai ne sont disponibles que dans les ensembles multirégionaux des États-Unis et de l'UE.
  • Les emplacements d'essai sont proposés pendant une durée limitée, selon le principe du "premier arrivé, premier servi".
  • En termes de performances et de disponibilité, il n'y a aucune différence entre les emplacements d'essai et d'autres types d'emplacements sur engagement.

Les emplacements d'essai sont soumis à des critères d'éligibilité et sont disponibles pour les clients suivants :

  • Nouveaux clients Google Cloud qui s'inscrivent à BigQuery
  • Clients Google Cloud existants qui s'inscrivent à BigQuery
  • Clients BigQuery existants dont les dépenses au cours des trois derniers mois n'ont pas dépassé 500 $ par mois
  • Clients qui s'inscrivent à l'aide de leur adresse e-mail professionnelle
  • Offre valable uniquement pour les achats effectués directement auprès de Google (et non par l'intermédiaire d'un revendeur ou d'un distributeur)

Pour en savoir plus sur le fonctionnement des emplacements d'essai, consultez la section Emplacements de test.

Pour bénéficier de cette offre, remplissez le formulaire de promotion sur les emplacements d'essai BigQuery. Nous vous recontacterons sous cinq jours ouvrés.

Tarifs de stockage

Une fois vos données chargées dans BigQuery, leur stockage vous est facturé. Les tarifs de stockage sont basés sur la quantité de données non compressées stockées dans vos tables.

La taille des données est calculée en fonction des types de données de chaque colonne. Pour plus d'informations sur le mode de calcul de la taille des données, consultez la section Calcul de la taille des données.

Stockage actif

Les tarifs de stockage actif sont les suivants :

Le prix de stockage est calculé au prorata par Mo et par seconde. Par exemple, si vous stockez :

  • 100 Mo pendant 15 jours, vous payez 0,001 $ (un dixième de cent) ;
  • 500 Go pendant 15 jours, vous payez 5 $ ;
  • 1 To pour un mois complet, vous payez 20 $.

Stockage à long terme

Si aucune modification n'est apportée à une table sur une période de 90 jours consécutifs, le prix de stockage de cette table diminue automatiquement d'environ 50 %. Lorsqu'une table est considérée comme un espace de stockage à long terme, cela n'a aucune incidence sur les performances, la durabilité, la disponibilité ni sur toute autre fonctionnalité.

Chaque partition d'une table partitionnée est prise en considération individuellement pour les tarifs de stockage à long terme. Si une partition n'a pas été modifiée au cours des 90 derniers jours, les données de cette partition sont considérées comme un espace de stockage à long terme et sont facturées au prix réduit.

Les tarifs de stockage à long terme sont les suivants :

Si la table est modifiée, le tarif de stockage normal s'applique de nouveau et le compteur de 90 jours est remis à zéro. Toute action qui modifie les données d'une table réinitialise le compteur, y compris les suivantes :

Action Détails
Charger des données dans une table Toute tâche de chargement ou de requête qui ajoute des données à une table de destination ou remplace celles qu'elle contient
Copier des données dans une table Toute tâche de copie qui ajoute des données à une table de destination ou remplace celles qu'elle contient
Écrire les résultats de requêtes dans une table Toute tâche de requête qui ajoute des données à une table de destination ou remplace celles qu'elle contient
Utiliser des instructions LMD (langage de manipulation de données) Utilisation d'une instruction LMD pour modifier les données d'une table
Utiliser des instructions LDD (langage de définition de données) Utilisation d'une instruction LDD CREATE OR REPLACE TABLEpour remplacer une table.
Diffuser des données en continu dans une table Ingestion de données avec l'appel d'API tabledata.insertAll

Toutes les autres actions ne réinitialisent pas le compteur, y compris celles indiquées ci-dessous :

  • Interroger une table
  • Créer une vue qui interroge une table
  • Exporter des données depuis une table
  • Copier une table (dans une autre table de destination)
  • Appliquer un correctif à une ressource de table ou la mettre à jour

Pour les tables qui atteignent le seuil de 90 jours au cours d'un cycle de facturation, le prix est calculé au prorata.

Les tarifs de stockage à long terme ne s'appliquent qu'au stockage BigQuery et non aux données stockées dans des sources de données externes, telles que Cloud Bigtable, Cloud Storage et Drive.

Tarifs de l'API BigQuery Storage

L'API BigQuery Storage dispose d'un modèle de tarification à la demande. Vous êtes facturé pour les lectures de données que vous effectuez. Les clients qui ont souscrit aux tarifs forfaitaires peuvent utiliser gratuitement l'API BigQuery Storage pour lire jusqu'à 300 To de données par mois. Les lectures au-delà des 300 To gratuits par mois sont facturées au tarif à la demande.

Tarifs à la demande

Dans le cadre de la tarification à la demande, les frais liés à l'API BigQuery Storage sont basés sur le nombre d'octets lus dans l'espace de stockage BigQuery par les appels à ReadRows.

Le nombre d'octets lus inclut les données que vous avez utilisées pour le filtrage, mais qui ne vous ont pas été renvoyées comme résultat de ReadRows. La lecture de données dans les tables temporaires ne vous est pas facturée.

Les tarifs à la demande de l'API BigQuery Storage sont les suivants :

Notez les points suivants concernant les frais de l'API BigQuery Storage :

  • Vous êtes facturé en fonction du volume total de données lues. Le total des données lues par colonne et la taille des données sont calculés en fonction du type de données de la colonne. Pour plus d'informations sur le mode de calcul de la taille des données, consultez la section Calcul de la taille des données.
  • Des frais s'appliquent pour toutes les données lues au cours d'une session de lecture, même en cas d'échec d'un appel ReadRows.
  • Si vous annulez un appel ReadRows avant la fin du flux, toutes les lectures de données effectuées avant l'annulation sont facturées. Des frais peuvent être facturés pour les données qui ont été lues, mais qui ne vous ont pas été renvoyées avant l'annulation de l'appel ReadRows.
  • Nous vous recommandons, dans la mesure du possible, d'utiliser des tables partitionnées et en cluster. Vous pouvez réduire la quantité de données lues en utilisant une clause WHERE pour restreindre les partitions. Pour en savoir plus, consultez la section Interroger des tables partitionnées.

Calcul de la taille des données

Lorsque vous chargez ou interrogez des données dans BigQuery, vous êtes facturé en fonction de leur taille. La taille de vos données est calculée en fonction de celle du type de données de chaque colonne.

La taille des données stockées et celle des données traitées par vos requêtes sont calculées en gigaoctets (Go). 1 Go correspond à 230 octets. Cette unité de mesure est parfois appelée gibioctet (GiB). De la même façon, 1 To correspond à 240 octets (1 024 Go).

Voici la taille de chaque type de données BigQuery :

Type de données Taille
INT64/INTEGER 8 octets
FLOAT64/FLOAT 8 octets
NUMERIC 16 octets
BOOL/BOOLEAN 1 octet
STRING 2 octets + la taille de la chaîne encodée en UTF-8
BYTES 2 octets + le nombre d'octets dans la valeur
DATE 8 octets
DATETIME 8 octets
TIME 8 octets
TIMESTAMP 8 octets
STRUCT/RECORD 0 octet + la taille des champs contenus
GEOGRAPHY 16 octets + 24 octets x le nombre de sommets dans le type de zone géographique (vous pouvez vérifier ce nombre à l'aide de la fonction ST_NumPoints.)

Les valeurs nulles pour tout type de données sont considérées comme représentant 0 octet.

Les colonnes répétées sont stockées sous la forme de tableaux, et leur taille est calculée en fonction du nombre de valeurs. Par exemple, la taille d'une colonne d'entiers (INT64) qui est répétée (ARRAY<INT64>) et qui contient 4 entrées est de 32 octets (4 entrées x 8 octets).

Tarifs des insertions en flux continu

Le chargement des données dans BigQuery est gratuit, sauf en ce qui concerne les données en flux continu, pour lesquelles nous facturons des frais minimes.

Les tarifs des insertions en flux continu sont les suivants :

Tarifs pour les requêtes LMD

Dans BigQuery, les requêtes LMD sont facturées en fonction du nombre d'octets traités par la requête.

Tarifs LMD pour les tables non partitionnées

Pour les tables non partitionnées, le nombre d'octets traités est calculé comme suit :

Instruction LMD Octets traités
INSERT Le nombre total d'octets traités pour toutes les colonnes référencées dans les tables analysées par la requête.
UPDATE Le nombre total d'octets de toutes les colonnes référencées dans les tables analysées par la requête
+ le nombre total d'octets de toutes les colonnes de la table mise à jour au moment où la fonction UPDATE démarre.
DELETE Le nombre total d'octets de toutes les colonnes référencées dans les tables analysées par la requête
+ le nombre total d'octets de toutes les colonnes de la table modifiée au moment où la fonction DELETE démarre.
MERGE S'il y a uniquement des clauses INSERT dans l'instruction MERGE, le nombre total d'octets traités pour toutes les colonnes référencées dans toutes les tables analysées par la requête vous sera facturé.
Si une clause UPDATE ou DELETE est présente dans l'instruction MERGE, le nombre total d'octets traités pour toutes les colonnes référencées dans les tables sources analysées par la requête
+ le nombre total d'octets de toutes les colonnes de la table cible (au démarrage de la fonction MERGE) vous sont facturés.

Tarifs LMD pour les tables partitionnées

Pour les tables partitionnées, le nombre d'octets traités est calculé comme suit :

Instruction LMD Octets traités
INSERT Le nombre total d'octets traités pour toutes les colonnes référencées dans toutes les partitions analysées par la requête.
UPDATE Le nombre total d'octets traités pour toutes les colonnes référencées dans toutes les partitions des tables analysées par la requête
+ le nombre total d'octets de toutes les colonnes des partitions mises à jour ou analysées pour la table en cours de mise à jour (au démarrage de la fonction UPDATE).
DELETE Le nombre total d'octets traités pour toutes les colonnes référencées dans toutes les partitions des tables analysées par la requête
+ le nombre total d'octets de toutes les colonnes des partitions modifiées ou analysées pour la table en cours de modification (au démarrage de la fonction DELETE).
MERGE S'il y a uniquement des clauses INSERT dans l'instruction MERGE, le nombre total d'octets traités pour toutes les colonnes référencées dans toutes les partitions analysées par la requête vous sera facturé.
Si une clause UPDATE ou DELETE est présente dans l'instruction MERGE, le nombre total d'octets traités pour toutes les colonnes référencées dans toutes les partitions des tables sources analysées par la requête
+ le nombre total d'octets de toutes les colonnes des partitions mises à jour, supprimées ou analysées pour la table cible (au démarrage de la fonction MERGE) vous sont facturés.

Tarifs pour les requêtes LDD

Dans BigQuery, les requêtes LDD sont facturées en fonction du nombre d'octets traités par la requête. Pour les instructions LDD, le nombre d'octets traités est calculé comme suit :

Instruction LDD Octets traités
CREATE TABLE Aucun
CREATE TABLE ... AS SELECT ... Le nombre total d'octets traités pour toutes les colonnes référencées dans les tables analysées par la requête.
CREATE VIEW Aucun
DROP TABLE Aucun
DROP VIEW Aucun

Tarifs des tables en cluster

Lorsque vous créez et utilisez des tables en cluster dans BigQuery, les frais sont basés sur le volume de données stockées dans les tables et sur les requêtes que vous exécutez sur les données. Pour vous aider à réduire le coût des requêtes, les tables en cluster éliminent des données de façon qu'elles ne soient pas traitées par les requêtes. Ce processus est appelé "élimination en bloc".

Élimination en bloc

BigQuery trie les données d'une table en cluster en fonction des valeurs des colonnes de clustering, puis les organise en blocs.

Lorsque vous envoyez une requête contenant un filtre sur une colonne en cluster, BigQuery utilise les informations de clustering pour déterminer efficacement si un bloc contient des données pertinentes pour la requête. Ce processus, appelé "élimination en bloc", permet à BigQuery d'analyser uniquement les blocs pertinents.

La tarification des requêtes est basée sur le nombre d'octets traités. Lorsque vous exécutez une requête sur une table en cluster et qu'elle inclut un filtre sur les colonnes en cluster, BigQuery utilise l'expression de filtre et les métadonnées de bloc pour restreindre le nombre de blocs analysés par la requête.

Lorsqu'un bloc est éliminé, il n'est pas analysé. Seuls les blocs analysés sont pris en compte pour calculer les octets de données traités par la requête. Le nombre d'octets traités par une requête sur une table en cluster est égal à la somme des octets lus dans chaque colonne référencée par la requête dans les blocs analysés.

Si une table en cluster est référencée à de multiples reprises dans une requête qui utilise plusieurs filtres, BigQuery facture l'analyse des colonnes des blocs appropriés de chacun des filtres respectifs.

Tarification des scripts

Tant que la fonctionnalité de scripts de BigQuery est en version bêta, l'équipe BigQuery recommande d'utiliser des projets comprenant des réservations à tarif fixe afin d'éviter des frais de requête inattendus, car le nombre d'octets scannés par un script n'est généralement pas connu avant son exécution. Vous pouvez également utiliser le bac à sable BigQuery pour profiter d'une exécution limitée de scripts gratuits. Dans le futur, l'équipe BigQuery offrira un contrôle plus explicite sur le nombre total d'octets scannés par les scripts et sur les instructions individuelles contenues dans chaque script. Cette fonctionnalité est en version bêta. Accédez aux notes de version de BigQuery pour connaître les modifications apportées aux tarifs.

Si un script échoue, le coût des instructions effectuées jusqu'au moment de l'échec vous est facturé. Les instructions qui échouent n'entraînent aucuns frais.

Pour les types d'instructions publics tels que SELECT, INSERT et UPDATE, le coût de l'exécution est conforme à la tarification décrite dans la documentation publique. Pour les types d'instructions spécifiques aux scripts, la tarification suivante s'applique :

  • DECLARE : nombre total d'octets scannés pour toutes les tables référencées dans l'expression DEFAULT. Les instructions DECLARE sans références de table n'entraînent aucuns frais.
  • SET : nombre total d'octets scannés pour toutes les tables référencées dans l'expression. Les instructions SET sans références de table n'entraînent aucuns frais.
  • IF : nombre total d'octets scannés pour toutes les tables référencées dans l'expression de condition. Les expressions de condition IF sans références de table n'entraînent aucuns frais. Une instruction non exécutée dans le bloc IF n'entraîne aucuns frais.
  • WHILE : nombre total d'octets scannés pour toutes les tables référencées dans l'expression de condition. Les instructions WHILE sans références de table dans l'expression de condition n'entraînent aucuns frais. Une instruction non exécutée dans le bloc WHILE n'entraîne aucuns frais.
  • CONTINUE ou ITERATE : aucuns frais associés.
  • BREAK ou LEAVE : aucuns frais associés.
  • BEGIN ou END : aucuns frais associés.

Les tables temporaires n'entraînent pas de frais de stockage pendant l'exécution du script. Toutefois, la tarification normale s'applique pour toute instruction qui crée, modifie ou interroge ces tables.

Exemples de tarification BigQuery

Estimer les coûts des requêtes

Pour obtenir des exemples de tarification des requêtes, consultez la section Estimer les coûts des requêtes.

Estimer les coûts de stockage

Pour obtenir des exemples de tarification du stockage, consultez la section Estimer les coûts de stockage.

Exemples de tarifs LMD pour les tables non partitionnées

Les exemples suivants montrent comment BigQuery calcule le nombre d'octets lus pour les instructions LMD qui modifient les tables non partitionnées.

Exemple 1 : Instruction UPDATE sur une table non partitionnée

table1 comporte deux colonnes : col1 de type INTEGER et col2 de type STRING.

UPDATE table1 SET col1 = 1 WHERE col2 = 2;

Octets traités dans cet exemple =

  • Nombre total d'octets dans col1 +
  • Nombre total d'octets dans col2

Exemple 2 : Instruction UPDATE sur une table non partitionnée

table1 comporte deux colonnes : col1 de type INTEGER et col2 de type STRING. table2 comporte une colonne : field1 de type INTEGER.

UPDATE table1 SET col1 = 1 WHERE col1 in (SELECT field1 from table2)

Octets traités dans cet exemple =

  • Nombre total d'octets dans table1.col1 avant l'exécution de l'instruction UPDATE +
  • Nombre total d'octets dans table1.col2 avant l'exécution de l'instruction UPDATE +
  • Nombre total d'octets dans table2.field1

Exemples de tarifs LMD pour les tables partitionnées

Les exemples suivants montrent comment BigQuery calcule le nombre d'octets lus pour les instructions LMD qui modifient les tables partitionnées. Pour afficher les représentations de schémas JSON pour les tables utilisées dans les exemples, consultez la section Tables utilisées dans les exemples de la page "Mettre à jour des données de tables partitionnées à l'aide d'instructions LMD".

Exemple 1 : Instruction INSERT sur une table partitionnée par date d'ingestion

mytable2 comporte deux colonnes : id de type INTEGER et ts de type TIMESTAMP. mytable comporte deux colonnes : field1 de type INTEGER et field2 de type STRING.

INSERT INTO mytable (_PARTITIONTIME, field1) AS SELECT TIMESTAMP(DATE(ts)), id from mytable2

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable2.ts +
  • Nombre total d'octets dans mytable2.id

La taille de la table dans laquelle les lignes sont insérées (mytable) n'a pas d'incidence sur le coût de la requête.

Exemple 2 : Instruction INSERT sur une table partitionnée

mytable2 comporte deux colonnes : id de type INTEGER et ts de type TIMESTAMP. mycolumntable comporte quatre colonnes : field1 de type INTEGER, field2 de type STRING, field3 de type BOOLEAN et ts de type TIMESTAMP.

INSERT INTO mycolumntable (ts, field1) AS SELECT ts, id from mytable2

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable2.ts +
  • Nombre total d'octets dans mytable2.id

La taille de la table dans laquelle les lignes sont insérées (mycolumntable) n'a pas d'incidence sur le coût de la requête.

Exemple 3 : Instruction UPDATE sur une table partitionnée par date d'ingestion

Instruction LMD 1 : Mise à jour d'une seule partition

mytable2 comporte deux colonnes : id de type INTEGER et ts de type TIMESTAMP. mytable comporte deux colonnes : field1 de type INTEGER et field2 de type STRING.

UPDATE project.mydataset.mytable T SET T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable2.id +
  • Nombre total d'octets dans mytable.field1 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mytable.field2 dans la partition "2017-05-01"

Instruction LMD 2 : Mise à jour d'une partition basée sur une autre partition de la table

UPDATE project.mydataset.mytable T SET T._PARTITIONTIME = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT 1 from project.mydataset.mytable S WHERE S.field1 = T.field1 AND S._PARTITIONTIME = TIMESTAMP("2017-06-01") )

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable.field1 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mytable.field2 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mytable.field1 dans la partition "2017-06-01" +
  • Nombre total d'octets dans mytable.field2 dans la partition "2017-06-01"

Dans ce cas, le coût de l'instruction UPDATE est basé sur la somme des tailles de tous les champs dans les partitions correspondant à "2017-05-01" et à "2017-06-01".

Exemple 4 : Instruction UPDATE sur une table partitionnée

Instruction LMD 1 : Mise à jour d'une seule partition

mytable2 comporte deux colonnes : id de type INTEGER et ts de type TIMESTAMP. mycolumntable comporte quatre colonnes : field1 de type INTEGER, field2 de type STRING, field3 de type BOOLEAN et ts de type TIMESTAMP.

UPDATE project.mydataset.mycolumntable T SET T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable2.id +
  • Nombre total d'octets dans mycolumntable.field1 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field2 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field3 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.ts dans la partition "2017-05-01"

Instruction LMD 2 : Mise à jour d'une partition basée sur une autre partition de la table

UPDATE project.mydataset.mycolumntable T SET T.ts = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT 1 from project.mydataset.mycolumntable S WHERE S.field1 = T.field1 AND DATE(S.ts) = "2017-06-01")

Octets traités dans cet exemple =

  • Nombre total d'octets dans mycolumntable.field1 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field2 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field3 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.ts dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field1 dans la partition "2017-06-01" +
  • Nombre total d'octets dans mycolumntable.field2 dans la partition "2017-06-01" +
  • Nombre total d'octets dans mycolumntable.field3 dans la partition "2017-06-01" +
  • Nombre total d'octets dans mycolumntable.ts dans la partition "2017-06-01"

Dans ce cas, le coût de l'instruction UPDATE est basé sur la somme des tailles de tous les champs dans les partitions correspondant à "2017-05-01" et à "2017-06-01".

Exemple 5 : Instruction DELETE sur une table partitionnée par date d'ingestion

mytable2 comporte deux colonnes : id de type INTEGER et ts de type TIMESTAMP. mytable comporte deux colonnes : field1 de type INTEGER et field2 de type STRING.

DELETE project.mydataset.mytable T WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable2.id +
  • Nombre total d'octets dans mytable.field1 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mytable.field2 dans la partition "2017-05-01"

Exemple 6 : Instruction DELETE sur une table partitionnée

mytable2 comporte deux colonnes : id de type INTEGER et ts de type TIMESTAMP. mycolumntable comporte quatre colonnes : field1 de type INTEGER, field2 de type STRING, field3 de type BOOLEAN et ts de type TIMESTAMP.

DELETE project.mydataset.mycolumntable T WHERE DATE(T.ts) =“2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Octets traités dans cet exemple =

  • Nombre total d'octets dans mytable2.id +
  • Nombre total d'octets dans mycolumntable.field1 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field2 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.field3 dans la partition "2017-05-01" +
  • Nombre total d'octets dans mycolumntable.ts dans la partition "2017-05-01"

Exemple de tarification des tables en cluster

Vous disposez d'une table en cluster nommée ClusteredSalesData. La table est partitionnée en fonction de la colonne timestamp. Elle est par ailleurs mise en clusters par la colonne customer_id. Les données sont organisées dans l'ensemble de blocs suivant :

Identifiant de partition ID de bloc Valeur minimale pour customer_id dans le bloc Valeur maximale pour customer_id dans le bloc
20160501 B1 10000 19999
20160501 B2 20000 24999
20160502 B3 15000 17999
20160501 B4 22000 27999

Vous exécutez la requête suivante sur la table. La requête contient un filtre sur la colonne customer_id.

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

Cette requête :

  • analyse les colonnes timestamp, customer_id et totalSale dans les blocs B2 et B4 ;
  • élimine le bloc B3 en raison du prédicat de filtre DATE(timestamp) = "2016-05-01" sur la colonne de partitionnement timestamp ;
  • élimine le bloc B1 en raison du prédicat de filtre customer_id BETWEEN 20000 AND 23000 sur la colonne de clustering customer_id.

Exemple de tarification d'un script

Dans le script ci-dessous, chaque instruction est précédée d'un commentaire détaillant, le cas échéant, les frais qui lui sont associés.

-- No cost, since no tables are referenced.
DECLARE x DATE DEFAULT CURRENT_DATE();
-- Incurs the cost of scanning string_col from dataset.table.
DECLARE y STRING DEFAULT (SELECT MAX(string_col) FROM dataset.table);
-- Incurs the cost of copying the data from dataset.big_table.  Once the
-- table is created, you are not charged for storage while the rest of the
-- script runs.
CREATE TEMP TABLE t AS SELECT * FROM dataset.big_table;
-- Incurs the cost of scanning column1 from temporary table t.
SELECT column1 FROM t;
-- No cost, since y = 'foo' doesn't reference a table.
IF y = 'foo' THEN
  -- Incurs the cost of scanning all columns from dataset.other_table, if
  -- y was equal to 'foo', or otherwise no cost since it is not executed.
  SELECT * FROM dataset.other_table;
ELSE
  -- Incurs the cost of scanning all columns from dataset.different_table, if
  -- y was not equal to 'foo', or otherwise no cost since it is not executed.
  UPDATE dataset.different_table
  SET col = 10
  WHERE true;
END IF;
-- Incurs the cost of scanning date_col from dataset.table for each
-- iteration of the loop.
WHILE x < (SELECT MIN(date_col) FROM dataset.table) DO
  -- No cost, since the expression does not reference any tables.
  SET x = DATE_ADD(x, INTERVAL 1 DAY);
  -- No cost, since the expression does not reference any tables.
  IF true THEN
    -- LEAVE has no associated cost.
    LEAVE;
  END IF;
  -- Never executed, since the IF branch is always taken, so does not incur
  -- a cost.
  SELECT * FROM dataset.big_table;
END WHILE;