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

Présentation des flux de modifications

Bigtable fournit la capture des données modifiées (CDC, Change Data Capture) avec sa fonctionnalité de flux de modifications. Un flux de modifications enregistre 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 de la CDC, y compris les suivants:

Déclencher une logique d'application en aval lorsque les modifications spécifiées se produisent
Intégration à un pipeline d'analyse de données
Répondre aux exigences d'audit et d'archivage

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

Un flux de modifications suit les modifications apportées au niveau de la table par un utilisateur ou une application, 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 capturées.

Toutes les modifications appliquées à une table compatible avec le flux de modifications sont stockées en tant qu'enregistrements des modifications de données. Les enregistrements de modification des données incluent les modifications de données 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 pages Lectures, Écritures, Suppressions et Présentation de la récupération de mémoire.

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 classés par code temporel de validation. Toutefois, il n'existe aucune garantie de tri des enregistrements de modification de données pour une clé de ligne ou un cluster différent.

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

Contenu d'un enregistrement de modifications de données

Chaque enregistrement de modification de données contient toutes les modifications apportées à 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 des modifications de données. L'enregistrement des modifications de données ne contient pas l'ancienne valeur.

Un enregistrement de modification de données reçoit son horodatage, appelé horodatage de commit, en même temps que la modification est appliquée au premier cluster qui la reçoit. Prenons l'exemple d'une instance à deux clusters. Si vous envoyez une requête d'écriture au Tableau 1 sur le cluster A, le code temporel de commit de l'enregistrement des modifications de données est attribué à la réception de l'écriture par le cluster A. L'enregistrement de modification de données du cluster B pour cette écriture possède le même horodatage de commit.

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

Entrées : modifications apportées à la ligne, y compris un ou plusieurs des éléments suivants :
- Écriture
  - Famille de colonnes
  - Le qualificatif de colonne
  - Code temporel
  - Valeur
- Suppression de cellules
  - Famille de colonnes
  - Le qualificatif de colonne
  - Plage d'horodatages
- Suppression d'une famille de colonnes
  - Famille de colonnes
  - Suppression à partir d'une ligne : la suppression d'une ligne est convertie en liste de suppressions à partir des 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 : déclenchée par l'utilisateur ou récupération de mémoire
ID du cluster ayant reçu la modification
Horodatage de commit : heure côté serveur à laquelle la modification a été validée dans la table.
Fonction de séparation : valeur permettant à l'application qui lit le flux d'utiliser la règle intégrée de résolution des conflits de Bigtable
Jeton : utilisé par l'application consommatrice pour reprendre le flux en cas d'interruption
Filigrane faible estimé : durée estimée depuis que la partition de l'enregistrement a été répliquée sur tous les clusters. Pour en savoir plus, consultez 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.

Stockage du flux de modifications

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 par 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 pour laquelle le flux de modifications est activé.

L'espace de stockage utilisé pour les données de votre flux de modifications n'est pas pris en compte dans votre utilisation totale du stockage (% max.). Ainsi, vous n'avez pas besoin d'ajouter de nœuds pour gérer l'augmentation de l'espace de stockage que consomme les données de flux de modifications (bien que vous deviez ajouter des nœuds pour augmenter la puissance de calcul). Toutefois, vous êtes facturé pour le stockage utilisé par les données de votre flux de modifications. Pour en savoir plus, consultez la section Considérations sur les coûts.

Lire un flux de modifications

Pour lire (en flux) un flux de modifications, vous devez utiliser un profil d'application configuré pour le routage vers un cluster unique. Si vous diffusez des flux à 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 à ligne unique, consultez la section Transactions à ligne unique.

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 plutôt que d'appeler l'API sans utiliser de bibliothèque cliente ni de connecteur:

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

Toutes ces options vous évitent de devoir suivre et gérer les modifications de partition causées par les divisions et les 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:

bibliothèque cliente Java

Client 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 modification en plusieurs partitions permettant de lire le flux de modifications en parallèle. Chaque partition du flux de modifications est associée à une tablet. Les tablets sont des sous-sections d'une table qui sont redistribuées selon les besoins pour équilibrer la charge de travail de requête de la table. Pour en savoir plus, consultez la page Équilibrage de charge.

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

Filigranes

Un filigrane est un horodatage qui estime la date à laquelle une partition a rattrapé la réplication sur tous les clusters. Le filigrane de la partition est mis à jour en continu à mesure que la réplication se produit, et progresse dans le temps.

Chaque ChangeStreamMutation (enregistrement de modification de données) inclut un champ estimatedLowWatermark, qui correspond au filigrane de la partition associée à l'enregistrement de modification de données. Ce estimatedLowWatermark est une estimation et ne garantit pas que le flux ne contient pas encore de données.

Filigranes pour les tables répliquées

Le estimatedLowWatermark (filigrane faible) d'une partition n'avance pas si la réplication n'est pas complètement rattrapée pour la partition. Le filigrane bas de l'ensemble du flux, le plus bas parmi tous les filigranes estimés au niveau de la partition, cesse d'avancer si le filigrane d'une partition ne progresse pas. Un filigrane qui ne progresse plus est considéré comme bloqué. Lorsque cela se produit, si vous diffusez votre flux de modifications dans un pipeline, celui-ci se bloque.

De nombreux facteurs peuvent bloquer un ou 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 la réplication pour une ou plusieurs partitions
Retards sur le réseau
Indisponibilité du cluster

Le connecteur Bigtable Beam gère cela en définissant l'horodatage 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 du stockage pour une instance contenant des tables compatibles avec les flux de modifications, nous proposons deux métriques spécifiques aux flux de modifications. Vous pouvez afficher les métriques sur la page Bigtable Monitoring ou à l'aide de la suite d'outils Cloud Monitoring.

Octets utilisés par les enregistrements de 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 page 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. Vous pouvez notamment vous attendre à entraîner des coûts de stockage plus élevés.

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 de 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 modifications, tel que sa lecture à 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 de flux sont lues.

Espace de stockage

Les tarifs de stockage Bigtable standards vous sont facturés pour le stockage des enregistrements de modification de données de votre table. Le stockage de la table créée pour suivre les métadonnées des flux de modifications vous est également facturé. La durée de conservation que vous spécifiez affecte directement les coûts de stockage.

En règle générale, l'équivalent d'une journée d'enregistrements de modifications de données (ne reflétant que les mutations qui se sont produites ce jour-là) occupe environ 1,5 fois plus de stockage que les données écrites ce jour-là sur le disque.

Transfert de données réseau

La lecture d'un flux de modifications dans plusieurs régions peut entraîner des coûts pour ce trafic. Consultez la section "Réseau" des tarifs de Bigtable pour obtenir la liste complète des taux de transfert de données réseau.

Frais de traitement

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

Supprimer des plages de lignes

Si 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 terminer l'opération et que l'utilisation du processeur augmente pendant l'opération.