Présentation des flux de modifications

Bigtable fournit la capture des données modifiées (CDC, Change Data Capture) avec ses 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
  • 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 qui utilise généralement 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 que modifications de données des enregistrements IP. 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 des modifications de données ne contient pas l'ancienne valeur.

Un enregistrement de modification de données reçoit son code temporel, appelé horodatage de commit, au moment en même temps 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 : <ph type="x-smartling-placeholder">
      </ph>
    • Écriture <ph type="x-smartling-placeholder">
        </ph>
      • Famille de colonnes
      • Le qualificatif de colonne
      • Horodatage
      • Valeur
    • Suppression de cellules <ph type="x-smartling-placeholder">
        </ph>
      • Famille de colonnes
      • Le qualificatif de colonne
      • Plage d'horodatages
    • Suppression d'une famille de colonnes <ph type="x-smartling-placeholder">
        </ph>
      • Famille de colonnes
      • Suppression d'une ligne : la suppression d'une ligne est convertie en liste des suppressions de familles de colonnes pour chaque famille de colonnes 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
  • Critère de séparation : valeur permettant à l'application qui lit le flux utilisez la fonctionnalité intégrée de résolution des conflits de Bigtable règlement
  • 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 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 modifications est stocké dans chaque cluster de l'instance contenant la modification table compatible avec les flux.

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, les frais suivants vous sont facturés : que les données de votre flux de modifications consomment. 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 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:

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

Bibliothèque cliente 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ées à 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. La faible qualité de l'ensemble du flux 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
  • Indisponibilité 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.

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 allouer plus d'espace de stockage de réduction des coûts.

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

Le tarif standard vous est facturé Tarifs de stockage Bigtable pour stocker les enregistrements de modification des 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

Selon la façon dont vous lisez les enregistrements de modification des données, des coûts supplémentaires pour autres que Bigtable s'appliquent. 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 opération, et l'utilisation du CPU augmente pendant l'opération.

Étape suivante