Quotas et limites

Ce document répertorie les quotas et limites système qui s'appliquent à Bigtable.

  • Les quotas spécifient la quantité d'une ressource partagée dénombrable que vous pouvez utiliser. Les quotas sont définis par des services Google Cloud tels que Bigtable.
  • Les limites système sont des valeurs fixes qui ne peuvent pas être modifiées.

Google Cloud utilise des quotas pour garantir l'équité et réduire les pics d'utilisation et de disponibilité des ressources. Un quota limite la quantité de ressources Google Cloud que votre projet Google Cloud peut utiliser. Les quotas s'appliquent à différents types de ressources, y compris les composants matériels, logiciels et réseau. Par exemple, les quotas peuvent limiter le nombre d'appels d'API à un service, le nombre d'équilibreurs de charge utilisés simultanément par votre projet ou le nombre de projets que vous pouvez créer. Les quotas protègent la communauté des utilisateurs de Google Cloud en empêchant la surcharge des services. Les quotas vous aident également à gérer vos propres ressources Google Cloud.

Le système Cloud Quotas effectue les opérations suivantes :

  • Surveille votre consommation de produits et services Google Cloud
  • Limite votre consommation de ces ressources
  • Permet de demander des modifications de la valeur du quota

Dans la plupart des cas, lorsque vous tentez d'utiliser plus d'une ressource que son quota ne le permet, le système bloque l'accès à la ressource et la tâche que vous essayez d'effectuer échoue.

Les quotas s'appliquent généralement au niveau du projet Google Cloud. Votre utilisation d'une ressource dans un projet n'affecte pas votre quota disponible dans un autre projet. Dans un projet Google Cloud, les quotas sont partagés entre toutes les applications et adresses IP.

Vous allez utiliser la console Google Cloud pour ajuster la plupart des quotas. Pour en savoir plus, consultez la section Demander un ajustement de quota.

Des limites système s'appliquent également aux ressources Bigtable. Les limites système ne peuvent pas être modifiées.

Quotas

Cette section décrit les quotas par défaut qui s'appliquent à l'ensemble de votre utilisation de Bigtable.

Quotas pour les opérations administratives

Les quotas suivants concernent le nombre d'opérations administratives Bigtable (appels à l'API Admin) que vous pouvez effectuer dans un délai donné.

En règle générale, vous ne pouvez pas demander une augmentation des quotas d'opérations administratives, sauf indication contraire. Des exceptions sont parfois accordées lorsqu'une justification solide est fournie. Toutefois, le nombre d'appels que votre application effectue vers l'API Admin ne doit pas augmenter lorsque l'utilisation augmente. Dans ce cas, cela signifie souvent que votre code d'application effectue des appels inutiles à l'API Admin. Vous devez modifier votre application au lieu de demander une augmentation du quota de l'opération d'administration.

Les quotas quotidiens sont réinitialisés à minuit (heure du Pacifique).

Nom Description Quota par défaut
Instances et clusters
Requêtes de lecture d'instance et de cluster Opération de lecture de la configuration d'une instance ou d'un cluster (par exemple, le nom de l'instance ou le nombre de nœuds dans un cluster), ou opération de lecture d'une liste d'instances

Par projet et par jour : 864 000 opérations (moyenne de 10 opérations/seconde)

Par minute et par utilisateur : 1000 opérations
Requêtes d'écriture d'instance et de cluster Opération de modification de la configuration d'une instance ou d'un cluster (par exemple, le nom de l'instance ou le nombre de nœuds dans un cluster), ou opération de création d'une instance

Par projet et par jour : 500 opérations

Par minute et par utilisateur : 100 opérations
Profils d'application
Requêtes de lecture de profil d'application Opération de lecture de la configuration d'un profil d'application

Par projet et par jour : 5000 opérations

Par minute et par utilisateur : 1000 opérations
Requêtes d'écriture de profil d'application Opération de modification de la configuration d'un profil d'application

Par minute et par projet : 500 opérations

Par minute et par utilisateur : 100 opérations
Tables
Requêtes de lecture de l'administrateur de table Opération de lecture de la configuration d'une table (par exemple, les détails sur ses familles de colonnes), ou opération de lecture d'une liste de tables

Par projet et par jour : 864 000 opérations (moyenne de 10 opérations/seconde)

Par minute et par utilisateur : 1000 opérations
Requêtes d'écriture de l'administrateur de la table Opération de modification de la configuration d'une table (par exemple, les paramètres de récupération de mémoire pour une famille de colonnes)

Par projet et par jour : 5 000 opérations

Par minute et par utilisateur : 100 opérations
Méthode DropRowRange Opération de suppression d'une plage de lignes d'une table en une seule fois

Par projet et par jour : 5 000 opérations

Par minute et par utilisateur : 100 opérations
Sauvegardes
Opérations de sauvegarde Création, mise à jour et suppression d'une sauvegarde

Par projet et par jour : 1 000 opérations

Par minute et par utilisateur : 10 opérations1
Requêtes de récupération de sauvegarde Obtention et liste des sauvegardes

Par projet et par jour : 864 000 opérations
Méthode RestoreTable Restauration d'une sauvegarde dans une nouvelle table

Par projet et par jour : 5 000 opérations

Par minute et par utilisateur : 100 opérations
Cloud Identity and Access Management
Requêtes d'obtention LCA détaillées Opération de lecture des informations sur la stratégie IAM pour une instance Bigtable, ou de test des autorisations IAM pour une instance

Par projet et par jour : 864 000 opérations (moyenne de 10 opérations/seconde)

Par minute et par utilisateur : 1000 opérations
Requêtes de définition LCA détaillées Opération de modification de la stratégie IAM pour une instance Bigtable

Par projet et par jour : 864 000 opérations (moyenne de 10 opérations/seconde)

Par minute et par utilisateur : 1000 opérations
  1. Peut bénéficier de l'augmentation de la limite de quota.

Quotas de nœuds

Un projet Google Cloud contient des instances Bigtable, qui sont des conteneurs pour les clusters. Un cluster représente le service Bigtable réel qui s'exécute dans une seule zone. Les clusters contiennent des nœuds, qui correspondent à des ressources de calcul permettant à Bigtable de gérer vos données.

Le nombre de nœuds par défaut que vous pouvez provisionner par zone dans chaque projet dépend de la région. Vous pouvez provisionner jusqu'à atteindre le nombre par défaut de nœuds HDD et le nombre par défaut de nœuds SSD par zone dans un projet.

Les quotas de nœuds par défaut sont les suivants :

Région SSD HDD
asia-east1 100 100
europe-west1 200 200
us-central1 200 200
us-east1 50 50
us-east4 50 50
us-west1 100 100
Tous les autres emplacements Bigtable 30 30

Si vous activez l'autoscaling pour un cluster, le nombre maximal de nœuds configuré est pris en compte dans cette limite, même si le cluster n'est pas mis à l'échelle avec ce nombre de nœuds. Si vous devez dépasser cette limite par défaut, vous pouvez demander une augmentation.

Quotas et disponibilité des nœuds

Le quota de nœuds correspond au nombre maximal de nœuds que vous pouvez provisionner par zone dans chaque projet. Les quotas ne garantissent pas que vous êtes toujours en mesure d'ajouter des nœuds à un cluster. Si une zone ne dispose plus de nœuds, vous ne pourrez peut-être pas ajouter de nœuds à un cluster de cette zone, même si vous disposez d'un quota suffisant dans votre projet.

Par exemple, si vous essayez d'ajouter 10 nœuds SSD à un cluster qui en contient déjà 20, mais que la zone ne dispose plus de nœuds, vous ne pourrez pas ajouter ces 10 nœuds, même si votre quota de nœuds SSD dans cette région est de 30.

Dans de telles situations, nous essayons d'augmenter les ressources de nœud d'une zone, puis d'accorder les ressources une fois qu'elles sont disponibles en réponse à vos demandes, sans garantie de délai et d'achèvement.

La disponibilité des nœuds que vous avez provisionnés est toujours garantie.

Quotas Data Boost

Les quotas de SPU (Server Processing Unit) suivants s'appliquent par projet et par région.

Région SPU
asia-east1 100 000
europe-west1 200 000
us-central1 200 000
us-east1 100 000
us-east4 100 000
us-west1 100 000
Tous les autres emplacements Bigtable 30 000

Pour en savoir plus sur Data Boost, consultez la présentation de Data Boost.

Afficher les informations sur les quotas

Pour connaître le nombre de nœuds SSD et HDD dont votre projet Google Cloud dispose déjà dans chaque zone, utilisez la console Google Cloud. Dans le volet de navigation de gauche, placez le curseur sur IAM et administration, cliquez sur Quotas, puis sélectionnez le service "API Bigtable Admin" dans la liste déroulante Service.

Vous trouverez sur cette page des lignes indiquant les quotas pour chaque combinaison de service, type de nœud et emplacement. Recherchez les lignes portant le sous-titre Nœuds SSD par zone ou Nœuds HDD par zone. La colonne Limite indique le nombre maximal de nœuds autorisés pour le type de nœud et l'emplacement donnés, tandis que la colonne Utilisation actuelle spécifie le nombre de nœuds qui existent actuellement. La différence entre ces deux chiffres correspond au nombre de nœuds que vous pouvez ajouter sans avoir à demander des nœuds supplémentaires.

Demander une augmentation du quota de nœuds

Pour garantir qu'il y aura assez de temps pour répondre à votre demande, planifiez toujours vos ressources à l'avance et demandez des ressources supplémentaires quelques jours avant d'être susceptible d'en avoir besoin. Il n'est pas garanti que les demandes d'augmentation de quota de nœuds soient acceptées. Pour en savoir plus, consultez la section Les quotas et leur utilisation.

Vous devez au moins disposer d'autorisations de niveau éditeur pour le projet qui contient l'instance pour laquelle vous demandez une augmentation de quota de nœuds.

Aucuns frais ne s'appliquent lorsque vous demandez une augmentation de quota de nœuds. Vos coûts n'augmentent que si vous utilisez plus de ressources.

  1. Accédez à la page Quotas.

    Accéder à la page Quotas

  2. Sur la page Quotas, sélectionnez les quotas à modifier.
  3. En haut de la page, cliquez sur le bouton Modifier les quotas.
  4. Dans le volet de droite, saisissez votre nom, votre adresse e-mail et votre numéro de téléphone, puis cliquez sur Suivant.
  5. Saisissez la nouvelle limite de quota souhaitée, puis cliquez sur Suivant.
  6. Envoyez la demande.

Limites

Cette section décrit les limites applicables à votre utilisation de Bigtable. Les limites sont intégrées au service et ne peuvent pas être modifiées.

Profils d'application par instance

Chaque instance peut avoir un maximum de 2 000 profils d'application.

Vues autorisées

  • Vues autorisées par instance Bigtable: jusqu'à 10 000
  • Préfixes de qualificatifs de colonne par vue autorisée: 10

Sauvegardes

  • Nombre maximal de sauvegardes standards pouvant être créées: 150 par table et par cluster
  • Nombre maximal de sauvegardes à chaud pouvant être créées: 10 par table et par cluster
  • Durée de conservation minimale d'une sauvegarde: 6 heures après la création initiale
  • Durée de conservation maximale d'une sauvegarde: 90 jours après la date de création initiale

Data Boost

Un profil d'application Data Boost ne peut pas envoyer plus de 1 000 requêtes de lecture par seconde.

Taille des données dans les tables

Limites recommandées

Concevez votre schéma de sorte que la taille de vos données reste inférieure aux limites recommandées.

  • Familles de colonnes par table : 100
  • Qualificatif de colonne unique : 16 Ko
  • Valeur unique dans une cellule de table : 10 Mo
  • Toutes les valeurs d'une seule ligne : 100 Mo

Limites strictes

De plus, vos données doivent respecter les limites strictes suivantes :

  • Clé de ligne unique : 4 Ko
  • Valeur unique dans une cellule de table : 100 Mo
  • Toutes les valeurs d'une seule ligne : 256 Mo

Ces limites de taille sont mesurées en kilo-octets (Ko) binaires, où 1 Ko équivaut à 210 octets, et en mégaoctets (Mo) binaires, où 1 Mo équivaut à 220 octets. Ces unités de mesure sont également appelées kibioctets (Kio) et mébioctets (Mio).

Limites des opérations

Lorsque vous envoyez plusieurs mutations à Bigtable sous la forme d'un lot unique, les limites suivantes s'appliquent :

  • Un lot de mutations conditionnelles, qui font appel à CheckAndMutate, peut inclure jusqu'à 100 000 vraies mutations et jusqu'à 100 000 mutations par lot.

  • Dans les lots de tous les autres types de mutations, vous ne pouvez pas inclure plus de 100 000 mutations dans le lot.

Régions par instance

Une instance Bigtable peut avoir des clusters dans un maximum de huit régions où Bigtable est disponible. Vous pouvez créer un cluster dans chaque zone d'une région. Pour obtenir la liste des zones disponibles, consultez la page Emplacements Bigtable.

Filtres de lignes

Un filtre de ligne ne peut pas dépasser 20 Ko. Si vous recevez un message d'erreur, réécrivez ou raccourcissez votre filtre.

Stockage par nœud

Si un cluster ne dispose pas de suffisamment de nœuds compte tenu de sa charge de travail actuelle et de la quantité de données stockées, Bigtable ne disposera pas de ressources de processeur suffisantes pour gérer l'ensemble des tablets associés au cluster. Par ailleurs, Bigtable ne sera pas en mesure d'effectuer les tâches de maintenance essentielles en arrière-plan. Par conséquent, le cluster risque de ne pas pouvoir gérer les requêtes entrantes, ce qui peut entraîner une augmentation de la latence. Pour en savoir plus, consultez la section Compromis entre utilisation du stockage et performances.

Pour éviter ces problèmes, vous devez surveiller l'utilisation du stockage sur vos clusters afin de vous assurer qu'ils disposent de suffisamment de nœuds pour gérer les données stockées, en fonction des limites ci-dessous :

  • Clusters SSD : 5 To par nœud
  • Clusters HDD : 16 To par nœud

Ces valeurs sont exprimées en téraoctets (To) binaires, où 1 To équivaut à 240 octets. Cette unité de mesure est également connue sous le nom de tébioctet (Tio).

Une bonne pratique consiste à ajouter suffisamment de nœuds à votre cluster afin de n'utiliser que 70 % de ces limites. Vous pourrez ainsi gérer les pics soudains d'utilisation du stockage. Par exemple, si vous stockez 50 To de données dans un cluster qui utilise le stockage SSD, vous devez prévoir au moins 15 nœuds, qui peuvent donc gérer jusqu'à 75 To de données. Si vous n'ajoutez pas une quantité importante de données au cluster, vous pouvez dépasser la limite recommandée et atteindre 100 % de cette dernière.

Tables par instance

Bigtable accepte jusqu'à 1 000 tables dans chaque instance.

Limites de longueur des ID

Vous trouverez ci-dessous les longueurs d'ID minimales et maximales (nombre de caractères) acceptées par Bigtable.

  • Profil d'application : 1-50
  • Sauvegarde : 1-50
  • Cluster : 6-30
  • Famille de colonnes : 1-64
  • Instance : 6-33
  • Table : 1-50
  • Vue autorisée: 1-50

Règles d'utilisation

Pour pouvoir utiliser ce service, vous devez accepter les Conditions d'utilisation et les Règles de confidentialité de Google.