Quotas et limites

Cette page présente les quotas et limites applicables à Cloud Bigtable.

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 affectent le nombre d'opérations d'administration Bigtable que vous pouvez effectuer au cours d'une période donnée.

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 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 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érations

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

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.

Par défaut, vous pouvez provisionner jusqu'à 30 nœuds SSD et 30 nœuds HDD par zone dans chaque projet Google Cloud. Si vous devez dépasser cette limite par défaut, vous pouvez demander une augmentation.

Pour connaître le nombre de nœuds SSD et HDD dont votre projet GCP dispose déjà dans chaque zone, utilisez Google Cloud Console. 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 de quota

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.

Aucuns frais ne s'appliquent lorsque vous demandez une augmentation de quota. Vos coûts ne seront en hausse 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.

Effectuez votre demande de ressources supplémentaires quelques jours à l'avance pour que le temps de traitement soit suffisant.

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.

Sauvegardes

  • Nombre maximal de sauvegardes pouvant être créées : 50 par table et par cluster
  • Valeur TTL minimale d'une sauvegarde : 6 heures après l'heure de création initiale
  • Valeur TTL maximale d'une sauvegarde : 30 jours après la date de création initiale

Taille des données dans les tables

Il est recommandé de concevoir votre schéma de sorte que la taille de vos données reste inférieure aux limites recommandées suivantes :

  • Clé de ligne unique : 4 Ko
  • 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

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

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

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

Règles d'utilisation

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