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 que vous créez automatiquement en exécutant des 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'indicateur --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

Vous êtes limité à quatre requêtes simultanées sur une source de données externes 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.

  • 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 d'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 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 d'API jobs.query et jobs.insert de type requête.

  • Délai d'exécution de la requête - 6 heures

Cette limite ne peut pas être modifiée.

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

  • Nombre maximal de paramètres de requête SQL standard : 10 000

  • Taille maximale des réponses : 10 Go compressés1

1 Les tailles varient 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

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 est adaptée à vos besoins.

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

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 000 (échecs compris)
  • Tâches de chargement par projet et par jour : 100 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 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 l'article Introduction au chargement de 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 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 que vous exécutez de manière automatisée à 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 (é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 d'API jobs.insert de type chargement.

  • Exportations par jour : 100 000 exportations par projet et jusqu'à 10 To par jour (la limite de données de 10 To est cumulative pour toutes les exportations)
  • Pour exporter plus de 10 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 de la console GCP 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 d'ensembles de données inclut toutes les opérations de mise à jour de métadonnées que vous effectuez à 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 d'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 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 à , 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. 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 relatives aux fonctions définies par l'utilisateur

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

  • Quantité de données générées par vos sorties JavaScript de fonctions définies 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 ci-dessous s'appliquent aux fonctions définies par l'utilisateur persistantes.
  • 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
  • Taux maximal 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 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.

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 :

Actuellement, ces quotas ne s'appliquent qu'à l'emplacement multirégional US. Pour en bénéficier, vous devez remplir le formulaire d'inscription de la fonctionnalité d'insertion en flux continu de BigQuery V2 (bêta).

  • Nombre maximal de lignes par seconde : 1 000 000
    Si vous ne remplissez pas le champ insertId pour chaque ligne insérée, vous êtes limité à 1 000 000 de lignes par seconde et par projet. Ce quota est cumulatif. Vous pouvez utiliser tout le quota sur une 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 : 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 :

  • Nombre maximal de lignes par seconde : 100 000
    Si vous remplissez le champ insertId pour chaque ligne insérée, vous êtes limité à 100 000 lignes par seconde et par projet ou par table. Ce quota est cumulatif. Vous pouvez utiliser tout le quota sur une 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 : 1 Mo
    Si vous dépassez cette valeur, des erreurs invalid sont générées.
  • Taille maximale des requêtes HTTP : 10 Mo
    Si vous dépassez cette valeur, des erreurs invalid sont générées.
  • Nombre maximal de lignes par requête : 10 000 lignes par requête
    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 envoyer une demande depuis Google Cloud Console. Vous pouvez définir un quota personnalisé sur les données en flux continu par incréments de 50 000 lignes. 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. 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 des instructions créant des tables telles que l'instruction LDD CREATE TABLE et des 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 de la réponse : 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 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 à 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 Résoudre les erreurs pour obtenir 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.