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

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 en utilisant l'option --dry_run ou en définissant la propriété dryRun dans une tâche de requête.

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

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

Il est possible d'exécuter un maximum de quatre requêtes simultanées sur une source de données externe 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 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 une requête via la console, l'UI Web classique de BigQuery ou l'outil de ligne de commande bq, ou bien en appelant les méthodes 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és1

1 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 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 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 Surveiller BigQuery avec Cloud Monitoring.

  • Nombre maximal de requêtes simultanées sur une source de données externes 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 la section Limites relatives aux fonctions définies par l'utilisateur.

  • 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 l'outil de ligne de commande, de Cloud Console ou de l'UI Web classique de BigQuery. 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)
  • La limite de 1 500 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
  • 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 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.

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, de la console ou de l'UI Web classique de BigQuery. 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 d'exportation

Les limites suivantes s'appliquent aux tâches d'exportation de données depuis BigQuery. Les limites ci-dessous s'appliquent aux tâches que vous créez 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. Elles s'appliquent également aux tâches d'exportation exécutées de manière automatisée à l'aide de la méthode API jobs.insert de type chargement.

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

  • 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'UI Web 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
    Lorsqu'un ensemble de données contient 50 000 tables ou plus, 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 Google Cloud Console ne vous permet d'afficher que 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 afin de limiter le nombre de tables affichées à 30 000 tables par projet. Pour ajouter ce 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 pour les utilisateurs lorsqu'ils effectuent 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 des ensembles de données inclut toutes les opérations de mise à jour de métadonnées effectuées à l'aide de la console, de l'UI Web classique de BigQuery ou de l'outil de ligne de commande bq, ou bien en appelant les méthodes API datasets.insert, datasets.patch ou datasets.update.
  • 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 : 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 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'UI Web classique de BigQuery, 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 bien encore en exécutant les instructions LDD ALTER TABLE. Elle 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 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. 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.

  • Taux maximal d'opérations de partition : 50 opérations de partition 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
  • 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 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.

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'un 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 sa création, vous pouvez mettre à jour chaque fonction jusqu'à 5 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

Instructions de langage de manipulation de données

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

De plus, les instructions LMD sont soumises au taux maximal d'opérations de mise à jour des métadonnées de table. Si vous dépassez cette limite, relancez l'opération avec un intervalle exponentiel entre les tentatives.

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 de manière optimale. Il s'agit de la méthode recommandée pour utiliser BigQuery afin d'augmenter les quotas d'ingestion par flux.

  • 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 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 ou par table. Ce quota est cumulatif. Vous pouvez utiliser tout le quota sur une même table ou le diviser pour insérer des données en flux continu dans plusieurs tables d'un projet.

    Si vous dépassez cette valeur, des erreurs quotaExceeded sont générées.
  • Nombre maximal de lignes par seconde 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. Vous pouvez utiliser tout le quota sur une même table ou le diviser pour insérer des données en flux continu dans plusieurs tables d'un projet.

    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 : 5 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 : 10 000
    Il est recommandé d'utiliser au maximum 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 de manière 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.

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 : 500/seconde
    Lorsque vous appelez tabledata.list, vous pouvez envoyer jusqu'à 500 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.

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 et par projet : 10. Lorsque vous appelez tables.insert, vous pouvez créer au maximum 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 au maximum 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 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 au maximum 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.

  • Au niveau du projet Google Cloud, le nombre de requêtes est limité à 25 par seconde et par utilisateur.

  • Au niveau du projet Google Cloud, le nombre de requêtes est limité à 50 par seconde.

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

Les limites ci-dessous s'appliquent aux appels ReadRows utilisant l'API BigQuery Storage :

  • Appels ReadRows par minute : 5 000. Lorsque vous lisez des données à l'aide de l'API BigQuery Storage, vous êtes limité à 5 000 appels ReadRows par minute, par utilisateur et par projet.

Les limites suivantes s'appliquent à tous les autres appels de méthode utilisant l'API BigQuery Storage :

  • Appels d'API par minute : 1 000. Vous êtes limité à 1 000 appels de l'API BigQuery Storage par minute, par utilisateur 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 la page consacrée à la résolution des erreurs pour obtenir la liste complète des codes d'erreur et des étapes de dépannage.

Limiter l'utilisation avec les 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.