Options de routage

Lorsque vous envoyez des requêtes d'une application à Bigtable, vous utilisez un profil d'application qui indique à Bigtable comment gérer les requêtes. Un profil d'application spécifie les règles de routage pour les requêtes. Pour les instances qui utilisent la réplication, les règles de routage contrôlent les clusters qui reçoivent les requêtes et la manière dont les basculements sont gérés.

Ce document décrit les règles de routage disponibles pour un profil d'application standard.

Les règles de routage sont particulièrement importantes pour les cas d'utilisation d'isolation des charges de travail, lorsque vous ne pouvez pas utiliser Data Boost. Vous pouvez les configurer conjointement avec les priorités des requêtes.

Les règles de routage n'affectent pas la réplication, mais vous devez savoir comment fonctionne la réplication Bigtable avant de lire cette page. Vous devez également lire la section Basculements.

Routage vers un cluster unique

Une règle de routage vers un 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. Les profils d'application Data Boost et de niveau en mémoire (Preview) utilisent le routage vers un cluster unique.

Il s'agit de la seule règle de routage qui vous permet d'activer les transactions à ligne unique.

Une instance répliquée fournit normalement une cohérence à terme. Toutefois, vous pouvez obtenir une cohérence écriture-lecture pour une charge de travail dans une instance répliquée si vous configurez un profil d'application pour que cette charge de travail utilise le routage vers un cluster unique afin d'envoyer des requêtes de lecture et d'écriture au même cluster. Vous pouvez acheminer le trafic pour des charges de travail supplémentaires sur l'instance répliquée vers d'autres clusters de l'instance en fonction des exigences de votre charge de travail.

Routage multi-cluster

Une règle de routage multi-cluster achemine les requêtes que vous envoyez à une instance vers la région la plus proche dans laquelle l'instance possède un cluster. Si le cluster devient indisponible, le trafic bascule automatiquement vers le cluster disponible le plus proche.

Cette configuration fournit une cohérence à terme. Vous ne pouvez pas activer les transactions à ligne unique avec le routage multi-cluster, car celles-ci peuvent entraîner des conflits de données lorsque vous utilisez le routage multi-cluster. Pour en savoir plus, consultez la section Transactions à ligne unique.

Utilisez le routage multi-cluster si vous souhaitez une haute disponibilité. Pour obtenir des configurations d'instance recommandées et plus d'informations, consultez Créer une haute disponibilité (HA).

Lorsque vous utilisez le routage multi-cluster, vous pouvez acheminer les requêtes vers n'importe quel cluster de l'instance ou vers un groupe de clusters que vous définissez. Si votre charge de travail est principalement constituée d'opérations à ligne unique et que vous souhaitez obtenir un taux de cohérence écriture-lecture plus élevé, vous pouvez activer le routage d'affinité de ligne.

Pour en savoir plus sur les considérations de routage liées à SQL, consultez la section Routage avec SQL de ce document.

Routage vers tous les clusters

Le routage vers tous les clusters permet à chaque cluster de l'instance de recevoir des requêtes et d'effectuer un basculement.

Routage vers un groupe de clusters

Si vous souhaitez exclure un ou plusieurs clusters d'une instance d'un éventuel basculement, vous pouvez utiliser le routage vers un groupe de clusters. Cette forme de routage multi-cluster vous permet de spécifier un sous-ensemble de clusters vers lesquels un profil d'application peut envoyer du trafic. Cela peut être utile si vous souhaitez réserver un cluster pour une charge de travail distincte.

Routage d'affinité de ligne

Le routage d'affinité de ligne achemine automatiquement les requêtes de lecture et d'écriture d'une seule ligne vers un cluster spécifique en fonction de la clé de ligne de la requête.

Vous pouvez activer le routage d'affinité de ligne à l'aide de la gcloud CLI, de la Google Cloud console, de la bibliothèque cliente Bigtable pour Java ou de Terraform. Pour en savoir plus, consultez Créer un profil d'application.

Si vous souhaitez que le routage multi-cluster atteigne un taux de cohérence écriture-lecture plus élevé et que la plupart de vos requêtes soient des opérations à ligne unique, vous pouvez utiliser le routage d'affinité de ligne (routage persistant). Bigtable utilise la clé de ligne de la requête pour déterminer automatiquement le cluster vers lequel acheminer la requête. Vous ne pouvez pas définir manuellement le mappage entre la clé de ligne et le cluster.

Le routage d'affinité de ligne ne peut être utilisé que pour les requêtes de lecture ou d'écriture à ligne unique. Cela inclut les requêtes qui appellent ReadRows avec une clé spécifiée, MutateRow, et MutateRows avec une clé spécifiée, et BulkMutateRow avec une clé spécifiée.

La cohérence écriture-lecture n'est pas entièrement atteinte avec le routage d'affinité de ligne dans les cas suivants :

  • Ajout d'un cluster à l'instance : le routage d'affinité de ligne détermine le cluster vers lequel effectuer le routage en fonction de la clé de ligne. Si un cluster est ajouté ou supprimé de l'instance lorsque le routage d'affinité de ligne est activé, l'attribution de la clé de ligne peut changer. Pour vous assurer que l'ordre de basculement du cluster reste le même malgré les modifications apportées à la liste des clusters de l'instance, nous vous recommandons d'utiliser des groupes de clusters en définissant l'indicateur --restrict-to.

    Avec les groupes de clusters, vous ne pouvez pas supprimer un cluster dans une instance lorsqu'il est utilisé par un profil d'application. De plus, tout nouveau cluster ajouté à l'instance ne commence à recevoir des requêtes que s'il est explicitement ajouté au groupe de clusters du profil d'application.

  • Basculement : si un cluster est indisponible ou défectueux, les requêtes adressées au cluster concerné sont dirigées vers le cluster suivant selon l'ordre de basculement. Ce réacheminement peut avoir un impact sur la cohérence.

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

Routage avec SQL

Lorsque vous utilisez SQL pour interroger Bigtable, vous devez tenir compte de la manière dont vos requêtes sont acheminées. Le comportement de routage des requêtes SQL diffère des autres types de requêtes Bigtable de la manière suivante :

  • Bien qu'une règle de routage multi-cluster offre une haute disponibilité grâce au basculement automatique pour la plupart des requêtes, ce comportement ne s'étend pas aux requêtes SQL. Si une requête SQL échoue, elle ne bascule pas vers un autre cluster, même si votre profil d'application est configuré pour le routage multi-cluster.
  • Le routage d'affinité de ligne dirige les lectures et les écritures à ligne unique automatiquement vers un cluster spécifique en fonction de la clé de ligne. Toutefois, Bigtable n'est pas compatible avec cette règle de routage pour les requêtes SQL. Cette limitation signifie que vous ne pouvez pas utiliser le routage d'affinité de ligne avec la méthode ExecuteQuery, même si la requête est conçue pour lire une seule ligne. Si vous envoyez une requête ExecuteQuery à l'aide d'un profil d'application pour lequel l'indicateur --row-affinity est activé, la requête réussit, mais l'affinité de ligne n'est pas appliquée.

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 répliquées.

Si votre cas d'utilisation le permet, vous pouvez éviter ces conflits en utilisant des agrégats. Lorsque vous envoyez une requête d'ajout à un champ agrégé, la nouvelle valeur est fusionnée avec la valeur existante. Les agrégats vous permettent de conserver une somme ou un compteur en cours d'exécution. Pour en savoir plus, consultez la section Agréger des valeurs au moment de l'écriture.

Pour illustrer le problème qui peut survenir lorsque vous n'utilisez pas d'agrégats, 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 billet, votre application envoie une opération de 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 de lecture/modification/écriture ou de vérification/mutation en conflit à différents clusters.

Étape suivante