Tarifs de BigQuery

Pour en savoir plus sur les tarifs de BigQuery, consultez cette page.

Pour BigQuery ML, consultez la page Tarifs de BigQuery ML.

Pour le service de transfert de données BigQuery, consultez la page Tarifs du service de transfert de données BigQuery.

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 : ces tarifs prévisibles sont plus adaptés aux clients qui disposent d'un budget fixe. 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 ne sont pas facturées de manière individuelle.

Pour en savoir plus sur la tarification du stockage et des requêtes, consultez la page relative aux SKU de Google Cloud. Notez que les tarifs des requêtes à la demande sont appelés "tarifs d'analyse" sur la page des 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 en savoir plus sur l'analyse des données de facturation à l'aide des rapports, consultez la page 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 page Exporter des données de facturation vers BigQuery dans la documentation 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

Lorsque vous chargez des données dans BigQuery depuis Cloud Storage, nous ne facturons pas l'opération de chargement 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. Une fois les données chargées dans BigQuery, elles sont soumises aux tarifs de stockage de BigQuery. Pour en savoir plus, consultez la page sur le chargement de données dans BigQuery.

Lorsque vous créez un ensemble de données dans BigQuery, vous devez choisir une zone pour les données. Si vous choisissez l'emplacement US, vous pouvez charger des données dans les tables de l'ensemble de données depuis un bucket Cloud Storage situé dans n'importe quelle autre région. Actuellement, lorsque vous chargez des données depuis une autre région dans un ensemble de données situé aux États-Unis, la sortie Internet ne vous est pas facturée.

Si vous choisissez une zone autre que US, vous devez effectuer l'une des opérations suivantes :

  • Charger les données depuis un bucket Cloud Storage accessible dans cette région (vous pouvez utiliser soit un bucket multirégional, soit un bucket régional situé dans la même région que l'ensemble de données)
  • Copier les données dans un bucket situé dans cette région

Lorsque vous copiez des données d'une région Cloud Storage à une autre, les tarifs réseau de Cloud Storage s'appliquent.

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 sur l'exportation de données à partir de BigQuery.
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 l'appel de fonctions définies par l'utilisateur persistantes ne sont pas facturés. Les fonctions persistantes définies par l'utilisateur étant actuellement en version bêta, les tarifs applicables sont susceptibles d'être modifié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.

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 tarif à la demande. Vous pouvez opter pour un modèle adapté à vos besoins ou associer les deux modèles de tarification pour chaque projet et chaque zone.

Tarifs à 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, Google Drive ou Bigtable. Les tarifs à la demande sont uniquement basés sur l'utilisation.

Les tarifs des 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.
  • Vous n'êtes pas facturé pour les requêtes renvoyant une erreur ni pour les requêtes qui récupèrent les résultats depuis le cache.
  • 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 celle-ci est terminée.
  • 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 relative aux SKU de Google Cloud Platform.

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 dans 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 :

Tarification des données partitionnées à l'aide d'outil externes stockées dans Cloud Storage

Des frais supplémentaires s'appliquent pour l'interrogation de tables partitionnées avec Hive qui sont stockées sur Cloud Storage.

BigQuery calcule la somme, en octets, des longueurs des noms de fichiers avant troncation. Le montant total facturé pour le partitionnement Hive est arrondi au Mo le plus proche, avec un minimum de 10 Mo de données traitées par table partitionnée Hive incluse dans la requête.

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 les réservations BigQuery.

Lorsque vous souscrivez à la tarification forfaitaire, vous vous procurez des engagements d'emplacements, 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 en file d'attente les emplacements. Aucuns frais supplémentaires ne s'appliquent. Pour savoir comment BigQuery exploite les emplacements pour le traitement des requêtes, consultez la page Emplacements dans la documentation BigQuery.

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 insertions en flux continu ou BI Engine.
  • Il s'agit d'une ressource régionale. Les engagements d'emplacements acquis dans une région ne peuvent pas être utilisés dans une autre région ni transférés.
  • Ils permettent aux clients d'augmenter leurs quotas de simultanéité par projet en contactant l'assistance Google Cloud Platform.
  • Ils sont disponibles sur engagements mensuel ou annuel.
  • Les engagements d'emplacements peuvent être partagés par l'ensemble de votre organisation. Il n'est pas nécessaire d'acquérir des engagements d'emplacements pour chaque projet.

Engagements forfaitaires mensuels

Vous souscrivez à la tarification forfaitaire en vous procurant des engagements d'emplacements, qui sont mesurés en nombre d'emplacements BigQuery. L'engagement de départ inclut 500 emplacements. Une facturation à la seconde s'applique pendant toute la durée de l'engagement. Le tableau ci-dessous indique le coût de votre engagement d'emplacements mensuel.

Engagements forfaitaires annuels

Vous souscrivez à la tarification forfaitaire en vous procurant des engagements d'emplacements, qui sont mesurés en nombre d'emplacements BigQuery. L'engagement de départ inclut 500 emplacements. Le tableau ci-dessous indique le coût de votre engagement d'emplacements annuel. Lorsque vous souscrivez à un engagement annuel, une facturation à la seconde s'applique pendant toute la durée de l'engagement.

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 :

Les tarifs de stockage sont calculés 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é.

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 TABLE' pour 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

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.

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 sources de données externes, telles que Cloud Bigtable, Cloud Storage et Google 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 liés à 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 même, 1 To équivaut à 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.

Voici les tarifs des insertions en flux continu :

Tarifs pour les requêtes LMD (langage de manipulation de données)

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 (langage de définition des données) 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 pour les 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 soumettez une requête qui contient 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 de n'analyser que 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 éliminer les 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 zones réservées à 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, UPDATE, etc., 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 l'expression WHILE n'entraîne aucuns frais.
  • CONTINUE/ITERATE : aucuns frais associés.
  • BREAK/LEAVE : aucuns frais associés.
  • BEGIN/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 et les tables partitionnées par date d'ingestion. 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 de 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;