Quotas et limites

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.

Les listes ci-dessous décrivent les limites actuelles de débit et de quota du système.

Tâches de requêtes

Les limites suivantes s'appliquent aux tâches de requête créées automatiquement en exécutant des requêtes interactives et aux tâches exécutées par programmation à l'aide d'appels de méthode jobs.query et jobs.insert de type requête.

Les requêtes contenant des résultats renvoyés par le cache de requêtes et 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'indicateur--dry_run ou en ajoutant la propriété dryRun dans une tâche de requête.

Cette limite est appliquée au niveau du projet. Pour l'augmenter, contactez l'assistance ou le service commercial.

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

Vous êtes limité à 4 requêtes simultanées sur une source de données externes Cloud Bigtable.

  • Limite de débit simultané pour les requêtes en ancien SQL contenant des fonctions définies par l'utilisateur (UDF, user-defined functions) - 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 aussi bien des requêtes interactives que des requêtes par lots. 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.

  • 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 de la table de destination - 1 000 mises à jour par table et par jour

Les tables de destination dans une tâche de requête sont soumises à une limite de 1 000 mises à jour par table et par jour. Les mises à jour des tables de destination incluent les opérations d'ajout et d'écrasement réalisées par une requête à l'aide de la console, de l'UI Web classique de BigQuery, de l'outil de ligne de commande bq, ou 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 - 6 heures

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

  • Longueur maximale de la requête en ancien SQL non résolue - 256 Ko

  • Longueur maximale de la requête en ancien SQL résolue - 12 Mo

  • Longueur maximale de la requête SQL standard non résolue - 1 Mo

La limite de longueur de 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.

  • Taille maximale de réponse - 128 Mo compressés1

1 Les tailles varient en fonction des taux de compression de données. La taille de réponse réelle peut être nettement supérieure à 128 Mo.

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 Mo2

2 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 la vue - 10 000

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

Le nombre d'emplacements par défaut pour les requêtes à la demande est partagé entre toutes les requêtes d'un même projet. En règle générale, si vous traitez moins de 100 Go de requêtes à la fois, il est peu probable que vous utilisiez les 2 000 emplacements.

Pour vérifier le nombre d'emplacements que vous utilisez, consultez la section Surveiller BigQuery avec Stackdriver. Si vous avez besoin de plus de 2 000 emplacements, contactez votre conseiller commercial pour savoir si la tarification forfaitaire correspond à vos besoins.

  • Nombre maximal de requêtes simultanées sur une source de données externes Cloud Bigtable - 4

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

Tâches de chargement

Les limites suivantes s'appliquent aux tâches créées automatiquement en chargeant des données à l'aide de l'outil de ligne de commande, de la console ou de l'UI Web classique de BigQuery. Ces limites s'appliquent également aux tâches de chargement exécutées par programmation à 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 000 (échecs compris)
  • Tâches de chargement par projet et par jour - 50 000 (échecs compris)
  • La limite de 1 000 tâches de chargement par table et par jour ne peut pas être augmentée.
  • 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
    Avro Les fichiers Avro compressés ne sont pas compatibles, mais les blocs de données compressés le sont. BigQuery est compatible avec les codecs DEFLATE et Snappy. 5 To (1 Mo pour l'en-tête du fichier)
  • Taille maximale par tâche de chargement – 15 To sur tous les fichiers d'entrée pour CSV, JSON, Avro, Parquet et ORC
  • 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 d'un bucket Cloud Storage 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.

Pour plus d'informations, consultez l'article Introduction au chargement des données dans BigQuery.

Tâches de copie

Les limites suivantes s'appliquent à la copie de tables dans BigQuery. Les limites s'appliquent aux tâches créées automatiquement en copiant des données à l'aide de l'outil de ligne de commande, de la console ou de l'UI Web classique de BigQuery. Ces limites s'appliquent également aux tâches de copie exécutées par programmation à l'aide de la méthode d'API jobs.insert de type copie.

  • Tâches de copie par table de destination et par jour – 1 000 (y compris les échecs)
  • Tâches de copie par projet et par jour - 10 000 (y compris les échecs)

Tâches d'exportation

Les limites suivantes s'appliquent aux tâches d'exportation de données depuis BigQuery. Les limites suivantes s'appliquent aux tâches créées automatiquement en exportant des données à l'aide de l'outil de ligne de commande, de la console ou de l'UI Web classique de BigQuery. Ces limites s'appliquent également aux tâches d'exportation exécutées par programmation à l'aide de la méthode d'API jobs.insert de type chargement.

  • Exportations par jour – 50 000 exportations par projet et jusqu'à 10 To par jour (la limite de données de 10 To est cumulative pour toutes les exportations)
  • 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
    Le nombre d'ensembles de données par projet n'est pas soumis à un quota. Toutefois, lorsque votre projet contient plusieurs milliers d'ensembles de données, les performances de l'interface utilisateur classique ont tendance à se dégrader. Il faut alors plus de temps pour répertorier les ensembles de données.
  • Nombre de tables par ensemble de données – sans restriction
    Lorsque vous atteignez 50 000 tables ou plus dans un ensemble de données, leur énumération est ralentie. Les performances d'énumération sont limitées, que vous utilisiez un appel d'API ou l'UI Web classique de BigQuery. Actuellement, l'UI Web de BigQuery dans la console GCP vous permet d'afficher uniquement 50 000 tables par ensemble de données. Pour améliorer les performances de l'UI Web classique de BigQuery, vous pouvez utiliser le paramètre ?minimal pour limiter le nombre de tables affichées à 30 000 tables par projet. Pour ajouter le paramètre à l'URL de l'UI Web classique de BigQuery, utilisez le format suivant : https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal.
  • 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 d'opérations de mise à jour de métadonnées d'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 d'ensembles de données inclut toutes les opérations de mise à jour de métadonnées réalisées à l'aide de la console, de l'UI Web classique de BigQuery, de l'outil de ligne de commande bq, ou en appelant les méthodes d'API datasets.insert, datasets.patch ou datasets.update.
  • Longueur maximale de la description d'un ensemble 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 d'une colonne - 16 384 caractères

Lorsque vous ajoutez une description à une colonne, le texte ne doit pas comporter plus de 16 384 caractères.

Tables standards

  • Nombre maximal d'opérations par table par jour - 1 000

Vous êtes limité à 1 000 opérations par table par jour, que l'opération ajoute des données à une table, écrase une table ou utilise une instruction LMD INSERT pour écrire des données dans une table.

Le nombre maximal d'opérations de table inclut la somme 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 pour écrire des données dans une table.

Par exemple, si vous exécutez 500 tâches de copie qui ajoutent des données à mytable et 500 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 tables inclut toutes les opérations de mise à jour de métadonnées réalisées à l'aide de la console, de l'UI Web classique de BigQuery, de l'outil de ligne de commande bq, ou en appelant les méthodes d'API tables.insert, tables.patch ou tables.update. Cette limite s'applique également aux résultats obtenus lors de l'exécution des tâches.

  • Nombre maximal de colonnes dans une table, un résultat de requête ou une définition de la 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- 2 000

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

  • Nombre maximal de modifications de partition par jour et par table - 5 000

Vous pouvez effectuer jusqu'à 5 000 modifications de partition par table partitionnée. 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 : une tâche de chargement, une requête qui écrit les résultats dans une partition ou une instruction LMD (INSERT, DELETE, UPDATE ou MERGE) qui modifie les données d'une partition.

Une tâche unique peut affecter plus d'une partition. Par exemple, une instruction LMD peut mettre à jour des données dans plusieurs partitions (à la fois dans les tables d’ingestion et les tables partitionnées). 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. BigQuery utilise le nombre de partitions affectées par une tâche pour déterminer le quota utilisé par cette dernière. Les insertions en flux continu n'affectent pas ce quota.

  • Taux maximal d'opérations de partition – 50 opérations de partition toutes les 10 secondes

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

Limites UDF

Les limites suivantes s'appliquent aux fonctions définies par l'utilisateur dans les requêtes SQL.

  • Quantité de données générées par votre fichier UDF JavaScript 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 des requêtes interactives et des requêtes par lots. 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.

  • Une tâche de requête peut contenir jusqu'à 50 ressources UDF JavaScript (blobs de code en ligne ou fichiers externes).
  • Chaque blob de code en ligne est limité à une taille maximale de 32 Ko.
  • Chaque ressource de code externe est limitée à une taille maximale de 1 Mo.

Instructions sur le langage de manipulation de données

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

  • Nombre maximal d'instructions INSERT, UPDATE, DELETE et MERGE combinées par jour et par table – 1 000

Une instruction MERGE est comptabilisée comme une seule instruction LMD, même si elle contient plusieurs clauses INSERT, UPDATE ou DELETE.

Limites de BigQuery ML

Les limites suivantes s'appliquent aux tâches de requête en SQL standard qui utilisent des instructions et des fonctions BigQuery ML.

  • Requêtes utilisant l'instruction CREATE MODEL – 1 000 requêtes
    • Vous êtes limité à 1 000 requêtes CREATE MODEL par jour et par projet.

Insertions en flux continu

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

  • Taille maximale de la ligne : 1 Mo. Le dépassement de cette valeur entraînera des erreurs invalid.
  • Taille maximale des requêtes HTTP : 10 Mo. Le dépassement de cette valeur entraînera des erreurs invalid.
  • Nombre maximal de lignes par seconde : 100 000 lignes par seconde, par projet. Le dépassement du nombre de lignes provoquera des erreurs quotaExceeded. Le nombre maximal de lignes par seconde et par table est également de 100 000.
    Vous pouvez utiliser le quota en entier sur une table ou diviser ce quota entre plusieurs tables d'un projet.
  • Nombre maximal de lignes par requête : 10 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 point, mais au prix d'une latence des requêtes. Un nombre limité de lignes par requête et le poids de chaque requête peuvent 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 environ 500 lignes par requête, mais faire des essais sur un échantillon de données (au niveau du schéma et de la taille) vous aidera à déterminer la taille idéale du lot.
  • Nombre maximal d'octets par seconde : 100 Mo par seconde, par table. Le dépassement de ce nombre provoquera des erreurs quotaExceeded.

Si vous avez besoin d'un quota plus important pour les données en flux continu dans votre projet, vous pouvez soumettre une demande à partir de la console Google Cloud Platform. Vous pouvez définir un quota personnalisé sur les données en flux continu par incréments de 50 000 lignes. Vous recevrez généralement une réponse dans un délai de deux à trois jours ouvrés.

Requêtes API

Toutes les requêtes API

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

  • Requêtes API par seconde, 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. Les limites suivantes s'appliquent aux requêtes tabledata.list :

  • Nombre maximal de requêtes tabledata.list par projet : 500/seconde
    Lorsque vous appelez tabledata.list, vous pouvez soumettre jusqu'à 500 requêtes par seconde et par projet.
  • Nombre maximal d'octets par seconde par projet renvoyé par les appels à tabledata.list : 60 Mo/seconde
    Lorsque vous appelez tabledata.list, vous pouvez renvoyer un maximum de 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 par projet renvoyé par les appels à tabledata.list : 150 000/seconde
    Lorsque vous appelez tabledata.list, vous pouvez renvoyer un maximum de 150 000 lignes de table par seconde par projet. La limite s'applique au projet contenant la table en cours de lecture.

Requêtes tables.insert

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

  • Nombre maximal de requêtes par seconde et par projet : 10. Lorsque vous appelez tables.insert, vous pouvez créer un maximum de 10 requêtes par seconde et par projet. Cette limite inclut des instructions créant des tables, telles que l'instruction DDL CREATE TABLE, et des requêtes écrivant des 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 suivantes 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 un maximum de 2 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 suivantes 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 un maximum de 1 000 requêtes par seconde et par projet.

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.

Codes d'erreur

Les erreurs de quota et de limite renvoient un code de réponse HTTP 403 ou 400. Consultez le document Erreurs de dépannage pour une liste complète des codes d'erreur et des étapes de dépannage.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.