Quotas et limites

BigQuery limite le taux maximal de requêtes entrantes et applique des quotas appropriés par projet. Les directives spécifiques s'appliquent 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 d'exécution tests ne sont pas prises en compte dans cette limite. Vous pouvez spécifier une requête test dans l'indicateur --dry_run ou en ajoutant la propriété dryRun dans une tâche de requête.

  • 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 - 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 de tables de destination incluent des opérations d'ajout et d'écrasement effectuées par une requête à l'aide de l'interface utilisateur Web de BigQuery, de l'outil de ligne de commande bq ou en appelant les méthodes 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 non résolue - 256 Ko

  • Longueur maximale de la requête résolue - 12 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

1Les 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 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 Surveillance de BigQuery à l'aide de Stackdriver. Si vous avez besoin de plus de 2 000 emplacements, contactez votre représentant 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 ou de l'interface Web BigQuery. Les limites s'appliquent également au chargement des travaux soumis par programmation à l'aide de la méthode 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 travaux 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 (ligne et taille de cellule)
    JSON 100 Mo (taille de ligne)
    Avro 16 Mo (taille de bloc)
  • Nombre maximum de colonnes par table - 10 000
  • Taille maximale des fichiers :
    Type de fichier Compressée : Sans compression
    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 et Avro
  • Nombre maximal d'URI sources dans la configuration de la tâche - 10 000 URI
  • Nombre maximum 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 zone que l'ensemble de données (le bucket peut être un bucket multirégional ou un bucket 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, voir Introduction au chargement des données dans BigQuery.

Copier des tâches

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 ou de l'interface Web BigQuery. Les limites s'appliquent également aux travaux de copie soumis par programmation à 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 (y compris les échecs)
  • Tâches de copie par projet et par jour - 10 000 (y compris les échecs)

Exporter des tâches

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 ou de l'interface utilisateur Web de BigQuery. Les limites s'appliquent également aux tâches d'exportation soumises par programmation à l'aide de la méthode 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 ; cependant, lorsqu'un projet contient plusieurs milliers d'ensembles de données, les performances de l'interface utilisateur Web ont tendance à baisser et cela prend plus de temps de répertorier les ensembles de données.
  • Nombre de tables par ensemble de données - sans restriction
    Le nombre de tables par ensemble de données est également illimité, mais lorsque vous avez près de 50 000 tables ou plus dans un ensemble de données, leur énumération est plus lente. Les performances d'énumération sont limitées si vous utilisez un appel API, l'interface utilisateur Web ou la méta __TABLES_SUMMARY__ Pour améliorer les performances de l'interface utilisateur, vous pouvez utiliser le paramètre ?minimal pour limiter le nombre de tables affichées à 30 000 par projet. Ajoutez le paramètre à l'URL de l'interface Web BigQuery au 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 - 1 000
    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'à 1 000 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 - 1 opération toutes les 2 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 l'interface Web BigQuery, de l'outil de ligne de commande bq ou avec les méthodes API datasets.insert, datasets.patch ou datasets.update.

Limites des tables

Les limites suivantes s'appliquent aux tables BigQuery.

Tables standards

  • Nombre maximum 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 à ou écrasent une table de destination ou 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 - 1 opération toutes les 2 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 effectuées à l'aide de l'interface utilisateur Web de BigQuery, de l'outil de ligne de commande bq ou avec les appels de méthodes 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.

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 maximum 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. Google 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 streaming n'affectent pas ce quota.

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

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 (UDF) - six 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 combinées UPDATE, DELETE et MERGE par jour et par table - 200
  • Nombre maximal d'instructions UPDATE, DELETE et MERGE combinées par jour et par projet - 10 000
  • Nombre maximum d'instructions INSERT 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.

Les instructions LMD sont plus limitées que les instructions SELECT (SQL), car leur traitement fait appel à beaucoup plus de ressources.

Limites du machine learning BigQuery

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 - 100 requêtes
    Vous êtes limité à 100 requêtes CREATE MODEL par jour et par projet.

Insertions en flux continu

Les limites suivantes s'appliquent à la diffusion de données dans BigQuery.

  • Taille maximale de la ligne : 1 Mo. Le dépassement de cette valeur entraînera des erreurs invalid.
  • Limite de taille des requêtes HTTP : 10 Mo. Le dépassement de cette valeur causera des erreurs invalid.
  • Nombre maximum 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 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 maximum 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 ligne 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 streaming dans votre projet, vous pouvez soumettre une demande à partir de la page Console Google Cloud Platform. Vous pouvez définir un quota personnalisé sur les données en streaming 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 streaming.
  • 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 streaming.

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 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 nouvelle 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 par projet : 10
    Lorsque vous appelez tables.insert, vous pouvez créer un maximum de 10 requêtes par seconde par projet. Cette limite inclut des instructions qui créent des tables telles que l'instruction LDD 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 par projet : 2
    Lorsque vous appelez projects.list, vous pouvez créer un maximum de 2 requêtes par seconde 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 par projet : 1 000
    Lorsque vous appelez jobs.get, vous pouvez créer un maximum de 1 000 requêtes par seconde 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…