Quotas et limites

Les listes ci-dessous décrivent les limites de débit et de quota de BigQuery.

BigQuery limite le taux maximal de requêtes entrantes et applique des quotas appropriés par projet. Les règles spécifiques varient en fonction de la disponibilité des ressources, du profil de l'utilisateur, de l'historique d'utilisation du service et d'autres facteurs. Elles peuvent en outre être modifiées sans préavis.

Demander une augmentation de quota

  • Certains quotas BigQuery s'affichent dans Google Cloud Console. Pour ces quotas, vous pouvez demander une augmentation de quota à l'aide de Cloud Console. Pour obtenir des instructions détaillées tout au long de ce processus, consultez le tutoriel Demander une augmentation de quota dans Google Cloud Console :

    VISITE GUIDÉE

  • Pour demander une augmentation des quotas qui ne sont pas affichés dans Google Cloud Console, contactez le service client Cloud.

  • Certains quotas et limites ne peuvent pas être augmentés. par exemple, les quotas et limites qui protègent le système.

Pour plus d'informations, consultez la page Demander une limite de quota supérieure.

Tâches de requête

Les limites ci-dessous s'appliquent aux tâches de requête créées automatiquement via l'exécution de requêtes interactives, ainsi qu'aux tâches exécutées de manière automatisée à l'aide d'appels de méthode jobs.query et jobs.insert de type requête.

  • Limite de débit simultané pour les requêtes interactives : 100 requêtes simultanées par projet

    Les requêtes dont les résultats sont renvoyés par le cache de requêtes sont prises en compte dans cette limite jusqu'à ce que BigQuery détermine qu'il s'agit d'un succès de cache. Les requêtes de simulation ne sont pas prises en compte dans cette limite. Vous pouvez spécifier une requête de simulation à l'aide de l'option --dry_run.

    Pour en savoir plus sur les stratégies permettant de respecter cette limite, consultez la page Résoudre les erreurs de quota. Pour augmenter cette limite, veuillez contacter le service client ou le service commercial.

  • Limite de débit simultané pour les requêtes interactives sur les sources de données externes Cloud Bigtable : 4 requêtes simultanées

    Il est possible d'exécuter jusqu'à quatre requêtes simultanées sur une source de données externe Bigtable.

  • Limite de débit simultané pour les requêtes en ancien SQL contenant des fonctions définies par l'utilisateur : 6 requêtes simultanées

    La limite de débit simultané pour les requêtes en ancien SQL contenant des fonctions définies par l'utilisateur 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 débit simultané pour les requêtes interactives. Cette limite ne s'applique pas aux requêtes en SQL standard.

  • Requêtes fédérées interrégionales : 1 To par projet et par jour

    Si l'emplacement de traitement des requêtes BigQuery et l'emplacement de l'instance Cloud SQL sont différents, il s'agit d'une requête interrégionale. Vous pouvez exécuter jusqu'à 1 To de requêtes interrégionales par projet et par jour. Consultez la page Requêtes fédérées Cloud SQL.

  • Limite de taille quotidienne des requêtes : illimitée par défaut

    Vous pouvez spécifier des limites sur la quantité de données que les utilisateurs peuvent interroger en définissant des quotas personnalisés.

  • Limite de mise à jour quotidienne des tables de destination : 1 500 mises à jour par table et par jour

    Les tables de destination d'une tâche de requête sont soumises à une limite de 1 500 mises à jour par table et par jour. 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 jobs.insert de type requête.

  • Délai d'exécution de la requête/du script : 6 heures

    Cette limite ne peut pas être modifiée. Dans certains cas, il est possible de relancer une requête. Celle-ci pourra alors être exécutée pendant six heures supplémentaires et relancée jusqu'à trois fois. La durée d'exécution totale peut ainsi dépasser six heures.

  • Nombre maximal de tables référencées par requête : 1 000

  • Longueur maximale d'une requête non résolue en ancien SQL : 256 ko

  • Longueur maximale d'une requête non résolue en SQL standard : 1 Mo

  • Longueur maximale d'une requête résolue en ancien SQL et en SQL standard : 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 d'une requête en SQL standard : 10 000

  • 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

  • Nombre maximal d'emplacements simultanés par projet pour la tarification à la demande : 2 000

    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.

    Pour plus d'informations sur les limites qui s'appliquent aux fonctions définies par l'utilisateur dans les requêtes SQL, consultez la section Limites relatives aux fonctions définies par l'utilisateur.

  • Utilisation maximale du processeur par données analysées pour la tarification à la demande : 256 secondes de temps de processeur par Mio analysé

    Avec la tarification à la demande, vous pouvez utiliser jusqu'à 256 secondes de temps de processeur par Mio de données analysées. Si votre requête est trop gourmande en ressources processeur pour la quantité de données traitées, elle échoue avec une erreur billingTierLimitExceeded.

    Pour en savoir plus, consultez la section billingTierLimitExceeded.

  • Requêtes programmées

    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 au quota de tâches de chargement. Les requêtes programmées sont soumises aux mêmes quotas et limites BigQuery que les requêtes manuelles.

Tâches de chargement

Les limites ci-dessous s'appliquent aux tâches que vous créez automatiquement en chargeant des données à l'aide de Cloud Console ou de l'outil de ligne de commande bq. Elles s'appliquent également aux tâches de chargement exécutées de manière automatisée à l'aide de la méthode d'API jobs.insert de type chargement.

Les limites suivantes s'appliquent lorsque vous chargez des données dans BigQuery.

  • Tâches de chargement par table et par jour : 1 500 (échecs compris)
  • Tâches de chargement par projet et par jour : 100 000 (échecs compris)
  • Limites de taille des lignes et des cellules :
    Format des données Limite maximale
    CSV 100 Mo (taille de ligne et de cellule)
    JSON 100 Mo (taille de ligne)
  • Nombre maximal de colonnes par table : 10 000
  • Taille maximale des fichiers :
    Type de fichier Compressé Non compressé
    CSV 4 Go 5 To
    JSON 4 Go 5 To
  • Taille maximale par tâche de chargement : 15 To sur tous les fichiers d'entrée pour CSV, JSON, Avro, Parquet et ORC
  • Taille maximale des blocs de données des fichiers Avro : 16 Mo
  • Nombre maximal d'URI sources dans la configuration de la tâche : 10 000 URI
  • Nombre maximal de fichiers par tâche de chargement : 10 millions de fichiers au total, y compris tous les fichiers correspondant à tous les URI génériques
  • Limite de temps d'exécution d'une tâche de chargement : 6 heures

À l'exception des ensembles de données basés aux États-Unis, vous devez importer les données depuis un bucket Cloud Storage situé dans la même région que l'ensemble de données (le bucket peut être un bucket multirégional ou régional de la même région que l'ensemble de données). Vous pouvez importer des données dans un ensemble de données basé aux États-Unis depuis n'importe quelle région.

Si vous dépassez régulièrement le quota de tâches de chargement en raison de mises à jour fréquentes, envisagez plutôt d'importer des données dans BigQuery.

Pour plus d'informations, consultez la page Présentation du chargement des données.

Tâches de copie

Les limites suivantes s'appliquent à la copie de tables dans BigQuery. Ces limites concernent les tâches que vous créez automatiquement en copiant des données à l'aide de l'outil de ligne de commande bq ou de Cloud Console. Elles s'appliquent également aux tâches de copie exécutées de manière automatisée à l'aide de la méthode API jobs.insert de type copie.

  • Tâches de copie par table de destination et par jour : 1 000 (échecs compris)

  • Tâches de copie par projet et par jour : 100 000 (échecs compris)

  • Tâches de copie interrégionale par table de destination et par jour : 100 (échecs compris)

  • Tâches de copie interrégionale par projet et par jour : 2 000 (échecs compris)

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

  • Nombre maximal de tables dans l'ensemble de données source : 20 000

  • Nombre maximal de tables pouvant être copiées par exécution dans un ensemble de données de destination de la même région : 20 000 tables par exécution

  • Nombre maximal de tables pouvant être copiées par exécution dans un ensemble de données de destination dans une région différente : 1 000 tables par exécution

    Par exemple, si vous configurez une copie interrégionale d'un ensemble de données comprenant 8 000 tables, le service de transfert de données BigQuery crée automatiquement huit exécutions de manière séquentielle. La première exécution copie 1 000 tables, puis 24 heures plus tard, une deuxième exécution va en copier 1 000 et ainsi de suite, jusqu'à ce que toutes les tables de l'ensemble de données soient copiées, dans la limite de 20 000 tables par ensemble de données.

Tâches d'exportation

Les limites suivantes s'appliquent aux tâches d'exportation de données depuis BigQuery. Elles concernent les tâches que vous créez automatiquement en exportant des données à l'aide de l'outil de ligne de commande bq ou de Cloud Console. Elles s'appliquent également aux tâches d'exportation exécutées de manière automatisée à l'aide de la méthode d'API jobs.insert de type exportation.
  • Exportations par jour : 100 000 exportations par projet et jusqu'à 50 To par jour (la limite de données de 50 To est cumulative pour toutes les exportations)
  • Pour exporter plus de 50 To de données par jour, utilisez l'API Storage Read ou l'instruction EXPORT DATA.

  • URI génériques : 500 URI génériques par exportation

Limites des ensembles de données

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

  • Nombre d'ensembles de données par projet : sans restriction

  • Nombre de tables par ensemble de données : sans restriction

    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. Cloud Console peut afficher jusqu'à 50 000 tables pour chaque ensemble de données.

  • Nombre maximal de vues autorisées dans la liste de contrôle d'accès d'un ensemble de données : 2 500

    Vous pouvez créer une vue autorisée pour restreindre l'accès à vos données sources. Une vue autorisée est créée à l'aide d'une requête SQL qui exclut les colonnes que vous ne souhaitez pas afficher aux utilisateurs lorsqu'ils font une requête sur cette vue. Vous pouvez ajouter jusqu'à 2 500 vues autorisées à la liste de contrôle d'accès d'un ensemble de données.

  • Taux maximal des opérations de mise à jour des métadonnées des ensembles de données : 5 opérations toutes les 10 secondes par ensemble de données

    La limite de mise à jour des métadonnées de l'ensemble de données inclut toutes les opérations de mise à jour des métadonnées effectuées à l'aide de Cloud Console, de l'outil de ligne de commande bq ou des bibliothèques clientes, ou bien en appelant les méthodes d'API datasets.insert, datasets.patch ou datasets.update, ou encore en exécutant les instructions LDD CREATE SCHEMA ou ALTER SCHEMA.

  • 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.

Limites des tables

Les limites suivantes s'appliquent aux tables BigQuery.

Toutes les tables

  • Longueur maximale de la description des colonnes : 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

    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 valeurs soient scalaires ou basées sur des tableaux (répétitions).

Tables standards

  • Nombre maximal d'opérations par table et par jour : 1 500

    Vous êtes limité à 1 500 opérations par table et par jour, qu'il s'agisse d'ajouter des données à une table ou de la tronquer.

    Le nombre maximal d'opérations de table inclut le total cumulé de toutes les tâches de chargement, tâches de copie et tâches de requête qui s'ajoutent à une table de destination ou l'écrasent, ou qui utilisent une instruction LMD INSERT, UPDATE, DELETE ou MERGE pour écrire des données dans une table. Les instructions LMD sont comptabilisées dans ce quota, mais n'y sont pas limitées. Autrement dit, les instructions LMD sont incluses dans le nombre d'opérations quotidiennes qui sont comptabilisées dans le quota. Cependant, ces instructions ne peuvent pas échouer à cause de cette limite.

    Par exemple, si vous exécutez 500 tâches de copie qui ajoutent des données à mytable et 1 000 tâches de requête qui ajoutent des données à mytable, vous atteignez le quota.

  • Taux maximal d'opérations de mise à jour des métadonnées de table : 5 opérations toutes les 10 secondes par table

    La limite de mise à jour des métadonnées de table inclut toutes les opérations de mise à jour de métadonnées que vous effectuez en utilisant Cloud Console, l'outil de ligne de commande bq ou les bibliothèques clientes, ou bien en appelant les méthodes d'API tables.insert, tables.patch ou tables.update, ou encore en exécutant les instructions LDD ALTER TABLE. Cette limite inclut également le total cumulé de toutes les tâches de chargement, tâches de copie et tâches de requête qui s'ajoutent à une table de destination ou l'écrasent. Il s'agit d'une erreur temporaire. Vous pouvez réessayer avec un intervalle exponentiel entre les tentatives. Cette limite ne s'applique pas aux opérations LMD.

  • Nombre maximal de colonnes dans une table, un résultat de requête ou une définition de vue : 10 000

Tables partitionnées

  • Nombre maximal de partitions par table partitionnée : 4 000

  • Nombre maximal de partitions modifiées par tâche : 4 000

    Chaque opération de tâche (requête ou chargement) peut affecter 4 000 partitions au maximum. Toute tâche de requête ou de chargement qui affecte plus de 4 000 partitions est refusée par BigQuery.

  • Nombre maximal de modifications de partition par table partitionnée par date d'ingestion : 5 000

  • Nombre maximal de modifications de partition par table partitionnée en colonnes : 30 000

    Vous pouvez effectuer jusqu'à 5 000 modifications de partition par jour pour une table partitionnée par date d'ingestion. Pour une table partitionnée en colonnes, la limite est fixée à 30 000. Pour découvrir des stratégies qui vous aideront à respecter ces limites, consultez la page Dépannage des erreurs de quota.

    Une partition peut être modifiée à l'aide d'une opération qui ajoute ou remplace des données dans la partition. Les opérations qui modifient les partitions incluent : les tâches de chargement, les requêtes qui écrivent les résultats dans une partition ou les instructions LMD (INSERT, DELETE, UPDATE ou MERGE) qui modifient les données d'une partition.

    Une tâche unique peut affecter plusieurs partitions. Par exemple, une instruction LMD peut mettre à jour des données dans plusieurs partitions (à la fois dans les tables partitionnées et les tables partitionnées par date d'ingestion). Les tâches de requête et les tâches de chargement peuvent également écrire sur plusieurs partitions, mais uniquement pour les tables partitionnées. Les instructions LMD sont comptabilisées dans ce quota, mais n'y sont pas limitées. Autrement dit, les instructions LMD sont incluses dans le nombre d'opérations quotidiennes qui sont comptabilisées dans le quota. Cependant, ces instructions ne peuvent pas échouer à cause de cette limite.

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

  • Fréquence maximale des opérations de partition : 50 opérations de partition toutes les 10 secondes, par table

  • Nombre maximal de plages possibles pour le partitionnement de plage : 10 000

    Cette limite s'applique à la spécification de partition lors de la création de la table. Une fois la table créée, la limite du nombre de partitions réelles s'applique également.

Instantanés de table

  • Nombre maximal de tâches simultanées pour les instantanés de table : 100

    Vous pouvez exécuter jusqu'à 500 tâches d'instantané de table simultanées par projet et par région.

  • Nombre maximal de tâches d'instantané de table par jour : 50 000

    Vous pouvez exécuter jusqu'à 50 000 tâches d'instantané de table par jour, par projet et par région.

  • Nombre maximal de tâches par instantané de table et par jour : 50

    Vous pouvez exécuter jusqu'à 50 tâches par jour pour un instantané de table. Pour augmenter la limite, adressez-vous à l'assistance ou contactez le service commercial.

  • Nombre maximal de mises à jour de métadonnées par instantané de table et par intervalle de 10 secondes : 5

    Vous pouvez mettre à jour les métadonnées d'un instantané de table jusqu'à cinq fois toutes les 10 secondes.

Tables externes

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

  • Nombre maximal d'URI sources par table externe : 10 000 URI

  • Nombre maximal de fichiers par table externe : 10 millions de fichiers au total, 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 pour tous les fichiers d'entrée : 600 To

    Cette limite s'applique aux fichiers tels qu'ils sont stockés sur Cloud Storage. Cette taille est différente de celle utilisée dans la formule de calcul du tarif des requêtes. Pour les tables partitionnées externes, la limite est appliquée après l'élimination des partitions.

Limites des fonctions de table

Les limites suivantes s'appliquent aux fonctions de table.

  • Longueur maximale d'un nom de fonction de table : 256 caractères
  • Nombre maximal d'arguments : 256
  • Longueur maximale d'un nom d'argument : 128 caractères
  • Profondeur maximale d'une chaîne de référence de fonction de table : 16
  • Profondeur maximale d'un argument ou d'une sortie de type STRUCT : 15
  • Nombre maximal de champs dans un argument ou une table de retour de type STRUCT par fonction de table : 1 024
  • Nombre maximal de colonnes dans le tableau des retours : 1 024
  • Longueur maximale des noms des colonnes des tables de retour : 128
  • Fréquence maximale de mise à jour par fonction de table : 5 par intervalle de 10 secondes. Après avoir créé une fonction de table, vous pouvez la mettre à jour jusqu'à cinq fois par intervalle de 10 secondes.

Instructions du langage de manipulation de données (LMD)

Les instructions LMD BigQuery ne sont pas limitées par un quota.

Cependant, les instructions LMD sont comptabilisées dans le nombre maximal d'opérations de table par jour et de modifications de partition par jour. Les instructions LMD ne peuvent pas échouer à cause de ces limites.

Sécurité au niveau des lignes

Description Quota
Nombre maximal de règles d'accès aux lignes par table. 100
Nombre total de règles d'accès aux lignes auxquelles une requête peut faire référence sur des tables dotées de règles d'accès aux lignes 100
CREATE / DROP Instructions LDD 5 pour 10 secondes, par ressource de règle d'accès aux lignes sur la table
Instructions DROP ALL ROW ACCESS POLICIES 5 pour 10 secondes, par ressource de table
Répertorier les règles d'accès aux lignes (à l'aide de l'API REST "rowAccessPolicies.list") Quota d'API par défaut
Obtenir les stratégies IAM de la règle d'accès aux lignes (à l'aide de l'API "rowAccessPolicies.getIamPolicy") Quota par défaut de l'API IAM

Insertions en flux continu

Les limites suivantes s'appliquent à l'insertion de données en flux continu dans BigQuery.

Si vous ne remplissez pas le champ insertId lorsque vous insérez des lignes, les quotas suivants s'appliquent. Pour en savoir plus, consultez la section Désactiver la déduplication optimale. Il s'agit de la méthode recommandée pour utiliser BigQuery afin d'augmenter les quotas d'ingestion par flux. Pour découvrir des stratégies qui vous aideront à respecter ces limites, consultez la page Dépannage des erreurs de quota.

  • Nombre maximal d'octets par seconde : 1 Go

    Si vous ne remplissez pas le champ insertId pour chaque ligne insérée, vous êtes limité à 1 Go par seconde et par projet. Cette limite s'applique au niveau du projet, et non aux tables individuelles.

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

Si vous remplissez le champ insertId lorsque vous insérez des lignes, les quotas suivants s'appliquent.

  • Nombre maximal de lignes par seconde et par projet dans les emplacements multirégionaux us et eu : 500 000

    Si vous remplissez le champ insertId pour chaque ligne insérée, vous êtes limité à 500 000 lignes par seconde dans les emplacements multirégionaux us et eu par projet. Ce quota est cumulatif au sein d'un emplacement multirégional donné. En d'autres termes, la somme des lignes par seconde transmises à l'ensemble des tables pour un projet donné au sein d'un emplacement multirégional est limitée à 500 000. En outre, chaque table est limitée à 100 000 lignes par seconde.

    Si vous dépassez les limites par projet ou par table, des erreurs quotaExceeded sont générées.

  • Nombre maximal de lignes par seconde et par projet dans tous les autres emplacements : 100 000

    Si vous remplissez le champ insertId pour chaque ligne insérée, vous êtes limité à 100 000 lignes par seconde dans tous les emplacements, sauf les emplacements multirégionaux us et eu, par projet ou par table. Ce quota est cumulatif au sein d'un emplacement régional donné. En d'autres termes, la somme des lignes par seconde transmises à l'ensemble des tables pour un projet donné au sein d'un emplacement régional est limitée à 100 000.

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

  • Nombre maximal de lignes par seconde et par table : 100 000

    Si vous remplissez le champ insertId pour chaque ligne insérée, vous êtes limité à 100 000 lignes par seconde et par table.

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

  • Nombre maximal d'octets par seconde : 100 Mo

    Si vous remplissez le champ insertId pour chaque ligne insérée, vous êtes limité à 100 Mo par seconde et par table.

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

Les quotas supplémentaires d'insertions en flux continu qui sont présentés ci-dessous s'appliquent que vous remplissiez le champ insertId ou non.

  • Taille maximale des lignes : 10 Mo

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

  • Taille maximale des requêtes HTTP : 10 Mo (voir la remarque)

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

  • Nombre maximal de lignes par requête : 50 000 lignes par requête

    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.

    Nous vous recommandons d'utiliser 500 lignes au maximum par requête. Toutefois, il est conseillé d'effectuer des tests sur des données représentatives (tailles de schémas et de données) pour déterminer la taille de lot idéale.

  • Longueur du champ insertId : 128

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

Si vous avez besoin d'un quota supérieur d'insertions en flux continu pour votre projet, vous pouvez désactiver la déduplication optimale. Pour augmenter le quota au-delà de ces limites, vous pouvez envoyer une demande depuis Google Cloud Console. Attendez-vous à recevoir une réponse dans un délai de deux à trois jours ouvrés.

Limites relatives aux fonctions définies par l'utilisateur

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

  • Quantité de données générées par votre fonction JavaScript définie par l'utilisateur lors du traitement d'une seule ligne : environ 5 Mo ou moins
  • Limite de débit simultané pour les requêtes en ancien SQL contenant des fonctions définies par l'utilisateur : 6 requêtes simultanées
  • La limite de débit simultané pour les requêtes en ancien SQL contenant des fonctions définies par l'utilisateur 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 débit simultané pour les requêtes interactives. Cette limite ne s'applique pas aux requêtes en SQL standard.

  • Nombre maximal de ressources de fonctions JavaScript définies par l'utilisateur (blobs de code intégrés ou fichiers externes, par exemple) dans une tâche de requête : 50
  • Taille maximale de chaque blob de code intégré : 32 ko
  • Taille maximale de chaque ressource de code externe : 1 Mo
Les limites suivantes s'appliquent aux fonctions persistantes définies par l'utilisateur.
  • Longueur maximale d'un nom de fonction : 256 caractères
  • Nombre maximal d'arguments : 256
  • Longueur maximale d'un nom d'argument : 128 caractères
  • Profondeur maximale d'une chaîne de référence de fonction définie par l'utilisateur : 16
  • Profondeur maximale d'argument ou d'une sortie de type STRUCT : 15
  • Nombre maximal de champs dans un argument ou une sortie de type STRUCT par fonction définie par l'utilisateur : 1 024
  • Nombre maximal de fonctions définies par l'utilisateur uniques, plus références de table par requête : 1 000

    Après extension complète, chaque fonction définie par l'utilisateur peut référencer jusqu'à 1 000 tables et fonctions définies par l'utilisateur uniques combinées.

  • Nombre maximal de bibliothèques JavaScript dans l'instruction CREATE FUNCTION : 50
  • Longueur maximale des chemins d'accès aux bibliothèques JavaScript incluses : 5 000 caractères
  • Fréquence maximale de mise à jour par fonction définie par l'utilisateur : 5 par intervalle de 10 secondes

    Après avoir créé une fonction, vous pouvez la mettre à jour jusqu'à cinq fois par intervalle de 10 secondes.

  • Taille maximale de chaque blob de code intégré : 32 ko
  • Taille maximale de chaque ressource de code JavaScript : 1 Mo

Limites de vues

  • Nombre maximal de niveaux de vues imbriquées : 16

    BigQuery accepte jusqu'à 16 niveaux de vues imbriquées. Si le nombre de niveaux est plus élevé, une erreur INVALID_INPUT est renvoyée.

  • Longueur maximale d'une requête en SQL standard utilisée pour définir une vue : 256 000 caractères

    Lorsque vous créez une vue, le texte de la requête SQL standard ne doit pas dépasser 256 000 caractères.

  • Nombre maximal de vues autorisées dans la liste de contrôle d'accès d'un ensemble de données : 2 500

    Vous pouvez créer une vue autorisée pour restreindre l'accès à vos données sources. Une vue autorisée est créée à l'aide d'une requête SQL qui exclut les colonnes que vous ne souhaitez pas que les utilisateurs voient lorsqu'ils font une requête sur cette vue. Vous pouvez ajouter jusqu'à 2 500 vues autorisées à la liste de contrôle d'accès d'un ensemble de données.

Requêtes API

Toutes les requêtes API

Les limites suivantes s'appliquent à toutes les requêtes API BigQuery :

  • Requêtes API par seconde et par utilisateur : 100

    Si vous effectuez plus de 100 requêtes par seconde, vous remarquerez peut-être un ralentissement du débit. Cette limite ne s'applique pas aux insertions en flux continu.

  • Requêtes API simultanées par utilisateur : 300

    Si vous effectuez plus de 300 requêtes simultanées par utilisateur, vous remarquerez peut-être un ralentissement du débit. Cette limite ne s'applique pas aux insertions en flux continu.

Requêtes tabledata.list

La méthode tabledata.list récupère les données de table d'un ensemble déterminé de lignes. D'autres API incluant la méthode jobs.getQueryResults et récupérant des résultats des méthodes jobs.query et jobs.insert peuvent également consommer le quota de cette API. Les limites ci-dessous s'appliquent aux requêtes tabledata.list :

  • Nombre maximal de requêtes tabledata.list par projet : 1 000/seconde

    Lorsque vous appelez tabledata.list, vous pouvez envoyer jusqu'à 1 000 requêtes par seconde et par projet.

  • Nombre maximal d'octets par seconde et par projet qui sont renvoyés par les appels à tabledata.list : 60 Mo/seconde

    Lorsque vous appelez tabledata.list, vous pouvez renvoyer au maximum 60 Mo par seconde de données de ligne de table par projet. La limite s'applique au projet contenant la table en cours de lecture.

  • Nombre maximal de lignes par seconde et par projet qui sont renvoyées par les appels à tabledata.list : 150 000/seconde

    Lorsque vous appelez tabledata.list, vous pouvez renvoyer au maximum 150 000 lignes de table par seconde et par projet. La limite s'applique au projet contenant la table en cours de lecture.

  • Nombre maximal de lignes renvoyées par un appel à tabledata.list : 100 000 lignes

    Lorsque vous appelez tabledata.list, la réponse peut contenir jusqu'à 100 000 lignes de table. Pour en savoir plus, consultez la section Paginer des résultats à l'aide de l'API.

Requêtes tables.insert

La méthode tables.insert permet de créer une table vide dans un ensemble de données. Les limites ci-dessous s'appliquent aux requêtes tables.insert :

  • Nombre maximal de requêtes par seconde par projet : 10 requêtes

    Lorsque vous appelez tables.insert, vous pouvez créer jusqu'à 10 requêtes par seconde et par projet. Cette limite inclut les instructions créant des tables telles que l'instruction LDD CREATE TABLE et les requêtes qui écrivent les résultats dans des tables de destination.

Requêtes projects.list

La méthode projects.list répertorie tous les projets auxquels vous avez accès. Les limites ci-dessous s'appliquent aux requêtes projects.list :

  • Nombre maximal de requêtes par seconde et par projet : 2

    Lorsque vous appelez projects.list, vous pouvez créer jusqu'à deux requêtes par seconde et par projet.

Requêtes jobs.get

La méthode jobs.get renvoie des informations sur une tâche spécifique. Les limites ci-dessous s'appliquent aux requêtes jobs.get :

  • Nombre maximal de requêtes par seconde et par projet : 1 000

    Lorsque vous appelez jobs.get, vous pouvez créer jusqu'à 1 000 requêtes par seconde et par projet.

Requêtes jobs.query

La méthode jobs.query exécute une requête SQL de manière synchrone et renvoie des résultats si la requête aboutit dans un délai spécifié.

  • Taille maximale des réponses : 10 Mo

    Par défaut, il n'existe aucun nombre maximal pour les lignes de données à renvoyer par page de résultats. Cependant, vous êtes tenu de respecter la limite maximale de 10 Mo pour la taille des réponses. Pour modifier le nombre de lignes à renvoyer, utilisez le paramètre maxResults.

Requêtes de l'API IAM

Les limites suivantes s'appliquent lorsque vous utilisez la fonctionnalité de 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.

  • Nombre maximal de requêtes par utilisateur : 25

    Vous êtes limité à 25 requêtes IAM par seconde, par utilisateur et par projet.

  • Nombre maximal de requêtes par projet : 50

    Vous êtes limité à 50 requêtes IAM par seconde et par projet.

Si besoin, vous pouvez demander une augmentation de vos quotas IAM pour votre projet en envoyant une demande dans Google Cloud Console. Attendez-vous à recevoir une réponse dans un délai de deux à trois jours ouvrés.

Requêtes de l'API BigQuery Storage Read

L'API Storage Read est soumise aux quotas et limites ci-dessous.

  • Longueur maximale des lignes/filtres : 1 Mo

    Lorsque vous utilisez l'appel CreateReadSession de l'API Storage Read, la longueur maximale des lignes/filtres est limitée à 1 Mo.

  • Requêtes de lecture pour le plan de données : 5 000 appels par minute, par utilisateur et par projet

    Vous êtes limité à 5 000 appels ReadRows par minute, par utilisateur et par projet.

  • Requêtes de lecture pour le plan de contrôle : 5 000 appels par minute, par utilisateur et par projet

    Vous êtes limité à un total de 5 000 appels d'opérations de métadonnées de l'API Storage Read (CreateReadSession et SplitReadStream) par minute, par utilisateur et par projet.

Requêtes de l'API BigQuery Storage Write

L'API Storage Write est soumise aux quotas et limites ci-dessous.

  • Limitation du débit pour la création de flux d'écriture : 100 par minute et par projet

    Les appels à CreateWriteStream ont un débit limité. Si vous atteignez cette limite, relancez l'opération avec un intervalle exponentiel entre les tentatives. Essayez également d'espacer les appels à CreateWriteStream. Le flux par défaut n'est pas soumis à ce quota. Si vous n'avez pas besoin de dupliquer les données avec le mode commit, envisagez d'utiliser le flux par défaut.

  • Octets en attente : 100 Go par projet

    Cette limite correspond au nombre maximal d'octets que vous pouvez écrire en mode "en attente" avant de valider les flux.

  • Connexions simultanées : 1 000 par projet

  • Nombre maximal de flux transmis à BatchCommitWriteStreams : 100

    En mode "en attente", la méthode BatchCommitWriteStreams prend une liste de flux à valider. Si vous dépassez cette limite, la méthode renvoie une erreur. Pour contourner le problème, appelez plusieurs fois BatchCommitWriteStreams.

Délais de réapprovisionnement

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.

Dépannage

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

Limiter l'utilisation des quotas

Pour savoir comment limiter l'utilisation d'une ressource donnée (jusqu'à la limite spécifiée par Google), consultez la section Limiter l'utilisation des ressources.