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

Présentation des flux de modifications

Bigtable fournit la capture de données modifiées (CDC) avec sa fonctionnalité de flux de modifications. Un flux de modifications capture les modifications de données dans une table Bigtable au fur et à mesure qu'elles se produisent, ce qui vous permet de les diffuser pour les traiter ou les analyser.

Ce document présente les flux de modifications Bigtable. Avant de lire ce document, vous devez avoir lu la présentation de Bigtable.

Les flux de modifications sont utiles pour les cas d'utilisation du CDC, y compris les suivants:

Déclencher la logique d'application en aval lorsque des modifications spécifiées se produisent
Intégrer un pipeline d'analyse de données
Respect des exigences d'audit et d'archivage

Qu'est-ce qu'un flux de modifications ?

Un flux de modifications suit les modifications apportées par un utilisateur ou une application au niveau de la table, généralement à l'aide de l'une des bibliothèques clientes Cloud Bigtable. Les modifications apportées à la récupération de mémoire sont également enregistrées.

Toutes les modifications appliquées à une table compatible avec un flux de modifications sont stockées en tant qu'enregistrements de modification de données. Les enregistrements de modification des données incluent les modifications appliquées par les éléments suivants:

Écritures, suppressions et mises à jour envoyées à l'aide des méthodes MutateRow, MutateRows, CheckAndMutateRow et ReadModifyWriteRow de l'API Cloud Bigtable
Suppressions effectuées en raison de la récupération de mémoire
Lignes supprimées à l'aide de la méthode DropRowRange de l'API Admin

Pour en savoir plus sur les types de modifications que vous pouvez envoyer à une table Bigtable, consultez les sections Lectures, Écritures, Suppressions et Présentation de la collecte des déchets.

Les flux de modifications ne suivent pas les modifications de schéma, telles que l'ajout ou la modification d'une famille de colonnes, ni la topologie de réplication, comme l'ajout ou la suppression d'un cluster.

Les enregistrements de modification des données pour chaque clé de ligne et chaque cluster sont triés par code temporel de validation. Toutefois, aucune garantie d'ordre n'est fournie pour les enregistrements de modification de données d'une autre clé de ligne ou d'un autre cluster.

Vous activez les flux de modifications sur une table et spécifiez une durée de conservation comprise entre 1 et 7 jours.

Contenu d'un enregistrement de modification des données

Chaque enregistrement de modification de données contient toutes les modifications d'une ligne qui ont été appliquées de manière atomique dans le cadre d'un seul appel RPC.

Si une valeur est écrasée, la nouvelle valeur écrite est enregistrée dans l'enregistrement de modification des données. L'enregistrement de modification des données ne contient pas l'ancienne valeur.

Un enregistrement de modification de données reçoit son code temporel, appelé code temporel de commit, au moment où la modification est appliquée au premier cluster qui la reçoit. Prenons l'exemple d'une instance avec deux clusters. Si vous envoyez une requête d'écriture à la table 1 du cluster A, l'horodatage de commit de l'enregistrement de modification de données est attribué lorsque l'écriture est reçue par le cluster A, et l'enregistrement de modification de données du cluster B pour cette écriture a le même code temporel de commit.

Chaque enregistrement de modification de données contient les éléments suivants:

Entrées : modifications apportées à la ligne, y compris l'une ou plusieurs des opérations suivantes :
- Écrire
  - Famille de colonnes
  - Le qualificatif de colonne
  - Horodatage
  - Valeur
- Suppression de cellules
  - Famille de colonnes
  - Le qualificatif de colonne
  - Plage d'horodatages
- Suppression d'une famille de colonnes
  - Famille de colonnes
  - Suppression d'une ligne : la suppression d'une ligne est convertie en liste de suppressions de familles de colonnes pour chaque famille de colonnes dans laquelle la ligne contient des données.
Clé de ligne : identifiant de la ligne modifiée
Type de modification : initiée par l'utilisateur ou récupération de mémoire
ID du cluster qui a reçu la modification
Code temporel de validation : heure côté serveur à laquelle la modification a été validée dans la table
Valeur de départage : valeur qui permet à l'application qui lit le flux d'utiliser la règle de résolution des conflits intégrée de Bigtable.
Jeton : utilisé par l'application consommatrice pour reprendre le flux en cas d'interruption
Estimation du repère bas : temps estimé depuis que la partition de l'enregistrement a rattrapé la réplication dans tous les clusters. Pour en savoir plus, consultez les pages Partitions et Filigranes.

Pour en savoir plus sur les champs d'un enregistrement de modification de données, consultez la documentation de référence de l'API pour DataChange.

Modifier le stockage du flux

Une table et son flux de modifications partagent les mêmes ressources au niveau du cluster, y compris les nœuds et le stockage. Par conséquent, le stockage des données du flux de modifications fait partie du stockage d'une table. Dans une instance qui utilise la réplication, une copie des données d'un flux de modifications est stockée dans chaque cluster de l'instance contenant la table compatible avec le flux de modifications.

L'espace de stockage utilisé pour vos données de flux de modifications n'est pas pris en compte dans l'utilisation totale de l'espace de stockage (% max). Par conséquent, vous n'avez pas besoin d'ajouter de nœuds pour gérer l'augmentation de stockage que les données de flux de modifications consomment (bien que vous deviez peut-être ajouter des nœuds pour une puissance de calcul supplémentaire). Toutefois, le stockage consommé par vos données de flux de modifications vous est facturé. Pour en savoir plus, consultez la section Considérations relatives aux coûts.

Lire un flux de modifications

Pour lire (lire en continu) un flux de modifications, vous devez utiliser un profil d'application configuré pour le routage à cluster unique. Si vous lisez en continu à l'aide de Dataflow, vous devez activer les transactions à ligne unique.

Pour en savoir plus sur les règles de routage, consultez la section Options de routage.

Pour en savoir plus sur les transactions sur une seule ligne, consultez Transactions sur une seule ligne.

Les méthodes de flux de modifications sont fournies par l'API Cloud Bigtable (API Data). Nous vous recommandons d'utiliser l'une des options suivantes au lieu d'appeler l'API sans utiliser de bibliothèque cliente ni de connecteur:

Modèles Dataflow
Connecteur Bigtable Beam
Bibliothèque cliente Java

Toutes les options vous évitent de devoir suivre et gérer les modifications de partition dues aux fractionnements et aux fusions.

Pour en savoir plus, consultez les sections sur ReadChangeStream

Modèles Dataflow

Vous pouvez utiliser l'un des modèles Dataflow suivants fournis par Google:

Connecteur Bigtable Beam

Vous pouvez utiliser le connecteur Bigtable Beam pour créer un pipeline:

Connecteur Bigtable Beam

Si vous ne souhaitez pas créer votre propre pipeline, vous pouvez utiliser les exemples de code du tutoriel ou du guide de démarrage rapide Bigtable comme point de départ pour votre code:

Bibliothèque cliente Java

Bibliothèque cliente Cloud Bigtable pour Java

Partitions

Pour maintenir un débit de lecture élevé correspondant à un taux d'écriture ou de modification élevé, Bigtable divise un flux de modifications en plusieurs partitions qui peuvent être utilisées pour lire le flux de modifications en parallèle. Chaque partition de flux de modifications est associée à une tablette. Les tablets sont des sous-sections d'une table qui sont redistribuées si nécessaire pour équilibrer la charge de travail des requêtes de la table. Pour en savoir plus, consultez la section Équilibrage de charge.

La bibliothèque cliente Java vous permet d'interroger chaque partition pour connaître les modifications et fournit les informations requises pour gérer les modifications apportées aux partitions en raison de scissions et de fusions.

Filigranes

Un filigrane est un code temporel qui estime la date à laquelle une partition a rattrapé la réplication dans tous les clusters. Le filigrane de la partition est mis à jour en continu à mesure que la réplication se produit, en avançant dans le temps.

Chaque ChangeStreamMutation (enregistrement de modification de données) inclut un champ estimatedLowWatermark, qui est le filigrane de la partition associée à l'enregistrement de modification de données. Cette estimatedLowWatermark est une estimation et ne garantit pas qu'il n'y a pas de données qui n'ont pas encore été reçues sur le flux.

Filigranes pour les tables répliquées

Le estimatedLowWatermark (seuil bas) d'une partition n'avance pas si la réplication n'est pas complètement à jour pour la partition. Le filigrane bas à l'échelle du flux (le plus bas de tous les filigranes bas estimés au niveau de la partition) cesse d'avancer si le filigrane d'une partition ne progresse pas. Un filigrane qui a cessé d'avancer est considéré comme bloqué. Dans ce cas, si vous diffusez votre flux de modifications dans un pipeline, le pipeline se bloque.

De nombreux facteurs peuvent entraîner le blocage d'un ou de plusieurs filigranes au niveau de la partition pendant un certain temps, y compris les suivants:

Surcharge d'un cluster avec du trafic qui entraîne un retard de réplication pour une ou plusieurs partitions
Retards réseau
Disponibilité du cluster

Le connecteur Bigtable Beam gère cela en définissant le code temporel de sortie sur zéro pour toutes les données. Pour en savoir plus, consultez la section Regrouper des données sans heure d'événement.

Surveillance

Pour vous aider à comprendre l'impact de l'activation d'un flux de modifications sur l'utilisation du processeur et de l'espace de stockage d'une instance contenant des tables compatibles avec les flux de modifications, nous fournissons deux métriques spécifiques aux flux de modifications. Vous pouvez afficher les métriques sur la page de surveillance de Bigtable ou à l'aide de la suite d'outils Cloud Monitoring.

Octets utilisés par les enregistrements du flux de modifications (change_stream_log_used_bytes)
Utilisation du processeur par flux de modifications ( utilise cpu_load_by_app_profile_by_method_by_table)

Pour en savoir plus sur ces métriques, consultez la section Surveillance.

Considérations liées au coût

L'activation d'un flux de modifications sur une table entraîne une augmentation des coûts pour les nœuds et le stockage. En particulier, vous devrez payer plus de frais de stockage.

Nœuds

Vous devez généralement ajouter des nœuds à un cluster (ou augmenter le nombre maximal de nœuds si vous utilisez l'autoscaling) pour gérer le trafic supplémentaire lié à l'activation et au traitement des enregistrements de modification des données.

L'activation d'un flux de modifications peut augmenter l'utilisation du processeur d'environ 10%, même avant de commencer à le traiter. Le traitement d'un flux de modification, par exemple en le lisant à l'aide d'un pipeline Dataflow, peut augmenter l'utilisation du processeur d'environ 20 à 30%, en fonction du niveau d'activité de modification et de la manière dont les données du flux sont lues.

Stockage

Vous êtes facturé les tarifs de stockage Bigtable standards pour stocker les enregistrements de modification de données de votre table. Le stockage de la table créée pour suivre les métadonnées du flux de modifications vous est également facturé. La période de conservation que vous spécifiez a un impact direct sur les coûts de stockage.

En règle générale, un jour d'enregistrements de modifications de données (qui ne reflètent que les mutations survenues ce jour-là) occupe environ 1,5 fois plus d'espace de stockage que les données écrites sur le disque ce jour-là.

Transfert de données réseau

Si vous lisez un flux de modifications entre les régions, vous pouvez encourir des coûts pour ce trafic. Pour obtenir la liste complète des tarifs de transfert de données réseau, consultez la section "Réseau" sur la page des tarifs Bigtable.

Coûts de traitement

En fonction de la façon dont vous lisez les enregistrements de modification des données, des coûts supplémentaires s'appliquent pour les services autres que Bigtable. Par exemple, si vous utilisez Dataflow, vous payez pour les octets traités et les machines de calcul qui traitent la tâche. Pour en savoir plus, consultez la page Tarifs de Dataflow.

Supprimer des plages de lignes

Dans la mesure du possible, évitez de supprimer une plage de lignes d'une table pour laquelle un flux de modifications est activé. Si vous devez supprimer une plage de lignes, sachez que Bigtable peut prendre beaucoup de temps pour effectuer l'opération et que l'utilisation du processeur augmentera au cours de l'opération.