Options de routage

Lorsque vous envoyez des requêtes à Bigtable depuis une application, vous utilisez une application profil qui indique à Bigtable gérer les requêtes. Un profil d'application spécifie le routage pour les requêtes. Pour les instances qui utilisent la réplication, la règle de routage contrôle quels clusters reçoivent les requêtes et comment 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 charges de travail de l'isolation, lorsque vous ne pouvez pas utiliser Data Boost (Preview). Vous pouvez les configurer dans conjointement avec les priorités des demandes.

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

Routage vers un cluster unique

Une stratégie de 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.

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

Une instance répliquée fournit normalement des données cohérence. Toutefois, vous pouvez obtenir une cohérence de type "lecture de vos écritures" pour une charge de travail dans une instance répliquée si vous configurez un profil d'application pour cette charge de travail afin qu'il utilise le routage à cluster unique pour 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 à d'autres clusters de l'instance en fonction de votre charge de travail exigences.

Routage multi-cluster

Une règle de routage multicluster 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 le plus proche disponibles.

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

Utilisez le routage multicluster si vous souhaitez bénéficier d'une haute disponibilité. Pour les recommandations d'instances Compute Engine et d'autres détails, consultez la section Créer une haute disponibilité (haute disponibilité).

Les deux types de routage multicluster sont tous les clusters et les clusters groupe.

Routage vers un cluster

Le routage de tout cluster rend chaque cluster de l'instance disponible pour recevoir et le basculement.

Routage des groupes de clusters

Si vous souhaitez exclure un ou plusieurs clusters d'une instance vous pouvez utiliser le routage des groupes de clusters. Cette forme de routage multicluster vous permet de spécifier un sous-ensemble de clusters auquel 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.

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 ne permet prendre en charge 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 qui nécessitent une ligne les transactions peuvent causer 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égations. Lorsque vous envoyez une demande d'ajout à un champ agrégé, la nouvelle valeur est fusionnée avec la valeur existante. Les agrégations vous permettent de conserver une somme ou un compteur cumulé. Pour plus pour plus d'informations, consultez la section Valeurs agrégées au moment de l'écriture.

Pour illustrer le problème qui peut survenir lorsque vous n'utilisez pas d'agrégations, supposons vous avez une table que vous utilisez pour stocker les données d'un système de tickets. Vous utilisez un un compteur de nombres entiers pour stocker le nombre de tickets vendus. À chaque fois vous vendez un ticket, votre application envoie un pipeline read-modify-write 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 de ne pas envoyer des requêtes conflictuelles de lecture-modification-écriture ou de vérification/mutation clusters.

Étape suivante