Présentation de la réplication

La fonctionnalité de réplication de Bigtable vous permet de copier vos données dans plusieurs régions ou plusieurs zones d'une même région afin d'améliorer leur disponibilité et leur durabilité. Vous pouvez également isoler des charges de travail en redirigeant différents types de requêtes vers plusieurs clusters.

Cette page explique le fonctionnement de la réplication dans Bigtable et décrit certains cas d'utilisation courants. Elle présente également le modèle de cohérence utilisé par Bigtable lorsque vous activez la réplication et décrit ce qui se passe lors du basculement d'un cluster vers un autre.

Pour découvrir des exemples de paramètres à utiliser pour mettre en œuvre des cas d'utilisation courants, consultez la section Exemples de paramètres de réplication.
Pour apprendre à créer une instance qui utilise la réplication, consultez la page Créer une instance.
Pour savoir comment activer la réplication pour une instance existante, consultez la page Ajouter un cluster.
Pour comprendre les coûts associés à la réplication, consultez la page Tarification.

Avant de lire cette page, vous devez avoir lu la présentation de Bigtable.

Fonctionnement de la réplication

Pour utiliser la réplication dans une instance Bigtable, créez une instance avec plusieurs clusters ou ajoutez des clusters à une instance existante.

Les instances Bigtable peuvent comporter des clusters situés dans un maximum de huit régions Bigtable, chacune d'entre elles ne pouvant contenir qu'un seul cluster par zone. Par exemple, si vous créez une instance dans huit régions comportant chacune trois zones, votre instance peut avoir jusqu'à 24 clusters.

Chaque zone d'une région ne peut contenir qu'un seul cluster. Le fait de disposer de clusters dans différentes zones ou régions vous permet d'accéder aux données de votre instance même si une zone ou une région Google Cloud devient indisponible.

Lorsque vous créez une instance avec plusieurs clusters, Bigtable commence immédiatement à synchroniser vos données entre les clusters, créant ainsi une copie distincte et indépendante de vos données dans chaque zone où votre instance possède un cluster. De même, lorsque vous ajoutez un cluster à une instance existante, Bigtable copie vos données existantes de la zone du cluster d'origine vers la zone du nouveau cluster, puis synchronise les modifications apportées aux données entre les zones.

Bigtable réplique toutes les modifications apportées aux données, y compris les types de modifications suivants :

Mises à jour des données dans les tables existantes
Création ou suppression de tables
Ajout ou suppression de familles de colonnes
Modifications apportées au règlement spécifique à la récupération de mémoire d'une famille de colonnes

Il est important de noter que la réplication présente une certaine latence et que la cohérence entre les instances dupliquées est à terme. Il est important de noter que la réplication présente une certaine latence et que la cohérence entre les clusters est définitive.

Bigtable considère chaque cluster de votre instance comme un cluster principal. Vous pouvez donc effectuer des opérations de lecture et d'écriture dans chaque cluster. Vous pouvez également configurer votre instance pour rediriger les requêtes de plusieurs types d'applications vers différents clusters.

Avant d'ajouter des clusters à une instance, vous devez prendre en compte les restrictions qui s'appliquent lorsque vous modifiez les stratégies de récupération de mémoire des tables répliquées.

Performances

L'utilisation de la réplication a des conséquences sur les performances que vous devez planifier lorsque vous créez une instance répliquée ou activez la réplication en ajoutant un cluster à une instance à cluster unique. Par exemple, les clusters répliqués dans différentes régions ont généralement une latence de réplication supérieure à celle des clusters répliqués dans la même région. De plus, les clusters dans les instances comportant plusieurs clusters nécessitent souvent plus de nœuds pour gérer la réplication supplémentaire. Pour en savoir plus, consultez la page Analyser les performances.

Cas d'utilisation

Cette section décrit quelques cas d'utilisation courants de la réplication Bigtable. Pour découvrir les meilleurs paramètres de configuration pour chaque cas d'utilisation et consulter des conseils sur la mise en œuvre d'autres cas, consultez les Exemples de paramètres de réplication.

Isoler les applications actives des lectures par lot

Lorsque vous utilisez un seul cluster pour exécuter une tâche d'analyse par lot effectuant de nombreuses lectures volumineuses aux côtés d'une application réalisant une combinaison d'opérations de lecture et d'écriture, cela peut ralentir l'exécution de cette dernière. Avec la réplication, vous pouvez utiliser des profils d'application avec un routage à un seul cluster pour acheminer vers des clusters différents le trafic des applications et les tâches d'analyse par lot, afin que ces dernières ne nuisent pas à l'exécution de vos applications. En savoir plus sur la mise en œuvre de ce cas d'utilisation

Améliorer la disponibilité

Si vous ne disposez que d'un seul cluster dans une instance, la durabilité et la disponibilité de vos données sont limitées à la zone dans laquelle se trouve le cluster. La réplication peut améliorer la durabilité et la disponibilité en stockant des copies séparées de vos données dans plusieurs zones ou régions et en opérant un basculement automatique entre les clusters si nécessaire. En savoir plus sur la mise en œuvre de ce cas d'utilisation

Fournir une sauvegarde en quasi-temps réel

Dans certains cas, vous devrez toujours rediriger les requêtes vers un seul cluster (par exemple, si vous ne pouvez pas vous permettre de lire des données obsolètes). Cependant, vous pouvez tout de même utiliser la réplication pour traiter les requêtes avec un seul cluster et en utiliser un autre pour effectuer une sauvegarde en quasi-temps réel. Si le cluster actif devient indisponible, vous pouvez basculer manuellement vers le cluster de sauvegarde pour réduire le temps d'arrêt. En savoir plus sur la mise en œuvre de ce cas d'utilisation

S'assurer que ses données ont une présence mondiale

Vous pouvez configurer une réplication dans des emplacements situés à travers le monde pour rapprocher vos données de vos clients. Par exemple, vous pouvez créer une instance avec des clusters répliqués aux États-Unis, en Europe et en Asie, puis configurer des profils d'application pour acheminer le trafic des applications vers le cluster le plus proche. En savoir plus sur la mise en œuvre de ce cas d'utilisation

Modèle de cohérence

Par défaut, la réplication de Bigtable est cohérente à terme. Ce terme signifie que lorsque vous écrivez une modification dans un cluster, vous pouvez éventuellement lire cette modification à partir des autres clusters de l'instance, mais seulement après que la modification a été répliquée entre les clusters.

Si votre instance est réactive, la latence de la réplication est généralement de quelques secondes ou de quelques minutes, et non de plusieurs heures. Toutefois, si vous écrivez une grande quantité de données sur un cluster, ou si un cluster est surchargé ou temporairement indisponible, la réplication peut prendre un certain temps. En outre, la réplication peut prendre plus de temps si vos clusters sont éloignés les uns des autres. Par conséquent, il n'est normalement pas prudent de supposer que vous lisez toujours la dernière valeur écrite, ou que l'attente de quelques secondes après une écriture donne suffisamment de temps à Bigtable pour que la modification soit répliquée.

Si vous devez garantir une cohérence différente, Bigtable peut également fournir une cohérence écriture-lecture lorsque la réplication est activée, pour vous assurer qu'une application ne lira jamais des données plus anciennes que ses écritures les plus récentes. Pour assurer la cohérence écriture-lecture sur un groupe d'applications, chaque application doit utiliser un profil d'application configuré pour le routage vers un cluster unique. Tous les profils d'application doivent rediriger les requêtes vers le même cluster. Vous pouvez utiliser les clusters supplémentaires de l'instance simultanément à d'autres fins.

Dans certains cas d'utilisation de la réplication, Bigtable peut également fournir une cohérence forte, ce qui garantit que toutes vos applications voient vos données dans le même état. Pour obtenir une cohérence forte, utilisez la configuration de profil d'application de routage à cluster unique pour la cohérence lecture/écriture décrite précédemment, mais vous ne devez pas utiliser les clusters supplémentaires de l'instance, sauf si vous devez basculer vers un autre cluster. Consultez les exemples de paramètres de réplication pour voir si cela est possible pour votre cas d'utilisation.

Résolution de conflits

Chaque valeur de cellule d'une table Bigtable est identifiée de manière unique par le quatre-tuple (clé de ligne, famille de colonnes, qualificatif de colonne, horodatage). Pour en savoir plus sur ces identifiants, consultez la section Modèle de stockage de Bigtable. Dans les rares cas où deux écritures avec exactement le même quatre-tuple sont envoyées à deux clusters différents, Bigtable résout automatiquement le conflit à l'aide d'un algorithme interne qui stipule que la dernière écriture l'emporte, en se basant sur l'heure du serveur. La mise en œuvre de "la dernière écriture l'emporte" de Bigtable est déterministe. Lorsque la réplication rattrape le retard, tous les clusters ont la même valeur pour le quatre-tuple.

Profils d'application

Si une instance utilise la réplication, vous devez utiliser des profils d'application pour spécifier les règles de routage. Les profils d'application déterminent également si vous pouvez effectuer des transactions à ligne unique, y compris des opérations lecture-modification-écriture (par exemple, incréments et ajouts), et des opérations de vérification et de mutation (également appelées mutations ou écritures conditionnelles).

Pour en savoir plus, consultez les Profils d'application. Pour découvrir des exemples de paramètres à utiliser pour mettre en œuvre des cas d'utilisation courants, consultez la section Exemples de paramètres de réplication.

Règles de routage

Chaque profil d'application possède une règle de routage qui déterminer quels clusters traitent les requêtes entrantes de vos applications. Les options de règles de routage incluent les suivantes :

Routage à cluster unique : envoie toutes les requêtes vers un seul cluster que vous spécifiez.
Routage multicluster vers n'importe quel cluster : envoie des requêtes au cluster disponible le plus proche dans l'instance.
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.

Basculements

Si un cluster Bigtable ne répond plus, la réplication permet au trafic entrant de basculer vers un autre cluster de la même instance. Le basculement peut s'effectuer manuellement ou automatiquement, en fonction du profil d'application utilisé et de sa configuration.

Pour en savoir plus, consultez la section Basculements.

Supprimer des plages de lignes lorsque la réplication est activée

L'API Cloud Bigtable Admin vous permet de supprimer une plage de lignes contiguës d'une table en fonction de leurs clés de ligne. Dans les instances qui n'utilisent pas la réplication, Bigtable peut supprimer une plage de lignes rapidement et efficacement. Cependant, lorsque vous activez la réplication, la suppression d'une plage de lignes est nettement plus lente et beaucoup moins efficace.