Quotas et limites

Ce document répertorie les quotas et limites système qui s'appliquent à BigQuery.

  • Les quotas spécifient la quantité d'une ressource partagée dénombrable que vous pouvez utiliser. Les quotas sont définis par les services Google Cloud tels que BigQuery.
  • Les limites système sont des valeurs fixes qui ne peuvent pas être modifiées.

Google Cloud utilise des quotas pour garantir l'équité et réduire les pics d'utilisation et de disponibilité des ressources. Un quota limite la quantité de ressources Google Cloud que votre projet Google Cloud peut utiliser. Les quotas s'appliquent à différents types de ressources, y compris les composants matériels, logiciels et réseau. Par exemple, les quotas peuvent limiter le nombre d'appels d'API à un service, le nombre d'équilibreurs de charge utilisés simultanément par votre projet ou le nombre de projets que vous pouvez créer. Les quotas protègent la communauté des utilisateurs de Google Cloud en empêchant la surcharge des services. Les quotas vous aident également à gérer vos propres ressources Google Cloud.

Le système Cloud Quotas effectue les opérations suivantes :

  • Surveille votre consommation de produits et services Google Cloud
  • Limite votre consommation de ces ressources
  • Permet de demander des modifications de la valeur du quota

Dans la plupart des cas, lorsque vous tentez d'utiliser plus d'une ressource que son quota ne le permet, le système bloque l'accès à la ressource et la tâche que vous essayez d'effectuer échoue.

Les quotas s'appliquent généralement au niveau du projet Google Cloud. Votre utilisation d'une ressource dans un projet n'affecte pas votre quota disponible dans un autre projet. Dans un projet Google Cloud, les quotas sont partagés entre toutes les applications et adresses IP.

Des limites système s'appliquent également aux ressources BigQuery. Les limites système ne peuvent pas être modifiées.

Par défaut, les quotas et limites de BigQuery s'appliquent par projet. Les quotas et limites qui s'appliquent de manière différente sont indiqués comme tels ; par exemple, le nombre maximal de colonnes par table ou le nombre maximal de requêtes API simultanées par utilisateur. Les règles spécifiques varient en fonction de la disponibilité des ressources, du profil de l'utilisateur, de l'historique d'Service Usage et d'autres facteurs. Elles peuvent en outre être modifiées sans préavis.

Renouvellement de quota

Les quotas quotidiens sont réapprovisionnés à intervalles réguliers tout au long de la journée, de sorte à inciter les utilisateurs à limiter leur taux de requêtes. Nous procédons en outre à un renouvellement progressif des quotas pour éviter de longues interruptions lorsqu'ils ont été atteints. Au lieu d'être réinitialisés intégralement en une seule fois, ils sont renouvelés au bout de quelques minutes.

Demander une augmentation du quota

Vous allez utiliser la console Google Cloud pour ajuster la plupart des quotas. Pour en savoir plus, consultez la section Demander un ajustement de quota.

Pour obtenir des instructions détaillées sur le processus de demande d'augmentation de quota dans la console Google Cloud, cliquez sur Visite guidée :

VISITE GUIDÉE

Limiter l'utilisation des quotas

Pour savoir comment limiter l'utilisation d'une ressource particulière en créant un forçage de quota, consultez la section Créer un forçage de quota.

Autorisations requises

Pour afficher et mettre à jour vos quotas BigQuery dans la console Google Cloud, vous avez besoin des mêmes autorisations que pour tout quota Google Cloud. Pour plus d'informations, consultez la section Autorisations de quota Google Cloud.

Résoudre les problèmes

Pour en savoir plus sur la résolution des erreurs liées aux quotas et aux limites, consultez la page Résoudre les erreurs de quota BigQuery.

Jobs

Les quotas et les limites s'appliquent aux tâches que BigQuery exécute en votre nom, qu'elles soient exécutées à l'aide de Google Cloud Console, de l'outil de ligne de commande bq ou de manière automatisée à l'aide de l'API REST ou des bibliothèques clientes.

Tâches de requête

Les quotas suivants s'appliquent aux tâches de requête créées automatiquement via l'exécution de requêtes interactives, de requêtes planifiées et de tâches soumises à l'aide de jobs.query et de la méthode d'API jobs.insert de type requête :

Quota Par défaut Remarques
Utilisation des requêtes par jour Illimité Il n'y a pas de limite au nombre d'octets pouvant être traités par les requêtes dans un projet.
Afficher le quota dans la console Google Cloud
Utilisation des requêtes par jour et par utilisateur Illimité Il n'y a pas de limite au nombre d'octets que les requêtes d'un utilisateur peuvent traiter chaque jour.
Afficher le quota dans la console Google Cloud
Octets de requêtes fédérées Cloud SQL interrégionales par jour 1 To Si l'emplacement de traitement des requêtes BigQuery et l'emplacement de l'instance Cloud SQL sont différents, votre requête est une requête interrégionale. Votre projet peut exécuter jusqu'à 1 To de requêtes interrégionales par jour. Consultez la page Requêtes fédérées Cloud SQL.
Afficher le quota dans la console Google Cloud
Octets transférés entre plusieurs clouds par jour 1 To Vous pouvez transférer jusqu'à 1 To de données par jour à partir d'un bucket Amazon S3 ou d'Azure Blob Storage. Pour en savoir plus, consultez les sections Transfert intercloud depuis Amazon S3 et Azure.
Afficher le quota dans la console Google Cloud

Les limites ci-dessous s'appliquent aux tâches de requête créées automatiquement via l'exécution de requêtes interactives, de requêtes planifiées et de tâches soumises à l'aide de jobs.query et de la méthode d'API jobs.insert de type requête :

Limite Par défaut Remarques
Nombre maximal de requêtes interactives en file d'attente 1 000 requêtes Votre projet peut mettre en file d'attente jusqu'à 1 000 requêtes interactives. Les requêtes interactives supplémentaires qui dépassent cette limite renvoient une erreur de quota.
Nombre maximal de requêtes par lot en file d'attente 20 000 requêtes Votre projet peut mettre en file d'attente jusqu'à 20 000 requêtes par lot. Les requêtes par lot supplémentaires qui dépassent cette limite renvoient une erreur de quota.
Nombre maximal de requêtes interactives simultanées sur des sources de données externes Bigtable 16 requêtes Votre projet peut exécuter jusqu'à seize requêtes simultanées sur une source de données externe Bigtable.
Nombre maximal de requêtes simultanées contenant des fonctions distantes 10 requêtes Vous pouvez exécuter jusqu'à dix requêtes simultanées avec des fonctions distantes par projet.
Nombre maximal de requêtes à plusieurs instructions simultanées 1 000 requêtes à plusieurs instructions Votre projet peut exécuter jusqu'à 1 000 requêtes à plusieurs instructions simultanées. Pour connaître les autres quotas et limites liés aux requêtes à plusieurs instructions, consultez la section Requêtes à plusieurs instructions.
Nombre maximal de requêtes simultanées en ancien SQL et contenant des fonctions définies par l'utilisateur 6 requêtes Votre projet peut exécuter jusqu'à six requêtes en ancien SQL simultanées avec des fonctions définies par l'utilisateur. Cette limite inclut les requêtes interactives et les requêtes par lot. Les requêtes interactives contenant des fonctions définies par l'utilisateur sont également comptabilisées dans la limite de requêtes interactives simultanées. Cette limite ne s'applique pas aux requêtes GoogleSQL.
Taille limite des requêtes quotidiennes Illimité Par défaut, aucune limite quotidienne ne s'applique à la taille des requêtes. Toutefois, vous pouvez définir des limites sur la quantité de données que les utilisateurs peuvent interroger en créant des quotas personnalisés pour contrôler l'utilisation des requêtes par jour ou l'utilisation des requêtes par jour et par utilisateur.
Limite quotidienne de mises à jour de la table de destination Consultez la section Nombre maximal d'opérations par table et par jour. Les mises à jour des tables de destination dans une tâche de requête sont comptabilisées dans la limite du nombre maximal d'opérations de table par jour pour les tables de destination. La mise à jour des tables de destination inclut les opérations d'ajout et d'écrasement que vous effectuez en exécutant des requêtes via Cloud Console ou l'outil de ligne de commande bq, ou bien en appelant les méthodes d'API jobs.query et de type requête jobs.insert.
Délai d'exécution de la requête à plusieurs instructions 6 heures

Une requête (qu'elle soit simple ou à instructions multiples) peut s'exécuter pendant 6 heures au maximum, après quoi elle échoue. Cependant, des requêtes font parfois l'objet de nouvelles tentatives. Une requête peut être tentée trois fois au maximum, et chaque tentative peut durer jusqu'à 6 heures. Par conséquent, il est possible pour une requête d'avoir un temps d'exécution total supérieur à 6 heures.

Le délai avant expiration du job CREATE MODEL est défini par défaut sur 24 heures, à l'exception des job de série temporelle, des jobs AutoML et des jobs de réglage d'hyperparamètres qui expirent après 72 heures.

Nombre maximal de ressources référencées par requête 1 000 Ressources Une requête peut référencer jusqu'à 1 000 tables, vues, fonctions définies par l'utilisateur (UDF) et fonctions de table uniques après expansion complète. Cette limite inclut les éléments suivants :
  • Tables, vues, fonctions définies par l'utilisateur et fonctions de table directement référencées par la requête.
  • Tables, vues, fonctions définies par l'utilisateur et fonctions de table référencées par d'autres vues/UDF/fonctions de table référencées dans la requête.
Longueur maximale des requêtes SQL en caractères 1 024 ko de caractères Une requête SQL peut comporter jusqu'à 1 024 ko de caractères. Cette limite inclut les commentaires et les caractères d'espacement. Si votre requête est plus longue, l'erreur suivante s'affiche: The query is too large.. Pour respecter cette limite, envisagez de remplacer les tableaux ou les listes volumineux par des paramètres de requête et de diviser une requête longue en plusieurs requêtes dans la session.
Longueur maximale d'une requête non résolue en ancien SQL 256 Ko Une requête non résolue en ancien SQL peut atteindre 256 Ko. Si votre requête est plus longue, vous obtenez l'erreur suivante : The query is too large. Pour respecter cette limite, envisagez de remplacer les tableaux ou les listes volumineux par des paramètres de requête.
Longueur maximale d'une requête GoogleSQL non résolue 1 Mo Une requête GoogleSQL non résolue peut atteindre 1 Mo. Si votre requête est plus longue, l'erreur suivante s'affiche : The query is too large.. Pour respecter cette limite, envisagez de remplacer les tableaux ou les listes volumineux par des paramètres de requête.
Longueur maximale d'une requête résolue en ancien SQL et en GoogleSQL 12 Mo La limite de longueur d'une requête résolue prend en compte la longueur de toutes les vues et tables génériques référencées par la requête.
Nombre maximal de paramètres de requête GoogleSQL 10 000 Paramètres Une requête GoogleSQL peut comporter jusqu'à 10 000 paramètres.
Taille maximale de requête 10 Mo La taille de la requête peut atteindre 10 Mo, ce qui inclut des propriétés supplémentaires comme les paramètres de requête.
Taille maximale des réponses 10 Go compressés La taille varie en fonction des taux de compression des données. La taille de réponse réelle peut être nettement supérieure à 10 Go. La taille de réponse maximale est illimitée dans le cas de l'écriture de résultats de requête volumineux dans une table de destination.
Taille maximale des lignes 100 Mo La taille maximale des lignes est approximative, car la limite est basée sur la représentation interne des données de ligne. La limite maximale de taille de ligne est appliquée à certaines étapes de l'exécution de la tâche de requête.
Nombre maximal de colonnes dans une table, un résultat de requête ou une définition de vue 10 000 colonnes Une de table, un résultat de requête ou une définition de vue peut contenir jusqu'à 10 000 colonnes. Cela inclut les colonnes imbriquées et répétées.
Nombre maximal d'emplacements simultanés pour la tarification à la demande 2 000 emplacements par projet

20 000 emplacements par organisation
Avec la tarification à la demande, votre projet peut comporter jusqu'à 2 000 emplacements simultanés. Un plafond de 20 000 emplacements simultanés est également appliqué au niveau de l'organisation. BigQuery essaie d'allouer des emplacements de manière équitable entre les projets d'une organisation si leur demande totale est supérieure à 20 000 emplacements. Les emplacements BigQuery sont partagés entre toutes les requêtes d'un même projet. BigQuery peut passer en utilisation intensive au-delà de cette limite pour accélérer vos requêtes. Pour vérifier le nombre d'emplacements que vous utilisez, consultez la page consacrée à la surveillance de BigQuery avec Cloud Monitoring.
Utilisation maximale du processeur par données analysées pour la tarification à la demande 256 secondes de processeur par Mio analysé Avec la tarification à la demande, votre requête peut utiliser jusqu'à 256 secondes de processeur par Mio de données analysées. Si votre requête nécessite une utilisation intensive du processeur pour la quantité de données en cours de traitement, la requête échoue avec une erreur billingTierLimitExceeded. Pour en savoir plus, consultez la section billingTierLimitExceeded.
Mutations de tables de transactions multi-instructions 100 tables Une transaction peut muter des données dans un maximum de 100 tables.
Modifications de partitions de transactions multi-instructions 100 000 modifications de partitions Une transaction peut effectuer au maximum 100 000 modifications de partitions.
Taille maximale des résultats de requêtes BigQuery Omni 20 Gio non compressés La taille maximale des résultats est de 20 Gio d'octets logiques lors de l'interrogation de données Azure ou AWS. Si le résultat de votre requête dépasse 20 Gio, envisagez d'exporter les résultats vers Amazon S3 ou Blob Storage. Pour en savoir plus, consultez la page Limites de BigQuery Omni.
Taille totale des résultats de requête BigQuery Omni par jour 1 To La taille totale des résultats de requête pour un projet est de 1 To par jour. Pour en savoir plus, consultez la page Limites de BigQuery Omni.
Taille maximale des lignes BigQuery Omni 10 Mio La taille maximale des lignes est de 10 Mio lors de l'interrogation de données Azure ou AWS. Pour en savoir plus, consultez la page Limites de BigQuery Omni.

Bien que les requêtes programmées utilisent des fonctionnalités du service de transfert de données BigQuery, elles ne sont pas des transferts et ne sont pas soumises aux limites de tâches de chargement.

Tâches d'exportation

Les limites suivantes s'appliquent aux tâches d'exportation de données depuis BigQuery à l'aide de l'outil de ligne de commande bq, de la console Google Cloud ou de la méthode d'API jobs.insert de type exportation.

Limite Par défaut Remarques
Nombre maximal d'octets exportés par jour 50 Tio Vous pouvez exporter gratuitement jusqu'à 50 Tio(tébioctets) de données par jour à partir d'un projet à l'aide du pool d'emplacements partagé. Vous pouvez configurer une règle d'alerte Cloud Monitoring qui fournit une notification sur le nombre d'octets exportés. Pour exporter plus de 50 Tio de données par jour, effectuez l'une des opérations suivantes :
Nombre maximal de tâches d'exportation par jour 100 000 Exportations Vous pouvez exécuter jusqu'à 100 000 exportations par jour dans un projet. Pour exécuter plus de 100 000 exportations par jour, effectuez l'une des opérations suivantes :
Taille maximale de table exportée vers un seul fichier 1 GB Vous pouvez exporter jusqu'à 1 Go de données de table dans un seul fichier. Pour exporter plus de 1 Go de données, utilisez un caractère générique pour exporter les données dans plusieurs fichiers. Le cas échéant, la taille des fichiers varie. Dans certains cas, la taille des fichiers de sortie est supérieure à 1 Go.
URI génériques par exportation 500 URI Une exportation peut comporter jusqu'à 500 URI génériques.

Pour en savoir plus sur votre utilisation actuelle des tâches d'exportation, consultez la page Afficher l'utilisation actuelle des quotas.

Tâches de chargement

Les limites suivantes s'appliquent lorsque vous chargez des données dans BigQuery à l'aide de la console Google Cloud, de l'outil de ligne de commande bq ou de la méthode d'API jobs.insert de type chargement.

Limite Par défaut Remarques
Tâches de chargement par table et par jour 1 500 jobs Les tâches de chargement, y compris celles ayant échoué, sont comptabilisées dans le nombre d'opérations de table par jour pour la table de destination. Pour en savoir plus sur les limites du nombre d'opérations de table par jour pour les tables standards et les tables partitionnées, consultez la page Tables.
Tâches de chargement par jour 100 000 Tâches Votre projet est réinitialisé avec un quota maximal de 100 000 jobs de chargement toutes les 24 heures. Les tâches de chargement ayant échoué sont comptabilisées dans cette limite. Dans certains cas, il est possible d'exécuter plus de 100 000 jobs de chargement en 24 heures si le quota du jour précédent n'est pas entièrement utilisé.
Nombre maximal de colonnes par table 10 000 colonnes Une table peut contenir jusqu'à 10 000 colonnes. Cela inclut les colonnes imbriquées et répétées.
Taille maximale par tâche de chargement 15 To La taille totale de l'ensemble de vos fichiers d'entrée CSV, JSON, Avro, Parquet et ORC peut atteindre 15 To.
Nombre maximal d'URI sources dans la configuration de la tâche 10 000 URI Une configuration de tâche peut comporter jusqu'à 10 000 URI sources.
Nombre maximal de fichiers par tâche de chargement 10 000 000 fichiers Une tâche de chargement peut contenir jusqu'à 10 millions de fichiers au total, y compris tous les fichiers correspondant à tous les URI génériques.
Nombre maximal de fichiers dans le bucket Cloud Storage source Environ 60 000 000 de fichiers Un job de chargement peut lire les données d'un bucket Cloud Storage contenant jusqu'à 60 000 000 de fichiers environ.
Limite de temps d'exécution d'une tâche de chargement 6 heures Une tâche de chargement échoue si elle s'exécute pendant plus de six heures.
Avro : taille maximale des blocs de données de fichiers 16 Mo La taille des blocs de données du fichier Avro est limitée à 16 Mo.
CSV : taille maximale de la cellule 100 Mo La taille des cellules CSV ne doit pas dépasser 100 Mo.
CSV : taille maximale des lignes 100 Mo La taille des lignes CSV ne doit pas dépasser 100 Mo.
CSV : taille maximale du fichier compressé 4 Go La taille des fichiers CSV compressés est limitée à 4 Go.
CSV : taille maximale du fichier, non compressé 5 To La taille d'un fichier CSV non compressé est limitée à 5 To.
JSON délimité par des retours à la ligne (ndJSON): taille maximale des lignes 100 Mo La taille des lignes JSON peut atteindre 100 Mo.
ndJSON: taille maximale du fichier compressé 4 Go La taille d'un fichier ndJSON compressé est limitée à 4 Go.
ndJSON: taille maximale du fichier, non compressé 5 To La taille maximale d'un fichier ndJSON non compressé est de 5 To.

Si vous dépassez régulièrement les limites de tâches de chargement en raison de mises à jour fréquentes, envisagez plutôt de diffuser des données par flux dans BigQuery.

Pour en savoir plus sur l'affichage de votre utilisation actuelle des jobs de chargement, consultez la section Afficher les jobs d'utilisation de quota actuelles.

Considérations relatives aux quotas des tâches de chargement du service de transfert de données BigQuery

Les jobs de chargement créés par les transferts du service de transfert de données BigQuery sont inclus dans les quotas de BigQuery sur les jobs de chargement. Il est important de prendre en compte le nombre de transferts que vous activez dans chaque projet pour éviter que les transferts et d'autres jobs de chargement ne génèrent des erreurs quotaExceeded.

Vous pouvez utiliser l'équation suivante pour faire une estimation du nombre de tâches de chargement dont vos transferts peuvent avoir besoin :

Number of daily jobs = Number of transfers x Number of tables x Schedule frequency x Refresh window

Où :

  • Number of transfers correspond au nombre de configurations de transfert que vous activez dans votre projet.
  • Number of tables correspond au nombre de tables créées par chaque type de transfert spécifique. Le nombre de tables varie selon le type de transfert :

    • Les transferts de Campaign Manager créent environ 25 tables.
    • Les transferts de Google Ads créent environ 60 tables.
    • Les transferts de Google Ad Manager créent environ 40 tables.
    • Les transferts de Google Play créent environ 25 tables.
    • Les transferts de Search Ads 360 créent environ 50 tables.
    • Les transferts de YouTube créent environ 50 tables.
  • Schedule frequency décrit la fréquence d'exécution du transfert. Les programmations d'exécution des transferts sont indiquées pour chaque type de transfert :

  • Refresh window correspond au nombre de jours à inclure dans le transfert de données. Si vous saisissez 1, il n'y a pas de remplissage quotidien.

Jobs de copie

Les limites suivantes s'appliquent aux tâches BigQuery permettant de copier des tables, y compris les tâches qui créent une copie, un clone ou un instantané d'une table standard, d'un clone de table ou d'un instantané de table. Elles concernent les jobs créés à l'aide de la console Google Cloud, de l'outil de ligne de commande bq ou de la méthode jobs.insert qui spécifie le champ copy dans la configuration du job. Les tâches de copie sont comptabilisées dans ces limites, qu'elles aboutissent ou non.

Limite Par défaut Remarques
Tâches de copie par table de destination et par jour Consultez la section Opérations de table par jour.
Tâches de copie par jour 100 000 Tâches Votre projet peut exécuter jusqu'à 100 000 tâches de copie par jour.
Tâches de copie interrégionales par table de destination et par jour 100 Tâches Votre projet peut exécuter jusqu'à 100 tâches de copie interrégionales par jour et par table de destination.
Tâches de copie interrégionales par jour 2 000 Tâches Votre projet peut exécuter jusqu'à 2 000 tâches de copie interrégionales par jour.
Nombre de tables sources à copier 1 200 tables sources Vous pouvez copier jusqu'à 1 200 tables sources par tâche de copie.

Pour en savoir plus sur l'affichage de votre utilisation actuelle des jobs de copie, consultez la section Jobs de copie : afficher les jobs d'utilisation de quota actuelles.

Les limites suivantes s'appliquent à la copie d'ensembles de données :

Limite Par défaut Remarques
Nombre maximal de tables dans l'ensemble de données source 25 000 tables Un ensemble de données source peut comporter jusqu'à 25 000 tables.
Nombre maximal de tables pouvant être copiées par exécution dans un ensemble de données de destination dans la même région 20 000 TABLES Votre projet peut copier un maximum de 20 000 tables par exécution dans un ensemble de données de destination situé dans la même région. Si un ensemble de données source contient plus de 20 000 tables, le service de transfert de données BigQuery planifie des exécutions séquentielles, chacune copiant jusqu'à 20 000 tables, jusqu'à ce que toutes les tables soient copiées. Ces exécutions sont séparées par un intervalle par défaut de 24 heures, que les utilisateurs peuvent personnaliser jusqu'à un minimum de 12 heures.
Nombre maximal de tables pouvant être copiées par exécution dans un ensemble de données de destination dans une autre région 1 000 TABLES Votre projet peut copier un maximum de 1 000 tables par exécution dans un ensemble de données de destination situé dans une région différente. Si un ensemble de données source contient plus de 1 000 tables, le service de transfert de données BigQuery planifie des exécutions séquentielles, chacune copiant jusqu'à 1 000 tables, jusqu'à ce que toutes les tables soient copiées. Ces exécutions sont séparées par un intervalle par défaut de 24 heures, que les utilisateurs peuvent personnaliser pour un minimum de 12 heures.

Réservations

Les quotas suivants s'appliquent aux réservations :

Quotas Par défaut Remarques
Nombre total d'emplacements pour la région UE 5 000 emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans l'ensemble de la région UE à l'aide de la console Google Cloud.
Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour la région États-Unis 10 000 emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans l'emplacement multirégional États-Unis à l'aide de la console Google Cloud.
Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour la région us-east1 4 000 Emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans la région répertoriée à l'aide de la console Google Cloud.
Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour les régions suivantes :
  • asia-south1
  • asia-southeast1
  • europe-west2
  • us-central1
  • us-west1
2 000 Emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans chacune des régions répertoriées à l'aide de la console Google Cloud.
Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour les régions suivantes :
  • asia-east1
  • asia-northeast1
  • asia-northeast3
  • asia-southeast2
  • australia-southeast1
  • europe-north1
  • europe-west1
  • europe-west3
  • europe-west4
  • northamerica-northeast1
  • us-east4
  • southamerica-east1
1 000 Emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans chacune des régions répertoriées à l'aide de la console Google Cloud.
Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour les régions BigQuery Omni 100 emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans les régions BigQuery Omni à l'aide de la console Google Cloud.
Consulter les quotas dans la console Google Cloud
Nombre total d'emplacements pour toutes les autres régions 500 emplacements Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans d'autres régions à l'aide de la console Google Cloud.
Afficher les quotas dans la console Google Cloud

Les limites suivantes s'appliquent aux réservations :

Limite Valeur Remarques
Nombre de projets d'administration pour les réservations d'emplacements 5 projets par organisation Nombre maximal de projets dans une organisation pouvant contenir une réservation ou un engagement actif pour des emplacements correspondant à une localisation ou une région donnée.
Nombre maximal de réservations d'édition standard 10 réservations par projet Nombre maximal de réservations d'édition standard par projet d'administration au sein d'une organisation pour un emplacement/une région donnés.
Nombre maximal de réservations de l'édition Enterprise ou Enterprise Plus 200 réservations par projet Nombre maximal de réservations de l'édition Enterprise ou Enterprise Plus par projet d'administration au sein d'une organisation pour un emplacement/une région donnés.
Nombre maximal d'emplacements dans une réservation associée à une attribution de réservation avec un type de tâche CONTINUOUS. 500 emplacements Lorsque vous souhaitez créer une attribution de réservation avec un type de tâche CONTINUOUS, la réservation associée ne peut pas comporter plus de 500 emplacements.

Ensembles de données

Les limites suivantes s'appliquent aux ensembles de données BigQuery.

Limite Par défaut Remarques
Nombre maximal d'ensembles de données Illimité Le nombre d'ensembles de données qu'un projet peut avoir est illimité.
Nombre de tables par ensemble de données Illimité Lorsque vous utilisez un appel d'API, les performances d'énumération sont ralenties à mesure que vous approchez 50 000 tables dans un ensemble de données. La console Google Cloud peut afficher jusqu'à 50 000 tables pour chaque ensemble de données.
Nombre de ressources autorisées dans la liste de contrôle d'accès d'un ensemble de données 2500 ressources La liste de contrôle d'accès d'un ensemble de données peut contenir jusqu'à 2500 ressources autorisées au total, ce qui inclut les Vues autorisées, les Ensembles de données autorisés et les Fonctions autorisées. Si vous dépassez cette limite en raison d'un grand nombre de vues autorisées, envisagez de les regrouper dans des ensembles de données autorisés.
Nombre d'opérations de mise à jour d'un ensemble de données par ensemble de données toutes les 10 secondes 5 opérations Votre projet peut effectuer jusqu'à cinq opérations de mise à jour des ensembles de données toutes les 10 secondes. La limite de mise à jour de l'ensemble de données inclut toutes les opérations de mise à jour des métadonnées effectuées par les éléments suivants :
Longueur maximale de la description des ensembles de données 16 384 caractères Lorsque vous ajoutez une description à un ensemble de données, le texte ne doit pas comporter plus de 16 384 caractères.

Tables

Toutes les tables

Les limites suivantes s'appliquent à toutes les tables BigQuery.

Limite Par défaut Remarques
Longueur maximale d'un nom de colonne 300 caractères. Le nom de la colonne ne peut pas comporter plus de 300 caractères.
Longueur maximale d'une description de colonne 1 024 caractères Lorsque vous ajoutez une description à une colonne, le texte ne doit pas comporter plus de 1 024 caractères.
Profondeur maximale des enregistrements imbriqués 15 Niveaux Les colonnes de type RECORD peuvent contenir des types RECORD imbriqués, également appelés enregistrements enfants. La limite de profondeur des données imbriquées est de 15 niveaux. Cette limite est indépendante du fait que les enregistrements soient scalaires ou basés sur des tableaux (répétitions).
Longueur maximale d'une description de table 16 384 caractères Lorsque vous ajoutez une description à un tableau, le texte ne doit pas comporter plus de 16 384 caractères.

Tables standards

Les limites suivantes s'appliquent aux tables intégrées (standards) de BigQuery :

Limite Par défaut Remarques
Modifications de table par jour 1 500 modifications

Votre projet peut effectuer jusqu'à 1 500 modifications par table et par jour, qu'il s'agisse de mettre à jour les métadonnées de la table, d'ajouter ou de mettre à jour des données, ou de tronquer la table. Cette limite ne peut pas être modifiée et inclut le total cumulé de tous les éléments suivants : jobs de chargement,jobs de copie et jobs de requête qui ajoutent ou écrasent une table de destination.

Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de table par jour.

Les données de streaming ne sont pas comptabilisées dans le nombre de modifications de table par jour.

Taux maximal d'opérations de mise à jour des métadonnées de table par table 5 opérations pour 10 secondes Votre projet peut effectuer jusqu'à cinq opérations de mise à jour des métadonnées de table pour 10 secondes par table. Cette limite s'applique à toutes les opérations de mise à jour des métadonnées de table, effectuées par les éléments suivants :Cette limite inclut le total combiné de tous les jobs de chargement, jobs de copie et jobs de requête qui ajoutent ou écrasent une table de destination, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table. Notez que même si les instructions LMD sont comptabilisées dans cette limite, elles n'y sont pas soumises si elle est atteinte. Les opérations LMD sont soumises à des limites de débit dédiées.

Si vous dépassez cette limite, vous recevez un message d'erreur du type Exceeded rate limits: too many table update operations for this table. Cette erreur est temporaire. vous pouvez réessayer avec un intervalle exponentiel entre les tentatives.

Pour identifier les opérations comptabilisées dans cette limite, vous pouvez inspecter vos journaux. Consultez Résoudre les erreurs de quota pour savoir comment diagnostiquer et résoudre cette erreur.

Nombre maximal de colonnes par table 10 000 colonnes Chaque table, résultat de requête ou définition de vue peut comporter jusqu'à 10 000 colonnes. Cela inclut les colonnes imbriquées et répétées.

Tables externes

Les limites suivantes s'appliquent aux tables BigQuery contenant des données stockées sur Cloud Storage aux formats Avro, CSV, JSON, ORC et Parquet.

Limite Par défaut Remarques
Nombre maximal d'URI sources par table externe 10 000 URI Chaque table externe peut comporter jusqu'à 10 000 URI sources.
Nombre maximal de fichiers par table externe 10 000 000 fichiers Une table externe peut contenir jusqu'à 10 millions de fichiers, y compris tous les fichiers correspondant à tous les URI génériques.
Taille maximale des données stockées sur Cloud Storage par table externe 600 To Une table externe peut contenir jusqu'à 600 téraoctets pour tous les fichiers d'entrée. Cette limite s'applique aux tailles de fichiers tels qu'ils sont stockés sur Cloud Storage. cette taille n'est pas la même que celle utilisée dans la formule de tarifs de la requête. Pour les tables partitionnées externes, la limite est appliquée après l'élimination des partitions.
Nombre maximal de fichiers dans le bucket Cloud Storage source Environ 60 000 000 de fichiers Une table externe peut référencer un bucket Cloud Storage contenant jusqu'à 60 000 000 de fichiers environ. Pour les tables partitionnées externes, cette limite est appliquée avant l'élimination des partitions.

Tables partitionnées

Les limites suivantes s'appliquent aux tables partitionnées BigQuery.

Les limites de partition s'appliquent au total cumulé de tous les jobs de chargement, jobs de copie et jobs de requête qui ajoutent ou écrasent une partition de destination.

Une seule tâche peut affecter plusieurs partitions. Par exemple, les jobs de requête et les jobs de chargement peuvent écrire sur plusieurs partitions.

BigQuery utilise le nombre de partitions affectées par une tâche pour déterminer la limite utilisée par celle-ci. Les insertions en flux continu n'affectent pas cette limite.

Pour en savoir plus sur les stratégies permettant de respecter les limites des tables partitionnées, consultez la page Résoudre les erreurs de quota.

Limite Par défaut Remarques
Nombre de partitions par table partitionnée 10 000 partitions Chaque table partitionnée peut comporter jusqu'à 10 000 partitions. Si vous dépassez cette limite, pensez à utiliser le clustering en plus ou à la place du partitionnement.
Nombre maximal de partitions modifiées par tâche 4 000 Partitions Chaque opération de tâche (requête ou chargement) peut affecter jusqu'à 4 000 partitions. BigQuery rejette toute tâche de requête ou de chargement qui tente de modifier plus de 4 000 partitions.
Nombre de modifications de partition au moment de l'ingestion par table partitionnée et par jour 11 000 modifications

Votre projet peut effectuer jusqu'à 11 000 modifications de partition par jour, qu'il s'agisse d'ajout ou de mise à jour des données, ou de troncation de table partitionnée par date d'ingestion.

Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de partition par jour.

Nombre de modifications de partitions par table partitionnée par colonne et par jour 30 000 Modifications.

Votre projet peut générer jusqu'à 30 000 modifications de partition par jour pour une table partitionnée en colonnes.

Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de partition par jour.

Les données de streaming ne sont pas comptabilisées dans le nombre de modifications de partition par jour.

Taux maximal d'opérations de mise à jour des métadonnées de table par table partitionnée 50 modifications toutes les 10 secondes Votre projet peut exécuter jusqu'à 50 modifications par table partitionnée toutes les 10 secondes. Cette limite s'applique à toutes les opérations de mise à jour des métadonnées de table partitionnée effectuées par les éléments suivants :Cette limite inclut le total combiné de tous les jobs de chargement, jobs de copie et jobs de requête qui ajoutent ou écrasent une table de destination, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table.

Si vous dépassez cette limite, vous recevez un message d'erreur du type Exceeded rate limits: too many partitioned table update operations for this table. Cette erreur est temporaire. vous pouvez réessayer avec un intervalle exponentiel entre les tentatives.

Pour identifier les opérations comptabilisées dans cette limite, vous pouvez inspecter vos journaux.

Nombre de plages possibles pour le partitionnement de plage 10 000 Plages Une table partitionnée par plages peut contenir jusqu'à 10 000 plages. Cette limite s'applique à la spécification de partition lorsque vous créez la table. Une fois la table créée, la limite s'applique également au nombre réel de partitions.

Clones de tables

Les limites suivantes s'appliquent aux clones de table BigQuery :

Limite Par défaut Remarques
Nombre maximal de clones et d'instantanés dans une chaîne 3 clones ou instantanés de table Les clones et les instantanés sont limités à une profondeur de 3. Cela signifie qu'après avoir cloné ou créé un instantané d'une table de base, vous ne pourrez cloner ou créer un instantané à partir du résultat que deux fois de plus. Toute troisième tentative de clonage ou de création d'instantané à partir du résultat générera une erreur. Par exemple, vous pouvez créer le clone A de la table de base, créer l'instantané B du clone A, puis créer le clone C de l'instantané B. Pour créer des doubles supplémentaires du clone ou de l'instantané de troisième niveau, utilisez plutôt une opération de copie.
Nombre maximal de clones et d'instantanés pour une table de base 1 000 clones ou instantanés de table Vous ne pouvez pas avoir plus de 1 000 clones et instantanés (total combiné) d'une table de base donnée. Par exemple, si vous disposez de 600 instantanés et 400 clones, la limite est atteinte.

Instantanés de table

Les limites suivantes s'appliquent aux instantanés de table BigQuery :

Limite Par défaut Remarques
Nombre maximal de tâches simultanées pour les instantanés de table 100 Tâches Votre projet peut exécuter jusqu'à 100 tâches d'instantané de table simultanées.
Nombre maximal de tâches d'instantané de table par jour 50 000 Tâches Votre projet peut exécuter jusqu'à 50 000 tâches d'instantané de table par jour.
Nombre maximal de jobs d'instantané de table par table et par jour 50 jobs Votre projet peut exécuter jusqu'à 50 jobs d'instantané de table par table et par jour.
Nombre maximal de mises à jour de métadonnées par instantané de table et par intervalle de 10 secondes 5 mises à jour Votre projet peut mettre à jour les métadonnées d'un instantané de table jusqu'à cinq fois toutes les 10 secondes.
Nombre maximal de clones et d'instantanés dans une chaîne 3 clones ou instantanés de table Les clones et les instantanés sont limités à une profondeur de 3. Cela signifie qu'après avoir cloné ou créé un instantané d'une table de base, vous ne pourrez cloner ou créer un instantané à partir du résultat que deux fois de plus. Toute troisième tentative de clonage ou de création d'instantané à partir du résultat générera une erreur. Par exemple, vous pouvez créer le clone A de la table de base, créer l'instantané B du clone A, puis créer le clone C de l'instantané B. Pour créer des doubles supplémentaires du clone ou de l'instantané de troisième niveau, utilisez plutôt une opération de copie.
Nombre maximal de clones et d'instantanés pour une table de base 1 000 clones ou instantanés de table Vous ne pouvez pas avoir plus de 1 000 clones et instantanés (total combiné) d'une table de base donnée. Par exemple, si vous disposez de 600 instantanés et 400 clones, la limite est atteinte.

Vues

Les quotas et limites suivants s'appliquent aux vues et aux vues matérialisées.

Vues logiques

Les limites suivantes s'appliquent aux vues BigQuery standards :

Limite Par défaut Remarques
Nombre maximal de niveaux de vues imbriquées 16 Niveaux BigQuery accepte jusqu'à 16 niveaux de vues imbriquées. Il est possible de créer des vues jusqu'à cette limite, mais les requêtes sont limitées à 15 niveaux. Si la limite est dépassée, BigQuery renvoie une erreur INVALID_INPUT.
Longueur maximale d'une requête GoogleSQL utilisée pour définir une vue 256 000 caractères Une requête GoogleSQL unique qui définit qu'une vue peut comporter jusqu'à 256 000 caractères. Cette limite s'applique à une seule requête et n'inclut pas la longueur des vues référencées dans la requête.
Nombre maximal de vues autorisées par ensemble de données Consultez la page Ensembles de données.
Longueur maximale d'une description de vue 16 384 caractères Lorsque vous ajoutez une description à une vue, le texte ne doit pas comporter plus de 16 384 caractères.

Vues matérialisées

Les limites suivantes s'appliquent aux vues matérialisées BigQuery.

Limite Par défaut Remarques
Références de table de base (même ensemble de données) 20 vues matérialisées Chaque table de base peut être référencée par un maximum de 20 vues matérialisées à partir du même ensemble de données.
Références de tables de base (même projet) 100 vues matérialisées Chaque table de base peut être référencée par un maximum de 100 vues matérialisées du même projet.
Références de tables de base (organisation entière) 500 vues matérialisées Chaque table de base peut être référencée par un maximum de 500 vues matérialisées de l'ensemble de l'organisation.
Nombre maximal de vues autorisées par ensemble de données Consultez la page Ensembles de données.
Longueur maximale de la description d'une vue matérialisée 16 384 caractères Lorsque vous ajoutez une description à une vue materialisée, le texte ne doit pas comporter plus de 16 384 caractères.

Rechercher dans les index

Les limites suivantes s'appliquent aux index de recherche BigQuery :

Limite Par défaut Notes
Nombre d'instructions LDD CREATE INDEX par projet, par région et par jour 500 opérations Votre projet peut émettre jusqu'à 500 opérations LDD CREATE INDEX chaque jour dans une région.
Nombre d'instructions LDD d'index de recherche par table et par jour 20 opérations Votre projet peut émettre jusqu'à 20 opérations LDD CREATE INDEX ou DROP INDEX par table et par jour.
Taille maximale autorisée des données de table par organisation, pour la création d'index de recherche ne s'exécutant pas dans une réservation 100 To dans les emplacements multirégionaux, 20 To dans toutes les autres régions Vous pouvez créer un index de recherche pour une table si la taille globale des tables avec des index dans votre organisation est inférieure à la limite de votre région : 100 To pour les emplacements multirégionaux US et EU, et 20 To pour toutes les autres régions. Cette limite ne s'applique pas si vos jobs de gestion d'index s'exécutent dans votre propre réservation.

Index vectoriels

Les limites suivantes s'appliquent aux index vectoriels BigQuery :

Limite Par défaut Notes
Nombre minimal de lignes de la table de base 5 000 lignes Pour créer un index vectoriel, une table doit contenir au moins 5 000 lignes.
Nombre maximal de lignes pour la table de base 10 000 000 000 lignes pour le type d'index IVF

200 000 000 pour le type d'index TREE_AH
Une table peut contenir au maximum 10 000 000 000 lignes pour créer un index vectoriel IVF et 200 000 000 lignes pour créer un index vectoriel TREE_AH.
Taille maximale du tableau dans la colonne indexée 1 600 éléments La colonne à indexer peut contenir au maximum 1 600 éléments.
Taille minimale de la table pour la population des index vectoriels 10 Mo Si vous créez un index vectoriel sur une table de moins de 10 Mo, l'index n'est pas renseigné. De même, si vous supprimez les données d'une table indexée vectorielle de telle sorte que la taille de la table est inférieure à 10 Mo, l'index vectoriel est temporairement désactivé. Cela se produit que vous utilisiez ou non votre propre réservation pour vos tâches de gestion d'index. Lorsque la taille d'une table indexée vectorielle dépasse à nouveau 10 Mo, son index est automatiquement renseigné.
Nombre d'instructions LDD CREATE VECTOR INDEX par projet, par région et par jour 500 opérations Pour chaque projet, vous pouvez émettre jusqu'à 500 opérations CREATE VECTOR INDEX par jour pour chaque région.
Nombre d'instructions LDD d'index vectoriel par table et par jour 10 opérations Vous pouvez émettre jusqu'à 10 opérations CREATE VECTOR INDEX ou DROP VECTOR INDEX par table et par jour.
Taille maximale autorisée des données de table par organisation, pour la création d'index vectoriel ne s'exécutant pas dans une réservation 6 To Vous pouvez créer un index vectoriel pour une table si la taille totale des tables avec index de votre organisation est inférieure à 6 To. Cette limite ne s'applique pas si vos jobs de gestion d'index s'exécutent dans votre propre réservation.

Routines

Les quotas et limites suivants s'appliquent aux routines.

Fonctions définies par l'utilisateur

Les limites suivantes s'appliquent aux fonctions définies par l'utilisateur (UDF), qu'elles soient temporaires ou persistantes, dans les requêtes GoogleSQL.

.
Limite Par défaut Remarques
Sortie maximale par ligne 5 Mo La quantité maximale de données que votre fonction JavaScript définie par l'utilisateur peut générer lors du traitement d'une seule ligne est d'environ 5 Mo.
Nombre maximal de requêtes en ancien SQL simultanées avec fonctions définies par l'utilisateur (JavaScript) 6 requêtes Votre projet peut comporter jusqu'à six requêtes en ancien SQL simultanées contenant des fonctions définies par l'utilisateur en JavaScript. Cette limite inclut les requêtes interactives et les requêtes par lot. Cette limite ne s'applique pas aux requêtes GoogleSQL.
Nombre maximal de ressources de fonction JavaScript définies par l'utilisateur par requête 50 Ressources Une tâche de requête peut contenir jusqu'à 50 ressources de fonction JavaScript définie par l'utilisateur, telles que des blobs de code intégrés ou des fichiers externes.
Taille maximale du blob de code intégré 32 Ko La taille d'un blob de code intégré dans une fonction définie par l'utilisateur peut atteindre 32 Ko.
Taille maximale de chaque ressource de code externe 1 Mo La taille maximale de chaque ressource de code JavaScript est de 1 Mo.

Les limites suivantes s'appliquent aux fonctions définies par l'utilisateur persistantes :

Limite Par défaut Remarques
Longueur maximale d'un nom de fonction définie par l'utilisateur 256 caractères Un nom de fonction définie par l'utilisateur peut comporter jusqu'à 256 caractères.
Nombre maximal d'arguments 256 Arguments Une fonction définie par l'utilisateur peut comporter jusqu'à 256 arguments.
Longueur maximale d'un nom d'argument 128 caractères Un nom d'argument de fonction définie par l'utilisateur peut comporter jusqu'à 128 caractères.
Profondeur maximale d'une chaîne de référence d'une fonction définie par l'utilisateur 16 Références Une chaîne de référence d'une fonction définie par l'utilisateur peut comprendre jusqu'à 16 références.
Profondeur maximale d'une sortie ou d'un argument de type STRUCT 15 Niveaux Une sortie ou un argument UDF de type STRUCT UDF peut comporter jusqu'à 15 niveaux de profondeur.
Nombre maximal de champs dans des arguments de type STRUCT ou en sortie par UDF 1 024 Champs Une fonction définie par l'utilisateur peut contenir jusqu'à 1 024 champs dans les arguments de type STRUCT et les résultats.
Nombre maximal de bibliothèques JavaScript dans une instruction CREATE FUNCTION 50 Bibliothèques Une instruction CREATE FUNCTION peut comporter jusqu'à 50 bibliothèques JavaScript.
Longueur maximale des chemins d'accès aux bibliothèques JavaScript incluses 5 000 caractères Le chemin d'accès à une bibliothèque JavaScript incluse dans une fonction définie par l'utilisateur peut comporter jusqu'à 5 000 caractères.
Fréquence maximale de mise à jour par fonction définie par l'utilisateur par intervalle de 10 secondes 5 mises à jour Votre projet peut mettre à jour une fonction définie par l'utilisateur jusqu'à cinq fois toutes les 10 secondes.
Nombre maximal d'UDF autorisées par ensemble de données Consultez la page Ensembles de données.

Fonctions à distance

Les limites suivantes s'appliquent aux fonctions distantes dans BigQuery.

Limite Par défaut Remarques
Nombre maximal de requêtes simultanées contenant des fonctions distantes 10 requêtes Vous pouvez exécuter jusqu'à dix requêtes simultanées avec des fonctions distantes par projet.
Taille maximale de l'entrée 5 Mo La taille totale maximale de tous les arguments d'entrée d'une seule ligne est de 5 Mo.
Taille limite des réponses HTTP (fonctions Cloud Run 1re génération) 10 Mo Le corps de la réponse HTTP de votre fonction Cloud Run 1re génération peut atteindre 10 Mo. Le dépassement de cette valeur entraîne des échecs de requêtes.
Limite de taille de réponse HTTP (fonctions Cloud Run 2e génération ou Cloud Run) 15 Mo Le corps de la réponse HTTP de votre fonction Cloud Run 2e génération ou de Cloud Run ne dépasse pas 15 Mo. Le dépassement de cette valeur entraîne des échecs de requêtes.
Durée maximale de l'appel HTTP (fonctions Cloud Run 1re génération) 9 minutes Vous pouvez définir votre propre limite de temps pour votre fonction Cloud Run de 1re génération pour un appel HTTP individuel, mais la limite de temps maximale est de 9 minutes. Le dépassement du délai défini pour votre fonction Cloud Run de 1re génération peut entraîner des échecs d'appels HTTP et des requêtes.
Durée maximale de l'appel HTTP (fonctions Cloud Run 2e génération ou Cloud Run) 20 minutes La limite de temps pour un appel HTTP individuel à votre fonction Cloud Run 2e génération ou Cloud Run. Le dépassement de cette valeur peut entraîner des échecs d'appels HTTP et des échecs de requête.
Nombre maximal de nouvelles tentatives d'appel HTTP 20 Nombre maximal de tentatives de nouvelle tentative pour un appel HTTP individuel à votre fonction Cloud Run 1re génération, 2e génération ou Cloud Run. Le dépassement de cette valeur peut entraîner des échecs d'appels HTTP et des échecs de requête.

Fonctions de table

Les limites suivantes s'appliquent aux fonctions de table BigQuery :

Limite Par défaut Remarques
Longueur maximale d'un nom de fonction de table 256 caractères Le nom d'une fonction de table peut comporter jusqu'à 256 caractères.
Longueur maximale d'un nom d'argument 128 caractères Le nom d'un argument de fonction de table peut comporter jusqu'à 128 caractères.
Nombre maximal d'arguments 256 Arguments Une fonction de table peut contenir jusqu'à 256 arguments.
Profondeur maximale d'une chaîne de référence de fonction de table 16 Références Une chaîne de référence de fonction de table peut comporter jusqu'à 16 références.
Profondeur maximale d'un argument ou d'une sortie de type STRUCT 15 Niveaux Un argument STRUCT pour une fonction de table peut comporter jusqu'à 15 niveaux de profondeur. De même, un enregistrement STRUCT dans le résultat d'une fonction de table peut contenir jusqu'à 15 niveaux de profondeur.
Nombre maximal de champs dans un argument ou une table de retour de type STRUCT par fonction de table 1 024 Champs Un argument STRUCT pour une fonction de table peut contenir jusqu'à 1 024 champs. De même, un enregistrement STRUCT dans le résultat d'une fonction de table peut contenir jusqu'à 1 024 champs.
Nombre maximal de colonnes dans le tableau des retours 1 024 colonnes Une table affichée par une fonction de table peut contenir jusqu'à 1 024 colonnes.
Longueur maximale des noms des colonnes des tables de retour 128 caractères Les noms de colonne des tables renvoyées peuvent comporter jusqu'à 128 caractères.
Nombre maximal de mises à jour par fonction de table pour 10 secondes 5 mises à jour Votre projet peut mettre à jour une fonction de table jusqu'à cinq fois toutes les 10 secondes.

Procédures stockées pour Apache Spark

Les limites suivantes s'appliquent aux procédures stockées BigQuery pour Apache Spark :

Limite Default Remarques
Nombre maximal de requêtes de procédures stockées simultanées 50 Vous pouvez exécuter jusqu'à 50 requêtes de procédures stockées simultanées pour chaque projet.
Nombre maximal de processeurs utilisés 12 000 Vous pouvez utiliser jusqu'à 12 000 processeurs simultanés pour chaque projet. Les requêtes déjà traitées ne sont pas comptabilisées dans cette limite.

Vous pouvez utiliser jusqu'à 2 400 processeurs pour chaque emplacement et chaque projet, sauf dans les emplacements suivants :

  • asia-south2
  • australia-southeast2
  • europe-central2
  • europe-west8
  • northamerica-northeast2
  • southamerica-west1

Vous pouvez utiliser jusqu'à 500 processeurs dans chaque emplacement pour chaque projet.

Si vous exécutez des requêtes simultanées dans un emplacement multirégional et dans un emplacement régional unique situé dans la même zone géographique, vos requêtes peuvent consommer le même quota de CPU simultané.

Taille maximale totale des disques persistants standard en cours d'utilisation 204,8 To

Vous pouvez utiliser jusqu'à 204,8 To de disques persistants standards pour chaque emplacement et chaque projet. Les requêtes déjà traitées ne sont pas comptabilisées dans cette limite.

Si vous exécutez des requêtes simultanées dans un emplacement multirégional et dans un emplacement régional unique situé dans la même zone géographique, vos requêtes peuvent consommer le même quota de disque persistant standard.

Notebooks

Tous les quotas et limites de Dataform, ainsi que les quotas et limites de Colab Enterprise, s'appliquent aux notebooks dans BigQuery. Les limites suivantes s'appliquent également :

Limite Default Notes
Taille maximale du notebook 20 Mo

La taille d'un notebook correspond au total de son contenu, de ses métadonnées et des frais généraux d'encodage.

Pour afficher la taille du contenu du notebook, développez l'en-tête du notebook, cliquez sur Afficher, puis sur Infos sur le notebook.

Nombre maximal de requêtes par seconde envoyées à Dataform 100 Les notebooks sont créés et gérés via Dataform. Toute action qui crée ou modifie un notebook est comptabilisée dans ce quota. Ce quota est partagé avec les requêtes enregistrées. Par exemple, si vous apportez 50 modifications aux notebooks et 50 modifications aux requêtes enregistrées sous une seconde, vous atteignez le quota.

Saved queries

Tous les quotas et limites de Dataform s'appliquent aux requêtes enregistrées. Les limites suivantes s'appliquent également :

Limite Default Notes
Taille maximale des requêtes enregistrées 10 Mo
Nombre maximal de requêtes par seconde envoyées à Dataform 100 Les requêtes enregistrées sont créées et gérées via Dataform. Toute action qui crée ou modifie une requête enregistrée est comptabilisée dans ce quota. Ce quota est partagé avec les notebooks. Par exemple, si vous apportez 50 modifications aux notebooks et 50 modifications aux requêtes enregistrées sous une seconde, vous atteignez le quota.

Langage de manipulation de données

Les limites suivantes s'appliquent aux instructions BigQuery langage de manipulation de données (LMD) :

Limite Par défaut Remarques
Instructions LMD par jour Illimité Votre projet peut exécuter un nombre illimité d'instructions LMD par jour.

Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de table par jour (ou dans le nombre de modifications de table partitionnée par jour pour les tables partitionnées).

Les instructions LMD sont soumises aux limites suivantes.
Instructions LMD INSERT simultanées par table et par jour 1 500 relevés Les 1 500 premières instructions INSERT s'exécutent immédiatement après leur envoi. Une fois cette limite atteinte, les instructions INSERT simultanées qui écrivent dans une table sont limitées à 10. Des instructions INSERT supplémentaires sont ajoutées à une file d'attente PENDING. Jusqu'à 100 instructions INSERT peuvent être placées en file d'attente sur une table à tout moment. Lorsqu'une instruction INSERT se termine, l'instruction INSERT suivante est supprimée de la file d'attente et exécutée.

Si vous devez exécuter des instructions LMD INSERT plus fréquemment, considérez la diffusion de données dans votre table à l'aide de l'API Storage Write.
Instructions LMD en mutation simultanées par table 2 instructions BigQuery exécute jusqu'à deux instructions LMD en mutation simultanées (UPDATE, DELETE et MERGE) par table. Les autres instructions LMD en mutation d'une table sont placées en file d'attente.
Instructions LMD en mutation en file d'attente par table 20 instructions Dans la file d'attente, une table peut contenir jusqu'à 20 instructions LMD en mutation en attente d'exécution. Si vous envoyez des instructions LMD en mutation supplémentaires pour la table, ces instructions échouent.
Temps maximal dans la file d'attente pour l'instruction LMD 6 heures Une instruction LMD interactive prioritaire peut être placée en file d'attente pendant six heures. Si l'instruction n'est pas exécutée au bout de six heures, elle échoue.
Taux maximal d'instructions LMD pour chaque table 25 instructions toutes les 10 secondes Votre projet peut exécuter jusqu'à 25 instructions LMD toutes les 10 secondes pour chaque table. Les instructions LMD INSERT et les instructions LMD de mutation contribuent à cette limite.

Pour en savoir plus sur les instructions LMD en mutation, consultez les sections INSERT LMD simultané et UPDATE, DELETE, MERGE LMD simultané.

Requêtes à plusieurs instructions

Les limites suivantes s'appliquent aux requêtes à plusieurs instructions dans BigQuery.

Limite Par défaut Remarques
Nombre maximal de requêtes à plusieurs instructions simultanées 1 000 requêtes à plusieurs instructions Votre projet peut exécuter jusqu'à 1 000 requêtes à plusieurs instructions simultanées.
Limite de temps cumulé 24 heures La limite de temps cumulé pour une requête à plusieurs instructions est de 24 heures.
Durée maximale de l'instruction 6 heures Le délai d'une instruction dans une requête à plusieurs instructions est de 6 heures.

CTE récursifs dans les requêtes

Les limites suivantes s'appliquent aux expressions de table courantes (CTE) récursives dans BigQuery.

Limite Par défaut Remarques
Limite d'itération 500 iterations Le CTE récursif peut exécuter ce nombre d'itérations. Si cette limite est dépassée, une erreur est générée. Pour contourner les limites d'itération, consultez la page Résoudre les erreurs de limite d'itération.

Sécurité au niveau des lignes

Les limites suivantes s'appliquent aux règles d'accès au niveau de la ligne de BigQuery :

Limite Default Notes
Nombre maximal de règles d'accès aux lignes par table. 400 règles Une table peut contenir jusqu'à 400 règles d'accès aux lignes.
Nombre maximal de règles d'accès aux lignes par requête. 6000 règles Une requête peut accéder jusqu'à 6000 règles d'accès aux lignes.
Nombre maximal d'instructions LDD CREATE / DROP par règle pour 10 secondes Cinq instructions Votre projet peut créer jusqu'à cinq instructions CREATE ou DROP par ressource de règle d'accès aux lignes toutes les 10 secondes.
Instructions DROP ALL ROW ACCESS POLICIES par table et par période de 10 secondes Cinq instructions Votre projet peut générer jusqu'à cinq instructions DROP ALL ROW ACCESS POLICIES par table toutes les 10 secondes.

Règles concernant les données

Les limites suivantes s'appliquent au masquage des données dynamiques au niveau des colonnes :

Limite Par défaut Remarques
Nombre maximal de stratégies de données par tag avec stratégie. 8 règles par tag avec stratégie Jusqu'à huit stratégies de données par tag avec stratégie. L'une de ces règles peut être utilisée pour les contrôles des accès au niveau des colonnes. Les expressions de masquage en double ne sont pas acceptées.

BigQuery ML

Les limites suivantes s'appliquent à BigQuery ML.

Tâches de requête

Tous les quotas et limites des jobs de requête s'appliquent aux jobs de requête GoogleSQL qui utilisent des instructions et des fonctions BigQuery ML.

Instructions CREATE MODEL

Les limites suivantes s'appliquent aux jobs CREATE MODEL :

Limite Par défaut Remarques
Requêtes avec instruction CREATE MODEL par période de 48 heures pour chaque projet 20 000 requête avec instruction Certains modèles sont entraînés à l'aide de services Vertex IA, qui possèdent leur propre gestion des ressources et des quotas.
Limite de durée d'exécution 24 ou 72 heures Le délai avant expiration du job CREATE MODEL est défini par défaut sur 24 heures, à l'exception des job de série temporelle, des jobs AutoML et des jobs de réglage d'hyperparamètres qui expirent après 72 heures.

Fonctions des services Vertex AI et Cloud AI

Les limites suivantes s'appliquent aux fonctions qui utilisent des modèles de langage volumineux (LLM) de Vertex AI et des services d'IA dans le cloud :

Fonction Requêtes par minute Lignes par job Nombre de jobs exécutés simultanément
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle gemini-1.5-pro 60 21 600 5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle gemini-1.5-flash 200 72 000 5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur le modèle gemini-1.0-pro-vision dans la région us-central1 100 20 000 1
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur le modèle gemini-1.0-pro-vision dans des régions autres que us-central1 10 3 600 1
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle gemini-1.0-pro dans la région us-central1 300 108 000 5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle gemini-1.0-pro dans des régions autres que us-central1 10 3 600 5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle Anthropic Claude 30 10 800 5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle text-bison 1 600 576 000 5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle text-bison-32 300 108 000 5
ML.GENERATE_EMBEDDING en cas d'utilisation avec des modèles distants via des modèles Vertex AI multimodalembedding dans les régions européennes uniques compatibles 120 14 000 5
ML.GENERATE_EMBEDDING en cas d'utilisation avec des modèles distants via des modèles Vertex AI multimodalembedding dans des régions autres que les régions européennes uniques compatibles 600 25 000 5
ML.GENERATE_EMBEDDING en cas d'utilisation avec des modèles distants via des modèles Vertex AI text-embedding et text-multilingual-embedding dans la région us-central1 1 500 2 700 000 1
ML.GENERATE_EMBEDDING en cas d'utilisation avec des modèles distants via des modèles Vertex AI text-embedding et text-multilingual-embedding dans des régions autres que us-central1 100 324 000 1
ML.PROCESS_DOCUMENT, avec des documents d'une page en moyenne 600 150 000 5
ML.PROCESS_DOCUMENT, avec des documents d'une dizaine de pages en moyenne 600 100 000 5
ML.PROCESS_DOCUMENT, avec des documents d'une moyenne de 50 pages 600 15 000 5
ML.TRANSCRIBE 200 10 000 5
ML.ANNOTATE_IMAGE 1 800 648 000 5
ML.TRANSLATE 6 000 2 160 000 5
ML.UNDERSTAND_TEXT 600 21 600 5

Pour en savoir plus sur les quotas applicables aux LLM Vertex AI et aux API des services Cloud AI, consultez les documents suivants :

Le quota de lignes par tâche représente le nombre maximal théorique de lignes que le système peut gérer dans un délai de six heures. Le nombre réel de lignes traitées dépend de nombreux autres facteurs, y compris la taille de l'entrée et l'état du réseau. Par exemple, ML.TRANSCRIBE peut traiter plus d'audios courts que d'audios longs.

Pour demander une augmentation de quota pour des fonctions BigQuery ML, ajustez d'abord le quota pour le LLM Vertex AI ou le service Cloud AI associé, puis envoyez un e-mail à bqml-feedback@google.com en incluant les informations sur le quota ajusté pour le LLM ou le service Cloud AI. Pour plus d'informations sur la demande d'augmentation de quota pour ces services, consultez la page Demander une augmentation de quota.

Définitions des quotas

La liste suivante décrit les quotas qui s'appliquent aux fonctions des services Vertex AI et Cloud AI :

  • Les fonctions qui appellent un modèle de fondation Vertex AI utilisent un quota Vertex AI, à savoir le nombre de requêtes par minute (RPM). Dans ce contexte, les requêtes sont des appels de requête lancés par la fonction, à destination de l'API du modèle Vertex AI. Le quota de RPM s'applique à un modèle de base et à l'ensemble des versions, identifiants et versions réglées de ce modèle. Pour en savoir plus sur les quotas relatifs aux modèles de fondation Vertex AI, consultez la page Quotas par région et par modèle.
  • Les fonctions qui appellent un service Cloud AI utilisent les quotas de requêtes du service cible. Consultez la documentation de référence sur les quotas du service Cloud AI concerné pour plus de détails.
  • BigQuery ML utilise trois quotas :

    • Requêtes par minute. Ce quota correspond au nombre maximal d'appels de requête par minute que les fonctions peuvent effectuer sur l'API du modèle Vertex AI ou du service Cloud AI. Cette limite s'applique à chaque projet.

      Pour les fonctions qui appellent un modèle de fondation Vertex AI, le nombre d'appels de requêtes par minute varie en fonction du point de terminaison, de la version et de la région du modèle Vertex AI. Ce quota est conceptuellement identique au quota de RPM utilisé par Vertex AI, mais sa valeur peut être inférieure à celle du quota de RPM pour un modèle correspondant.

    • Lignes par job. Ce quota correspond au nombre maximal de lignes autorisées pour chaque job de requête.

    • Nombre de jobs exécutés simultanément. Ce quota correspond au nombre maximal de requêtes SQL, par projet, pouvant être exécutées simultanément pour la fonction concernée.

Les exemples suivants montrent comment interpréter les limites de quota dans des situations types :

  • J'ai un quota de 1 000 RPM dans Vertex AI. Une requête portant sur 100 000 lignes devrait donc prendre environ 100 minutes. Alors pourquoi le job prend-il plus de temps ?

    Les environnements d'exécution d'un job peuvent varier, même avec des données d'entrée identiques. Dans Vertex AI, les appels de procédure à distance (RPC) ont des priorités différentes afin d'éviter le drainage des quotas. Lorsque le quota est insuffisant, les RPC ayant des priorités inférieures sont mis en attente et peuvent finir par échouer, si leur traitement prend trop de temps.

  • Comment dois-je interpréter le quota de lignes par job ?

    Dans BigQuery, une requête peut s'exécuter pendant un maximum de six heures. Le nombre maximal de lignes acceptées varie selon cette chronologie et votre quota de RPM Vertex AI, afin de garantir que BigQuery peut achever le traitement de la requête en six heures. Étant donné qu'une requête ne peut généralement pas utiliser l'intégralité du quota, ce nombre est inférieur à votre quota de RPM multiplié par 360.

  • Que se passe-t-il si j'exécute un job d'inférence par lot sur une table qui contient plus de lignes que le quota de lignes par job (par exemple, 10 millions de lignes) ?

    BigQuery ne traite que le nombre de lignes spécifié par le quota de lignes par job. Vous êtes facturé uniquement pour les appels d'API réussis pour ce nombre de lignes, et non pour l'ensemble des 10 millions de lignes de votre table. Pour les autres lignes, BigQuery répond à la requête avec une erreur A retryable error occurred: the maximum size quota per query has reached, qui est renvoyée dans la colonne status du résultat. Vous pouvez utiliser cet ensemble de scripts SQL ou ce package Dataform pour effectuer une itération des appels d'inférence jusqu'à ce que toutes les lignes soient traitées avec succès.

  • J'ai beaucoup plus de lignes à traiter que ce qu'autorise le quota de lignes par job. Puis-je m'en sortir en répartissant les lignes sur plusieurs requêtes et en les exécutant simultanément ?

    Non, car ces requêtes consomment les mêmes quotas de requêtes BigQuery ML par minute et de RPM Vertex AI. Si vous définissez plusieurs requêtes qui restent toutes dans les limites du quota de lignes par job et du quota de nombre de jobs exécutés simultanément, le traitement cumulé va épuiser le quota de requêtes par minute.

BI Engine

Les limites suivantes s'appliquent à BigQuery BI Engine.

Limite Par défaut Remarques
Taille maximale de réservation par projet et par emplacement (interface SQL 250 Gio S'applique lors de l'utilisation de BI Engine avec BigQuery. S'applique dans tous les cas, sauf pour Looker Studio sans intégration native.

Vous pouvez demander une augmentation de la capacité de réservation maximale pour vos projets. Les augmentations de réservation sont disponibles dans la plupart des régions et leur traitement peut prendre de trois jours à une semaine.
Nombre maximal de lignes par requête 7 milliards Nombre maximal de lignes par requête.

Analytics Hub

Les limites suivantes s'appliquent à Analytics Hub :

Limite Par défaut Remarques
Nombre maximal d'échanges de données par projet 500 échanges Vous pouvez créer jusqu'à 500 échanges de données dans un projet.
Nombre maximal de fiches par échange de données 1 000 fiches Vous pouvez créer jusqu'à 1 000 fiches dans un échange de données.
Nombre maximal d'ensembles de données associés par ensemble de données partagé 1 000 ensembles de données associés Tous les abonnés Analytics Hub combinés peuvent posséder un maximum de 1 000 ensembles de données associés par ensemble de données partagé.

Quotas et limites des API

Ces quotas et limites s'appliquent aux requêtes de l'API BigQuery.

API BigQuery

Les quotas suivants s'appliquent aux requêtes API BigQuery (cœur) :

Quotas Par défaut Remarques
Requêtes par jour Illimité Votre projet peut effectuer un nombre illimité de requêtes API BigQuery par jour.
Afficher le quota dans la console Google Cloud
Nombre maximal d'octets tabledata.list par minute 7,5 Go dans les emplacements multirégionaux et 3,7 Go dans toutes les autres régions Votre projet peut renvoyer jusqu'à 7,5 Go de données de ligne de table par minute via tabledata.list dans les emplacements multirégionaux us et eu, et 3,7 Go de données de ligne de table par minute dans toutes les autres régions. Ce quota s'applique au projet contenant la table en cours de lecture. D'autres API, y compris jobs.getQueryResults, et extrayant les résultats de jobs.query et jobs.insert peuvent également consommer ce quota.
Afficher le quota dans la console Google Cloud

L'API BigQuery Storage Read peut gérer un débit beaucoup plus élevé que tabledata.list. Si vous avez besoin d'un débit supérieur à celui autorisé sous ce quota, envisagez d'utiliser l'API BigQuery Storage Read.

Les limites suivants s'appliquent aux requêtes API BigQuery (cœur) :

Limite Par défaut Remarques
Nombre maximal de requêtes API par seconde, par utilisateur et par méthode 100 requêtes Un utilisateur peut envoyer jusqu'à 100 requêtes API par seconde à une méthode d'API. Si un utilisateur envoie plus de 100 requêtes par seconde à une méthode, un ralentissement du débit peut survenir. Cette limite ne s'applique pas aux insertions en flux continu.
Nombre maximal de requêtes API simultanées par utilisateur 300 requêtes Si un utilisateur effectue plus de 300 requêtes simultanées, cela peut entraîner une limitation. Cette limite ne s'applique pas aux insertions en flux continu.
Taille maximale de l'en-tête de requête 16 Kio Une requête API BigQuery ne peut pas dépasser 16 Kio, en incluant l'URL de la requête et tous les en-têtes. Cette limite ne s'applique pas au corps de la requête, comme dans une requête POST.
Nombre maximal de requêtes jobs.get par seconde 1 000 requêtes Votre projet peut effectuer jusqu'à 1 000 requêtes jobs.get par seconde.
Taille maximale des réponses jobs.query 20 Mo Par défaut, il n'existe aucun nombre maximal pour les lignes de données renvoyées par jobs.query par page de résultats. Cependant, vous êtes tenu de respecter la limite maximale de 20 Mo pour la taille des réponses. Pour modifier le nombre de lignes à renvoyer, utilisez le paramètre maxResults.
Taille maximale des lignes jobs.getQueryResults 20 Mo La taille maximale des lignes est approximative, car la limite est basée sur la représentation interne des données de ligne. La limite est appliquée lors du transcodage.
Nombre maximal de requêtes projects.list par seconde 2 requêtes Votre projet peut envoyer jusqu'à deux requêtes projects.list par seconde.
Nombre maximal de requêtes tabledata.list par seconde 1 000 requêtes Votre projet peut effectuer jusqu'à 1 000 requêtes tabledata.list par seconde.
Nombre maximal de lignes par réponse tabledata.list 100 000 Lignes Un appel tabledata.list peut renvoyer jusqu'à 100 000 lignes de table. Pour en savoir plus, consultez la section Parcourir des résultats à l'aide de l'API.
Taille maximale des lignes tabledata.list 100 Mo La taille maximale des lignes est approximative, car la limite est basée sur la représentation interne des données de ligne. La limite est appliquée lors du transcodage.
Nombre maximal de requêtes tables.insert par seconde Dix requêtes Votre projet peut effectuer jusqu'à 10 requêtes tables.insert par seconde. La méthode tables.insert permet de créer une table vide dans un ensemble de données. Cette limite inclut les instructions SQL qui créent des tables, telles que CREATE TABLE, et les requêtes qui écrivent les résultats dans des tables de destination.

API BigQuery Connection

Les quotas suivants s'appliquent aux requêtes de l'API BigQuery Connection :

Quotas Par défaut Remarques
Requêtes de lecture par minute 1 000 requêtes par minute Votre projet peut envoyer jusqu'à 1 000 requêtes par minute aux méthodes de l'API BigQuery Connection qui lisent des données de connexion.
Afficher le quota dans la console Google Cloud
Requêtes d'écriture par minute 100 requêtes par minute Votre projet peut envoyer jusqu'à 100 requêtes par minute aux méthodes de l'API BigQuery Connection qui créent ou mettent à jour des connexions.
Afficher le quota dans la console Google Cloud
Connexions BigQuery Omni créées par minute 10 connexions créées par minute Votre projet peut créer jusqu'à 10 connexions BigQuery Omni au total sur AWS et Azure par minute.
Utilisations de la connexion BigQuery Omni 100 connexions par minute Votre projet peut utiliser une connexion BigQuery Omni jusqu'à 100 fois par minute. Cela s'applique aux opérations qui utilisent votre connexion pour accéder à votre compte AWS, comme l'interrogation d'une table.

API BigQuery Migration

Les limites suivantes s'appliquent à l'API BigQuery Migration :

Limite Par défaut Remarques
Taille individuelle des fichiers pour la traduction SQL par lot 10 Mo La taille maximale de chaque fichier source et de métadonnée est de 10 Mo. Cette limite ne s'applique pas au fichier ZIP de métadonnées généré par l'outil d'extraction sur ligne de commande dwh-migration-dumper.
Taille totale des fichiers sources pour la traduction SQL par lot 1 GB La taille totale maximale de tous les fichiers d'entrée importés dans Cloud Storage est de 1 Go. Cela inclut tous les fichiers sources ainsi que tous les fichiers de métadonnées si vous décidez de les inclure.
Taille de chaîne d'entrée pour la traduction SQL interactive 1 Mo La chaîne que vous saisissez pour la traduction SQL interactive ne doit pas dépasser 1 Mo. Lorsque vous exécutez des traductions interactives à l'aide de l'API Translation, cette limite s'applique à la taille totale de toutes les entrées de chaîne.
Taille maximale du fichier de configuration pour la traduction SQL interactive 50 Mo Les fichiers de métadonnées individuels (compressés) et les fichiers de configuration YAML dans Cloud Storage ne doivent pas dépasser 50 Mo. Si la taille d'un fichier dépasse 50 Mo, le traducteur interactif ignore ce fichier de configuration lors de la traduction et génère un message d'erreur. Une méthode permettant de réduire la taille des fichiers de métadonnées consiste à utiliser l'option —database ou –schema pour filtrer les bases de données lorsque vous générez les métadonnées.

Les quotas suivants s'appliquent à l'API BigQuery Migration. Les valeurs par défaut suivantes s'appliquent dans la plupart des cas. Les valeurs par défaut de votre projet peuvent être différentes :

Quotas Par défaut Remarques

Requêtes de liste d'EDWMigration Service par minute

Requêtes de listes d'EDWMigration Service par minute et par utilisateur

12 000 requêtes

2 500 requêtes

Votre projet peut envoyer jusqu'à 12 000 requêtes de liste de l'API Migration par minute.

Chaque utilisateur peut générer jusqu'à 2 500 requêtes de liste de l'API Migration par minute.

Consulter les quotas dans la console Google Cloud

Demandes GET d'EDWMigration Service par minute

Demandes GET d'EDWMigration Service par minute et par utilisateur

25 000 requêtes

2 500 requêtes

Votre projet peut générer jusqu'à 25 000 requêtes GET de l'API Migration par minute.

Chaque utilisateur peut générer jusqu'à 2 500 requêtes GET de l'API Migration par minute.

Consulter les quotas dans la console Google Cloud

Autres requêtes d'EDWMigration Service par minute

Autres requêtes d'EDWMigration Service par minute et par utilisateur

25 requêtes

5 requêtes

Votre projet peut envoyer jusqu'à 25 autres requêtes de l'API Migration par minute.

Chaque utilisateur peut envoyer jusqu'à 5 autres requêtes de l'API Migration par minute.

Consulter les quotas dans la console Google Cloud

Requêtes de traduction SQL interactives par minute

Requêtes de traduction SQL interactives par minute et par utilisateur

200 requêtes

50 requêtes

Votre projet peut envoyer jusqu'à 200 requêtes de service de traduction SQL par minute.

Chaque utilisateur peut envoyer jusqu'à 50 autres requêtes de service de traduction SQL par minute.

Consulter les quotas dans la console Google Cloud

API BigQuery Reservation

Les quotas suivants s'appliquent aux requêtes API BigQuery Reservation :

Quotas Par défaut Remarques
Requêtes par minute et par région 100 requêtes Votre projet peut effectuer jusqu'à 100 appels vers les méthodes de l'API BigQuery Reservations par minute et par région.
Afficher les quotas dans la console Google Cloud
Nombre d'appels SearchAllAssignments par minute et par région 100 requêtes Votre projet peut envoyer jusqu'à 100 appels vers la méthode SearchAllAssignments par minute et par région.
Afficher les quotas dans la console Google Cloud
Requêtes pour SearchAllAssignments par minute, par région et par utilisateur Dix requêtes Chaque utilisateur peut envoyer jusqu'à 10 appels à la méthode SearchAllAssignments par minute et par région.
Afficher les quotas dans la console Google Cloud
(Dans les résultats de recherche de la console Google Cloud, recherchez par utilisateur.)

API BigQuery DataPolicy

Les limites suivantes s'appliquent à l'API Data Policy (aperçu) :

Limite Par défaut Remarques
Nombre maximal d'appels dataPolicies.list. 400 requêtes par minute et par projet

600  requêtes par minute et par organisation
Nombre maximal d'appels dataPolicies.testIamPermissions. 400 requêtes par minute et par projet

600  requêtes par minute et par organisation
Nombre maximal de requêtes de lecture . 1 200 requêtes par minute et par projet

1 800 requêtes par minute et par organisation
Cela inclut les appels vers dataPolicies.get et dataPolicies.getIamPolicy.
Nombre maximal de requêtes d'écriture. 600 requêtes par minute et par projet

900 requêtes par minute et par organisation

Cela inclut les appels à :

API IAM

Les quotas suivants s'appliquent lorsque vous utilisez la fonctionnalité Gestion de l'authentification et des accès dans BigQuery pour récupérer et définir des stratégies IAM, et pour tester des autorisations IAM. Les instructions de langage de contrôle des données (LCD) sont comptabilisées dans le quota SetIAMPolicy.

Quotas Par défaut Notes
IamPolicy requêtes par minute et par utilisateur 1 500 requêtes par minute et par utilisateur Chaque utilisateur peut générer jusqu'à 1 500 requêtes IAM par minute et par projet.
Afficher le quota dans la console Google Cloud
IamPolicy requêtes par minute et par projet 3 000 requêtes par minute et par projet Votre projet peut générer jusqu'à 3 000 requêtes IAM par minute.
Afficher le quota dans la console Google Cloud
Requêtes régionales SetIAMPolicy par minute et par projet 1 000 requêtes par minute et par projet Votre projet à région unique peut générer jusqu'à 1 000 requêtes par minute.
Afficher le quota dans la console Google Cloud
Requêtes SetIAMPolicy multirégionales par minute et par projet 2 000 requêtes par minute et par projet Votre projet multirégional peut générer jusqu'à 2 000 requêtes par minute.
Afficher le quota dans la console Google Cloud
Requêtes SetIAMPolicy pour les Régions Omni par minute et par projet 200 requêtes par minute et par projet Votre projet pour les régions omni peut envoyer jusqu'à 200 requêtes par minute.
Afficher le quota dans la console Google Cloud

API Storage Read

Les quotas suivants s'appliquent aux requêtes de l'API BigQuery Storage Read :

Quota Par défaut Remarques
Requêtes de lecture du plan de données par minute et par utilisateur 25 000 requêtes Chaque utilisateur peut effectuer jusqu'à 25 000 appels ReadRows par minute et par projet.
Afficher le quota dans la console Google Cloud
Requêtes de lecture du plan de contrôle par minute et par utilisateur 5 000 requêtes Chaque utilisateur peut effectuer jusqu'à 5 000 appels d'opérations de métadonnées d'API Read Storage par minute et par projet. Les appels de métadonnées incluent les méthodes CreateReadSession et SplitReadStream.
Afficher le quota dans la console Google Cloud

Les limites suivantes s'appliquent aux requêtes de l'API BigQuery Storage Read :

Limite Par défaut Remarques
Longueur maximale de ligne/filtre 1 Mo Lorsque vous utilisez l'appel CreateReadSession de l'API Storage Read, vous êtes limité à 1 Mo au maximum pour chaque ligne ou filtre.
Taille maximale des données sérialisées 128 Mo Lorsque vous utilisez l'appel ReadRows de l'API Storage Read, la représentation sérialisée des données dans un message ReadRowsResponse individuel ne peut pas dépasser 128 Mo.
Nombre maximal de connexions simultanées 2 000 dans les emplacements multirégionaux, 400 dans les régions Vous pouvez ouvrir jusqu'à 2 000 connexions ReadRows simultanées par projet dans les emplacements multirégionaux us et eu, et 400 connexions ReadRows simultanées dans d'autres régions. Dans certains cas, vous pouvez être soumis à un nombre de connexions simultanées inférieur à cette limite.
Utilisation maximale de la mémoire par flux 1,5 Go La mémoire maximale par flux est approximative, car la limite est basée sur la représentation interne des données de ligne. Les flux utilisant plus de 1,5 Go de mémoire pour une seule ligne peuvent échouer. Pour en savoir plus, consultez la page Résoudre les problèmes liés au dépassement de ressources.

API Storage Write

Les quotas suivants s'appliquent aux requêtes API Storage Write : Les quotas suivants peuvent être appliqués au niveau du dossier. Ces quotas sont ensuite agrégés et partagés entre tous les projets enfants. Pour activer cette configuration, contactez l'assistance Cloud Customer Care.

Si vous prévoyez de demander une augmentation de limite de quota, incluez le message d'erreur dans votre demande pour accélérer le traitement.

Quota Par défaut Remarques
Connexions simultanées 1 000 dans une région ; 10 000 dans un emplacement multirégional

Le quota de connexions simultanées est basé sur le projet client qui lance la requête de l'API Storage Write, et non sur le projet contenant la ressource d'ensemble de données BigQuery. Le projet initiateur est celui associé à la clé d'API ou au compte de service.

Votre projet peut fonctionner sur 1 000 connexions simultanées dans une région ou 10 000 connexions simultanées dans les emplacements multirégionaux US et EU.

Lorsque vous utilisez le flux par défaut en Java ou Go, nous vous recommandons d'utiliser le multiplexage de l'API Storage Write pour écrire dans plusieurs tables de destination avec des connexions partagées afin de réduire le nombre de connexions globales nécessaires. Si vous utilisez le connecteur Beam avec une sémantique "au moins une fois", vous pouvez définir UseStorageApiConnectionPool sur TRUE pour activer le multiplexage.

Afficher le quota dans la console Google Cloud

Vous pouvez consulter les métriques de quota d'utilisation et de limites de vos projets dans Cloud Monitoring. Sélectionnez le nom de la limite de connexions simultanées en fonction de votre région. Les options sont ConcurrentWriteConnectionsPerProject, ConcurrentWriteConnectionsPerProjectEU et ConcurrentWriteConnectionsPerProjectRegion pour us, eu et les autres régions, respectivement.

Nous vous recommandons vivement de configurer des alertes pour surveiller votre utilisation et vos limites de quota. De plus, si vos modèles de trafic connaissent des pics et/ou une croissance naturelle régulière, vous pouvez envisager de surprovisionner votre quota de 25 à 50 % afin de gérer la demande inattendue.

Débit Débit de 3 Go par seconde dans les emplacements multirégionaux ; 300 Mo par seconde dans les régions Vous pouvez diffuser jusqu'à 3 Go/s dans les emplacements multirégionaux us et eu, et 300 Mbit/s dans les autres régions par projet.
Afficher le quota dans la console Google Cloud

Vous pouvez consulter les métriques de quota d'utilisation et de limites de vos projets dans Cloud Monitoring. Sélectionnez le nom de la limite de débit en fonction de votre région. Les options sont AppendBytesThroughputPerProject, AppendBytesThroughputPerProjectEU et AppendBytesThroughputPerProjectRegion pour us, eu et les autres régions, respectivement. Le quota de débit en écriture est mesuré en fonction du projet où réside l'ensemble de données cible, et non du projet client.

Nous vous recommandons vivement de configurer des alertes pour surveiller votre utilisation et vos limites de quota. De plus, si vos modèles de trafic connaissent des pics et/ou une croissance naturelle régulière, vous pouvez envisager de surprovisionner votre quota de 25 à 50 % afin de gérer la demande inattendue.


Requêtes CreateWriteStream 10 000 diffusions par heure, par projet et par région Vous pouvez appeler CreateWriteStream jusqu'à 10 000 fois par heure, par projet et par région. Envisagez d'utiliser le flux par défaut si vous n'avez pas besoin d'une sémantique de type "exactement une fois". Ce quota est calculé par heure, mais la métrique affichée dans la console Google Cloud est par minute.
Octets de flux en attente 10 To dans les emplacements multirégionaux et 1 To dans les régions Pour chaque commit que vous déclenchez, vous pouvez valider jusqu'à 10 To dans les emplacements multirégionaux us et eu, et 1 To dans les autres régions. Aucun rapport sur les quotas n'est disponible pour ce quota.

Les limites suivantes s'appliquent aux requêtes d'API Storage Write :

Limite Par défaut Remarques
Commits par lot 10 000 diffusions par table Vous pouvez valider jusqu'à 10 000 diffusions dans chaque appel BatchCommitWriteStream.
Taille de requête AppendRows 10 Mo La taille maximale de la requête est de 10 Mo.

Insertions en flux continu

Les quotas et limites suivants s'appliquent lorsque vous insérez des données en flux continu dans BigQuery à l'aide de l'ancienne API de streaming. Pour découvrir des stratégies qui vous aideront à respecter ces limites, consultez la page Dépannage des erreurs de quota. Si vous dépassez ces quotas, des erreurs quotaExceeded sont générées.

Limite Par défaut Remarques
Nombre maximal d'octets par seconde et par projet dans les emplacements multirégionaux us et eu 1 Go par seconde

Votre projet peut diffuser jusqu'à 1 Go par seconde. Ce quota est cumulatif au sein d'un emplacement multirégional donné. En d'autres termes, la somme des octets par seconde transmis à l'ensemble des tables pour un projet donné au sein d'un emplacement multirégional est limitée à 1 Go.

Le dépassement de cette limite entraîne des erreurs quotaExceeded.

Si nécessaire, vous pouvez demander une augmentation de quota en contactant Cloud Customer Care. Demandez une augmentation dès que possible, au moins deux semaines avant que vous n'en ayez besoin. Il faut du temps pour augmenter les quotas, en particulier dans le cas d'une augmentation significative.

Nombre maximal d'octets par seconde et par projet dans tous les autres emplacements 300 Mo par seconde

Votre projet peut diffuser jusqu'à 300 Mo par seconde dans tous les emplacements sauf les emplacements multirégionaux us et eu. Ce quota est cumulatif au sein d'un emplacement multirégional donné. En d'autres termes, la somme des octets par seconde transmis à l'ensemble des tables pour un projet donné au sein d'un emplacement régional est limitée à 300 Mo.

Le dépassement de cette limite entraîne des erreurs quotaExceeded.

Si nécessaire, vous pouvez demander une augmentation de quota en contactant Cloud Customer Care. Demandez une augmentation dès que possible, au moins deux semaines avant que vous n'en ayez besoin. Il faut du temps pour augmenter les quotas, en particulier dans le cas d'une augmentation significative.

Taille maximale des lignes 10 Mo Si vous dépassez cette valeur, des erreurs invalid sont générées.
Taille limite des requêtes HTTP 10 Mo

Si vous dépassez cette valeur, des erreurs invalid sont générées.

En interne, la requête est traduite de HTTP JSON en une structure de données interne. La structure de données traduite applique sa propre limite de taille. Il est difficile de prédire la taille de la structure de données interne obtenue. Toutefois, si vous conservez des requêtes HTTP de 10 Mo ou moins, le risque d'atteindre la limite interne est faible.

nombre maximal de lignes par requête 50 000 Lignes Nous recommandons un maximum de 500 lignes. La mise en lots peut augmenter les performances et le débit jusqu'à un certain point, mais au prix d'une latence des requêtes. Si le nombre de lignes par requête est trop faible, l'impact de chaque requête peut rendre l'ingestion inefficace. Si le nombre de lignes par requête est trop important, le débit peut s'affaiblir. Testez des données représentatives (tailles de schémas et de données) pour déterminer la taille de lot idéale pour vos données.
Longueur du champ insertId 128 caractères Si vous dépassez cette valeur, des erreurs invalid sont générées.

Pour obtenir des quotas de streaming supplémentaires, consultez la page Demander une augmentation de quota.

Bande passante

Les quotas suivants s'appliquent à la bande passante de réplication:

Quota Par défaut Remarques
Bande passante de réplication de remplissage initial maximale pour chaque région ayant une sortie de données interrégionale du réplica principal vers les réplicas secondaires. Quota de 10 Gbit/s physiques par région pour la plupart des projets
Bande passante de réplication maximale en cours pour chaque région ayant une sortie de données interrégionale du réplica principal vers les réplicas secondaires. Quota de 5 Gio/s physiques par région pour la plupart des projets
Bande passante maximale de la réplication turbo pour chaque région ayant une sortie de données interrégionale du réplica principal vers les réplicas secondaires. Quota par défaut de 5 Gio/s physiques par région pour la plupart des projets Le quota de bande passante de réplication turbo ne s'applique pas à l'opération de remplissage initiale.

Lorsque la bande passante de réplication d'un projet dépasse un certain quota, la réplication des projets concernés peut s'arrêter avec l'erreur rateLimitExceeded qui inclut les détails du quota dépassé.