Cette page a été traduite par l'API Cloud Translation.

À propos des profils d'application

Un profil d'application stocke des paramètres indiquant à votre instance Cloud Bigtable comment gérer les demandes entrantes provenant d'une application. Lorsqu'une application se connecte à une instance Bigtable, elle peut spécifier un profil d'application. Bigtable utilise ce profil pour les requêtes envoyées par l'application via cette connexion. Un profil d'application définit les règles de routage utilisées par Bigtable et détermine si les transactions à ligne unique sont autorisées.

Les profils d'application sont particulièrement utiles pour les instances comportant au moins deux clusters. Même si une instance ne comporte qu'un seul cluster, vous pouvez utiliser un profil d'application unique pour chaque application que vous exécutez ou pour différents composants au sein d'une même application. Vous pouvez alors afficher des graphiques distincts de vos métriques Bigtable pour chaque profil d'application.

Cette page décrit les paramètres contrôlés par un profil d'application, ainsi que le fonctionnement de ces profils avec votre application.

Si vous utilisez des profils d'application pour configurer des règles de routage de clusters, vous devez avoir pris connaissance de la présentation de la réplication Bigtable avant de lire cette page.

Règle de routage

Un profil d'application spécifie les règles de routage qui doivent être utilisées par Bigtable pour chaque requête :

Le routage à cluster unique achemine toutes les requêtes vers un cluster de votre instance. Si ce cluster devient indisponible, vous devez basculer manuellement vers un autre cluster.
Le routage multicluster achemine automatiquement les requêtes vers le cluster le plus proche dans une instance. Si le cluster devient indisponible, le trafic bascule automatiquement vers le cluster disponible le plus proche. Bigtable considère que les clusters d'une même région sont équidistants, même s'ils se trouvent dans des zones différentes. Vous pouvez configurer un profil d'application pour qu'il achemine le trafic vers tout cluster d'une instance, ou spécifier un groupe de clusters pour indiquer au profil d'application qu'il ne doit acheminer le trafic que vers certains clusters de l'instance.
Le routage vers un groupe de clusters envoie les requêtes au cluster disponible le plus proche dans un groupe de clusters que vous spécifiez dans les paramètres du profil d'application.

Pour en savoir plus sur le basculement, consultez Basculements. Pour savoir comment effectuer un basculement, consultez la section Gérer les basculements.

Transactions à ligne unique

Dans les mutations Bigtable, telles que les requêtes de lecture, d'écriture et de suppression, elles sont toujours atomiques au niveau des lignes. Cela inclut les mutations vers plusieurs colonnes sur une seule ligne, à condition qu'elles soient incluses dans la même opération de mutation. Bigtable n'accepte pas les transactions qui mettent à jour plusieurs lignes de manière atomique.

Cependant, Bigtable est compatible avec certaines opérations d'écriture qui nécessiteraient une transaction dans d'autres bases de données. En effet, Bigtable utilise des transactions à ligne unique pour effectuer ces opérations. Celles-ci incluent des opérations de lecture et d'écriture qui sont toutes exécutées de manière atomique, mais uniquement au niveau de la ligne :

Opérations lecture/modification/écriture, y compris incréments et ajouts. Une opération de lecture/modification/écriture lit une valeur existante, incrémente ou ajoute à la valeur existante, et écrit la valeur mise à jour dans la table.
Opérations vérification/mutation, également appelées mutations conditionnelles ou écritures conditionnelles. Lors d'une opération de vérification/mutation, Bigtable vérifie une ligne pour déterminer si elle remplit une condition spécifiée. Si la condition est remplie, Bigtable écrit de nouvelles valeurs sur la ligne.

Conflits entre transactions à ligne unique

Chaque cluster d'une instance Bigtable est un cluster principal qui accepte les opérations de lecture et d'écriture. Par conséquent, les opérations nécessitant des transactions à ligne unique peuvent générer des problèmes dans les instances multicluster.

Par exemple, supposons que vous disposiez d'une table permettant de stocker les données d'un système de billetterie. Vous utilisez un compteur d'entiers pour stocker le nombre de billets vendus. Chaque fois que vous vendez un ticket, votre application envoie une opération lecture-modification-écriture pour incrémenter le compteur de 1.

Si votre instance comporte un cluster, les applications clientes peuvent vendre des billets en même temps et incrémenter les compteurs sans perte de données, car les requêtes sont traitées de manière atomique dans l'ordre dans lequel elles sont reçues par ce cluster unique.

En revanche, si votre instance comporte plusieurs clusters et que votre profil d'application autorise le routage multicluster, les requêtes simultanées incrémentant le compteur peuvent être envoyées à différents clusters, puis répliquées sur les autres clusters de l'instance. Si vous envoyez simultanément deux requêtes d'incrémentation acheminées vers différents clusters, chacune termine sa transaction sans "savoir" que l'autre existe. Le compteur de chaque cluster est incrémenté d'une unité. Lorsque les données sont répliquées sur l'autre cluster, Bigtable n'a aucun moyen de savoir que vous souhaitez incrémenter la valeur de 2.

Pour vous aider à éviter des résultats inattendus, Bigtable effectue les opérations suivantes :

Nécessite chaque profil d'application pour indiquer l'autorisation ou non des transactions à ligne unique.
Cela vous empêche d'activer des transactions à ligne unique dans un profil d'application qui utilise un routage multi-cluster, car il n'existe aucun moyen sûr d'activer ces deux fonctionnalités simultanément.
Il vous avertit si vous activez des transactions à ligne unique dans au moins deux profils d'application différents utilisant le routage à cluster unique et pointant vers différents clusters. Si vous choisissez de créer ce type de configuration, vous devez vous assurer que vous n'envoyez pas de requêtes conflictuelles de lecture/modification/écriture ou de vérification/mutation à des clusters différents.

Fonctionnement des profils d'application

Un profil d'application spécifie les paramètres utilisés par Bigtable pour traiter les requêtes entrantes d'une instance.

De nombreux utilisateurs de Bigtable disposent de plusieurs applications se connectant à la même instance. Par exemple, vous pourriez avoir une application qui fournit des données aux clients à la demande et une autre application qui exécute des travaux par lots ponctuels pour analyser vos données. Pour gérer ces différentes applications, vous devez créer plusieurs profils d'application (au minimum un pour chaque application) et configurer chaque profil avec les paramètres appropriés pour l'application correspondante. Cette configuration permet de modifier des paramètres pour une application sans affecter les autres.

Vous pouvez également avoir une seule application qui remplit plusieurs fonctions, telles que l'affichage des données actuelles et l'interrogation des données historiques. Pour gérer ces différentes fonctions, vous devez créer un profil d'application pour chacune d'elles, afin de pouvoir configurer chaque fonction de manière distincte et mettre à jour ses paramètres sans affecter ceux des autres fonctions.

Chaque instance a un profil d'application par défaut default, mais vous pouvez également créer des profils d'application personnalisés pour chaque instance. Les sections ci-dessous décrivent les profils d'application default et personnalisés.

Pour utiliser un profil d'application, vous devez le spécifier dans votre code lorsque vous vous connectez à votre instance. Si vous ne spécifiez pas de profil d'application, Bigtable utilise le profil d'application par défaut de l'instance.

Profil d'application par défaut

Lorsque vous créez une instance, Bigtable crée automatiquement un profil d'application par défaut pour l'instance. Si votre application ne spécifie pas de profil d'application, ou si vous utilisez l'interface système HBase pour vous connecter à votre instance, Bigtable utilise les paramètres du profil d'application par défaut. Vous pouvez afficher et modifier ces paramètres à tout moment.

Les paramètres du profil d'application par défaut d'une instance dépendent du nombre de clusters dont l'instance disposait lors de sa création :

Si vous avez créé l'instance avec un cluster unique, le profil d'application default utilise le routage à cluster unique et active les transactions à ligne unique. Cela garantit que l'ajout ultérieur de clusters ne modifie pas le comportement de vos applications existantes.
Si vous avez créé l'instance avec plusieurs clusters, le profil d'application default utilise le routage multicluster. Les transactions à ligne unique ne sont jamais autorisées avec ce type de routage.

Le profil d'application par défaut n'est pas modifié lorsque vous ajoutez ou supprimez des clusters. Vous devez mettre à jour le profil d'application par défaut manuellement pour modifier ses paramètres. Cependant, il est recommandé de créer et d'utiliser un nouveau profil d'application plutôt que de modifier le profil d'application par défaut.

Profils d'application personnalisés

Un profil d'application personnalisé est un profil d'application que vous créez et configurez. Une instance peut comporter jusqu'à 2000 profils d'application.