Quotas et limites

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

Un quota limite la quantité d'une ressource Google Cloud partagée particulière que votre projet Google Cloud peut utiliser, y compris les composants matériels, logiciels et réseau. Par conséquent, les quotas font partie d'un système qui effectue les opérations suivantes :

Surveille votre utilisation ou votre consommation des produits et services Google Cloud
Limite la consommation de ces ressources pour des raisons telles que l'équité et la réduction des pics d'utilisation.
Gère des configurations qui appliquent automatiquement des restrictions recommandées.
Fournit un moyen de demander ou d'effectuer des modifications de quota.

Dans la plupart des cas, lorsqu'un quota est dépassé, le système bloque immédiatement l'accès à la ressource Google concernée et la tâche que vous essayez d'effectuer échoue. Dans la plupart des cas, les quotas s'appliquent à chaque projet Google Cloud. Ils sont partagés entre toutes les applications et adresses IP qui utilisent ce projet.

Pour demander une augmentation ou une diminution de la plupart des quotas, vous pouvez utiliser Google Cloud Console. Pour en savoir plus, consultez Demander une augmentation de quota.

Il existe également des limites pour les ressources Bigtable. Ces limites ne sont pas liées au système de quotas. Sauf indication contraire, les limites 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 général, vous ne pouvez pas demander une augmentation des quotas d'opérations d'administration, sauf indication contraire. Des exceptions sont parfois accordées lorsqu'une justification solide est fournie. Toutefois, le nombre d'appels que votre application envoie à 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 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	Lecture des informations sur la stratégie IAM d'une instance Bigtable ou 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	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
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'au nombre par défaut de nœuds HDD et jusqu'au 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 pourrez toujours 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.

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.

Accédez à la page Quotas.
Accéder à la page Quotas
Sur la page Quotas, sélectionnez les quotas à modifier.
En haut de la page, cliquez sur le bouton Modifier les quotas.
Dans le volet de droite, saisissez votre nom, votre adresse e-mail et votre numéro de téléphone, puis cliquez sur Suivant.
Saisissez la nouvelle limite de quota souhaitée, puis cliquez sur Suivant.
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.

Sauvegardes

Nombre maximal de sauvegardes pouvant être créées: 150 par table et par cluster
Durée de conservation minimale d'une sauvegarde: 6 heures après l'heure de 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 ne dépasse pas ces 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 à 2¹⁰ octets, et en mégaoctets (Mo) binaires, où 1 Mo équivaut à 2²⁰ 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, vous devez reconcevoir ou raccourcir 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 à 2⁴⁰ 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.