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 enregistre les modifications de données dans une table Bigtable au fur et à mesure des modifications, ce qui vous permet de les diffuser en flux continu pour les traiter. ou l'analyse.

Ce document présente les flux de modifications Bigtable. Avant de lire ce document, vous devez connaître les 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
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 au niveau de la table par un utilisateur ou 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 sous forme d'enregistrements de modification 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 de l'API Cloud Bigtable MutateRow, MutateRows, CheckAndMutateRow et ReadModifyWriteRow
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 à un table Bigtable, consultez Lectures Écritures, Suppressions, et Présentation de la récupération de mémoire

Les flux de modifications n'effectuent pas le suivi des modifications de schéma, comme l'ajout ou la modification d'un la famille de colonnes ou la topologie de réplication, comme l'ajout ou la suppression d'un cluster.

Enregistrements de modification des données pour chaque clé de ligne et chaque cluster dans l'horodatage de commit commande. Toutefois, il n'existe aucune garantie de tri des enregistrements de modification des données pour une clé de ligne ou cluster différent.

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 modifications de données

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

Si une valeur est écrasée, la nouvelle valeur écrite est enregistrée dans les données modifier l'enregistrement. 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 même moment que la modification est appliquée au premier cluster qui la reçoit. Pour Prenons l'exemple d'une instance à deux clusters. Si vous envoyez une requête d'écriture à Dans le tableau 1 du cluster A, le code temporel de validation de l'enregistrement des modifications de données est attribué l'écriture est reçue par le cluster A et l'enregistrement des modifications de données sur le 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 un ou plusieurs des éléments suivants :
- Écriture
  - 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 : 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 sur le tableau
Briseur de lien : 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, le cas échéant interrompu
Filigrane faible estimé : temps estimé depuis la partition de l'enregistrement rattrapé la réplication sur 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 des données, consultez l'API référence 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 stockage. Dans une instance qui utilise la réplication, une copie des données d'un flux de modification est stockée dans chaque cluster de l'instance contenant la table compatible avec le flux de modification.

L'espace de stockage utilisé pour les données de votre flux de modifications n'est pas pris en compte dans le total utilisation du stockage (% max.). Vous n'avez donc pas besoin d'ajouter de nœuds pour gérer l'espace de stockage supplémentaire consommé par les données des flux de modifications (même si vous aurez peut-être besoin pour ajouter des nœuds et augmenter la puissance de calcul). Toutefois, le stockage consommé par vos données de flux de modifications vous est facturé. Pour en savoir plus, consultez Considérations sur les coûts.

Lire un flux de modifications

Pour lire (diffuser) un flux de modifications, vous devez utiliser un profil d'application configuré pour routage vers un cluster unique. De plus, si vous diffusez des données à 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 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 du flux de modifications est associé à une tablette. Les tablettes sont des sous-sections d'un tableau qui sont redistribués selon les besoins pour équilibrer la charge de travail de requête de la table. Pour apprendre plus, voir Équilibrage de charge :

La bibliothèque cliente Java vous permet d'interroger chaque partition pour y apporter des modifications et fournit les informations requises pour gérer les modifications dans les partitions les divisions et les fusions.

Filigranes

Un filigrane est un horodatage qui estime la date de collecte avec réplication sur tous les clusters. Le filigrane de la partition est continuellement mis à jour au fur et à mesure de la réplication, et progresse dans le temps.

Chaque ChangeStreamMutation (enregistrement des modifications de données) inclut un champ estimatedLowWatermark, qui correspond au filigrane de la partition associé à l'enregistrement des modifications de données. Cet estimatedLowWatermark est un estime et ne garantit pas que des données n'ont pas encore été reçues le flux.

Filigranes pour les tables répliquées

Le estimatedLowWatermark d'une partition (filigrane faible) ne progresse pas si la réplication n'est pas complètement rattrapée pour la partition. Les pistes de lecture filigrane : le plus bas de tous les filigranes estimés au niveau de la partition : arrête l'avance si le filigrane d'une partition ne avance pas. A un filigrane qui ne progresse plus est considéré comme bloqué. Lorsque cette se produit. Si vous diffusez votre flux de modifications dans un pipeline, les étals.

De nombreux facteurs peuvent bloquer un ou plusieurs filigranes au niveau de la partition du temps, y compris les suivants:

Surcharge d'un cluster avec du trafic, ce qui entraîne une chute de la réplication pour une ou plusieurs partitions
Retards sur le 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 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 le processeur et le stockage pour une instance contenant des tables compatibles avec les flux de modifications, nous deux métriques propres à un flux de modifications. Vous pouvez consulter les métriques page Bigtable Monitoring ou à l'aide de la suite Cloud Monitoring d'outils.

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 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 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 si vous utilisez l'autoscaling) pour gérer le trafic supplémentaire lié à l'activation le 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 à les traiter. Traiter un flux de modifications, comme la lecture à l'aide d'un pipeline Dataflow, peut augmenter l'utilisation du processeur d'environ de 20 à 30%, en fonction du niveau d'activité de modification et de la façon dont les données de flux est lu.

Stockage

Vous êtes facturé les tarifs de stockage Bigtable standards pour stocker les enregistrements de modification de données de votre table. Le stockage du fichier créée pour suivre les métadonnées du flux de modifications. La durée de conservation que vous spécifiez affecte directement les coûts de stockage.

En règle générale, l'équivalent des enregistrements de modifications d'une journée, reflétant uniquement qui se sont produites ce jour-là, occupe environ 1,5 fois plus d'espace de stockage les données écrites ce jour-là sont consommées 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 du trafic. Consultez la section "Réseau" sur Tarifs de Bigtable pour obtenir la liste complète des taux de transfert de données réseau.

Frais de traitement

En fonction de la manière 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 dans Dataflow, vous payez pour les octets traités et pour le nœud de calcul, des machines qui traitent le job. Pour en savoir plus, consultez Tarifs de Dataflow

Supprimer des plages de lignes

Si possible, évitez de supprimer une ligne plage à partir d'une table dans laquelle un flux de modifications est activé. Si vous devez supprimer une plage de lignes, car Bigtable peut mettre beaucoup de temps à terminer et l'utilisation du CPU augmente pendant l'opération.