Présentation des flux de modifications

Un flux de modifications surveille et diffuse les modifications de données d'une base de données Spanner (insertions, mises à jour et suppressions) en temps quasi réel.

Cette page offre un aperçu général des flux de modifications Spanner: leur rôle et leur fonctionnement. Pour découvrir comment créer et gérer des flux de modifications dans votre base de données et les associer à d'autres services, suivez les liens de la section Et maintenant ?.

Objectif des flux de modifications

Les flux de modifications offrent un moyen flexible et évolutif de diffuser les modifications de données vers d'autres services. Vous trouverez ci-dessous des cas d'utilisation courants :

  • Répliquer les modifications de données Spanner dans un entrepôt de données, tel que BigQuery, à des fins d'analyse.

  • Déclenchement de la logique d'application en fonction des modifications de données envoyées à une file d'attente de messages, telle que Pub/Sub.

  • Stocker les modifications de données dans Cloud Storage, à des fins de conformité ou d'archivage.

Modifier la configuration du flux de modifications

Spanner traite les flux de modifications comme des objets de schéma, tout comme les tables et les index. Par conséquent, vous créez, modifiez et supprimez des flux de modifications à l'aide d'instructions LDD, et vous pouvez afficher les flux de modifications d'une base de données comme les autres objets de schéma gérés par le LDD.

Vous pouvez configurer un flux de modifications pour surveiller les modifications de données dans l'ensemble d'une base de données ou limiter son champ d'application à des tables et des colonnes spécifiques. Une base de données peut avoir plusieurs flux de modifications, et une table ou une colonne particulière peut être surveillée par plusieurs flux, dans la limite.

Vous pouvez éventuellement configurer un flux de modifications avec les éléments suivants:

L'émission de la requête DDL qui crée un flux de modifications lance une opération de longue durée. Une fois la création terminée, le nouveau flux de modifications commence immédiatement à surveiller les tables et les colonnes qui lui sont attribuées.

Surveiller implicitement les tables et les colonnes

Les flux de modifications qui surveillent une table entière surveillent implicitement toutes les colonnes de cette table, même lorsque la définition de cette table est mise à jour. Par exemple, lorsque vous ajoutez de nouvelles colonnes à cette table, le flux de modifications commence automatiquement à surveiller ces nouvelles colonnes, sans aucune modification de la configuration de ce flux de modifications. De même, le flux de modifications arrête automatiquement de surveiller les colonnes supprimées de cette table.

Les flux de modifications de la base de données entière fonctionnent de la même manière. Ils surveillent implicitement chaque colonne de chaque table, surveillent automatiquement les tables ou colonnes ajoutées après la création du flux de modifications et cessent de surveiller les tables ou colonnes supprimées.

Surveiller explicitement les tables et les colonnes

Si vous configurez un flux de modifications pour qu'il ne surveille que certaines colonnes d'une table, et que vous ajoutez ensuite des colonnes à cette table, le flux de modifications ne commencera pas à surveiller ces colonnes, sauf si vous le reconfigurez.

Le schéma de la base de données traite les flux de modifications comme des objets dépendants de toutes les colonnes ou tables qu'ils surveillent explicitement. Avant de pouvoir supprimer une colonne ou une table de ce type, vous devez la supprimer manuellement de la configuration de tout flux de modifications qui la surveille explicitement.

Types de modifications de données surveillés par les flux de modifications

Les modifications de données qu'un flux de modifications surveille incluent toutes les insertions, mises à jour et suppressions effectuées sur les tables et les colonnes qu'il surveille. Ces modifications peuvent provenir des sources suivantes:

Les flux de modifications ne peuvent surveiller les modifications de données que dans les colonnes et les tables créées par l'utilisateur. Ils ne surveillent pas les index, les vues, d'autres flux de modifications ni les tables système telles que le schéma d'informations ou les tables de statistiques. Les flux de modifications ne surveillent pas les colonnes générées, sauf si la colonne fait partie de la clé primaire. Les colonnes de clé primaire sont toujours suivies.

De plus, les flux de modifications ne surveillent pas les modifications de schéma ni les modifications de données qui en résultent directement, à l'exception des remplissages pour les valeurs par défaut. Par exemple, un flux de modifications qui surveille l'intégralité d'une base de données ne considère pas la suppression d'une table comme une modification de données et ne l'enregistre pas, même si cette action supprime toutes les données de cette table de la base de données.

Comment Spanner écrit et stocke les flux de modifications

Chaque fois que Spanner détecte une modification de données dans une colonne surveillée par un flux de modifications, il écrit un enregistrement de modification de données dans son stockage interne. L'écriture de la modification de données et l'enregistrement de la modification de données sont écrits dans la même transaction. Spanner colocalise ces deux écritures afin qu'elles soient traitées par le même serveur, ce qui réduit le traitement des écritures. La transaction est ensuite répliquée dans les instances dupliquées de la base de données, ce qui entraîne des coûts de stockage et de réplication. Pour en savoir plus, consultez la page Tarifs de Spanner.

Contenu d'un enregistrement de modification des données

Chaque enregistrement de modification de données écrit par un flux de modifications inclut les informations suivantes sur la modification de données:

  • Nom de la table concernée

  • Noms, valeurs et types de données des clés primaires identifiant la ligne modifiée

  • Noms et types de données des colonnes de la ligne modifiée qui ont été capturés en fonction de la définition du flux de modifications.

  • Les anciennes valeurs des colonnes de la ligne. La disponibilité des anciennes valeurs et du contenu qu'elles suivent, qui peut être uniquement les colonnes modifiées ou l'ensemble de la ligne suivie, dépend du type de capture de valeur configuré par l'utilisateur.

  • Nouvelles valeurs des colonnes de la ligne. La disponibilité des nouvelles valeurs et du contenu qu'elles suivent dépend du type de capture de valeur configuré par l'utilisateur.

  • Type de modification (insertion, mise à jour ou suppression)

  • Code temporel du commit

  • ID de la transaction

  • Numéro de séquence de l'enregistrement

  • Type de capture de valeur de l'enregistrement de modification de données.

Pour en savoir plus sur la structure des enregistrements de modification des données, consultez Enregistrements de modification des données.

Conservation des données

Un flux de modifications conserve ses enregistrements de modification de données pendant une période comprise entre un et sept jours. Vous pouvez utiliser le langage DDL pour spécifier une limite de conservation des données autre que la valeur par défaut d'un jour lors de la création initiale d'un flux de modifications, ou l'ajuster à tout moment par la suite. Notez que réduire la limite de conservation des données d'un flux de modifications rend toutes les données historiques de modification antérieures à la nouvelle limite immédiatement et définitivement indisponibles pour les lecteurs de ce flux de modifications.

Cette période de conservation des données présente un compromis : une période de conservation plus longue entraîne des demandes de stockage plus importantes sur la base de données du flux.

Type de capture de valeur

L'option de configuration Type de capture de valeur d'un flux de modifications contrôle la manière dont il stocke les valeurs d'une ligne modifiée. Vous pouvez utiliser le langage de définition de données pour spécifier l'un des types de capture de valeur suivants pour un flux de modifications:

  • OLD_AND_NEW_VALUES: capture les anciennes et les nouvelles valeurs des colonnes modifiées d'une ligne.

  • NEW_VALUES: ne capture que les nouvelles valeurs des colonnes autres que les clés, mais aucune ancienne valeur.

  • NEW_ROW: capture toutes les nouvelles valeurs des colonnes surveillées, modifiées et non modifiées, chaque fois qu'une de ces colonnes change. Aucune ancienne valeur n'est capturée.

  • NEW_ROW_AND_OLD_VALUES: capture toutes les nouvelles valeurs pour les colonnes modifiées et non modifiées, ainsi que les anciennes valeurs pour les colonnes modifiées.

Exclure les suppressions basées sur le temps de vie

Dans Spanner, la valeur TTL (Time To Live) vous permet de définir des règles visant à supprimer régulièrement des données des tables Spanner. Par défaut, les flux de modifications incluent toutes les suppressions basées sur le TTL. Vous pouvez utiliser exclude_ttl_deletes pour définir votre flux de modifications afin d'exclure les suppressions basées sur le TTL. Lorsque vous définissez ce filtre pour exclure les suppressions basées sur le TTL, seules les suppressions futures basées sur le TTL sont exclues de votre flux de modifications.

La valeur par défaut de ce filtre est false. Pour exclure les suppressions basées sur le TTL, définissez le filtre sur true. Vous pouvez ajouter le filtre lorsque vous créez un flux de modifications ou modifier un flux de modifications existant pour inclure le filtre.

Type de modification de la table

Par défaut, les flux de modifications incluent toutes les modifications de table, telles que les insertions, les mises à jour et les suppressions. Vous pouvez filtrer une ou plusieurs de ces modifications de table à partir du champ d'application de votre flux de modifications à l'aide des options de filtrage disponibles suivantes:

  • exclude_insert: excluez toutes les modifications de la table INSERT.
  • exclude_update: excluez toutes les modifications de la table UPDATE.
  • exclude_delete: excluez toutes les modifications de la table DELETE.

La valeur par défaut de ces filtres est false. Pour exclure un type spécifique de modification de table, définissez le filtre sur true. Vous pouvez définir un ou plusieurs filtres en même temps.

Vous pouvez ajouter un filtre pour un type de modification de table lorsque vous créez un flux de modifications ou modifier le filtre pour un type de modification de table pour un flux de modifications existant.

Exclusion des enregistrements au niveau de la transaction

Par défaut, un flux de modifications surveille toutes les transactions d'écriture dans la base de données, car l'option DDL allow_txn_exclusion est définie sur false. Vous pouvez définir l'option allow_txn_exclusion sur true pour permettre à votre flux de modifications d'ignorer les enregistrements des transactions d'écriture spécifiées. Si vous ne définissez pas cette option sur true, toutes les transactions d'écriture sont surveillées, même si vous utilisez le paramètre exclude_txn_from_change_streams dans votre transaction d'écriture.

Vous pouvez activer cette option lorsque vous créez un flux de modifications ou modifier un flux de modifications existant.

Exclure les transactions d'écriture des flux de modifications

Pour exclure une transaction d'écriture des flux de modifications, vous devez définir le paramètre exclude_txn_from_change_streams sur true. Ce paramètre fait partie des méthodes TransactionOptions et BatchWriteRequest. La valeur par défaut pour ce paramètre est false. Vous pouvez définir ce paramètre avec l'API RPC, l'API REST ou à l'aide des bibliothèques clientes. Pour en savoir plus, consultez Spécifier une transaction d'écriture à exclure des flux de modifications.

Vous ne pouvez pas définir ce paramètre sur true pour les transactions en lecture seule. Dans ce cas, l'API renvoie une erreur d'argument non valide.

Pour les colonnes de surveillance des flux de modifications modifiées par des transactions, lorsque exclude_txn_from_change_streams est défini sur true, deux scénarios sont possibles:

  • Si l'option DDL allow_txn_exclusion est définie sur true, les mises à jour effectuées dans cette transaction ne sont pas enregistrées dans le flux de modifications.
  • Si vous ne définissez pas l'option DDL allow_txn_exclusion ou si elle est définie sur false, les mises à jour effectuées dans cette transaction sont enregistrées dans le flux de modifications.

Si vous ne définissez pas l'option exclude_txn_from_change_streams ou si elle est définie sur false, toutes les colonnes de surveillance des flux de modifications modifiées par les transactions captureront les mises à jour effectuées dans cette transaction.

Lire les flux de modifications

Spanner propose plusieurs méthodes pour lire les données d'un flux de modifications:

  • Via Dataflow, à l'aide du connecteur SpannerIO Apache Beam. Il s'agit de la solution recommandée pour la plupart des applications de flux de modifications. Google fournit également des modèles Dataflow pour les cas d'utilisation courants.

  • Directement, à l'aide de l'API Spanner. Cela remplace l'abstraction et les fonctionnalités des pipelines Dataflow par une vitesse et une flexibilité maximales.

  • En utilisant le connecteur Kafka basé sur Debezium pour les flux de modification Spanner. Ce connecteur diffuse les enregistrements de modification directement dans des sujets Kafka.

Vous pouvez fournir une isolation partielle pour les lectures de flux de modifications à l'aide de lectures dirigées. Les lectures dirigées peuvent contribuer à minimiser l'impact sur les charges de travail transactionnelles dans votre base de données. Vous pouvez utiliser l'API Spanner pour acheminer les lectures des flux de modifications vers un type de réplica ou une région spécifique dans une configuration d'instance multirégionale ou une configuration régionale personnalisée avec une ou plusieurs régions en lecture seule facultatives. Pour en savoir plus, consultez la section Lectures dirigées.

Utiliser Dataflow

Utilisez le connecteur Apache Beam SpannerIO pour créer des pipelines Dataflow qui lisent à partir de flux de modifications. Une fois que vous avez configuré le connecteur avec des informations sur un flux de modifications particulier, il génère automatiquement de nouveaux enregistrements de modification de données dans un ensemble de données PCollection unique et illimité, prêt à être traité par les transformations ultérieures dans le pipeline Dataflow.

Dataflow utilise des fonctions de fenêtrage pour diviser les collections illimitées en composants logiques ou fenêtres. Par conséquent, Dataflow fournit un flux en temps quasi réel lors de la lecture à partir de flux de modifications.

Google fournit des modèles qui vous permettent de créer rapidement des pipelines Dataflow pour les cas d'utilisation courants des flux de modifications, y compris l'envoi de toutes les modifications de données d'un flux à un ensemble de données BigQuery ou leur copie dans un bucket Cloud Storage.

Pour en savoir plus sur l'interaction entre les flux de modifications et Dataflow, consultez Créer des connexions de flux de modifications avec Dataflow.

Utiliser l'API

Au lieu d'utiliser Dataflow pour créer des pipelines de flux de modifications, vous pouvez écrire du code qui utilise l'API Spanner pour lire directement les enregistrements d'un flux de modifications. Vous pouvez ainsi lire les enregistrements de modification des données de la même manière que le connecteur SpannerIO, en fournissant les latences les plus faibles possibles lors de la lecture des données de flux de modifications au lieu de fournir la flexibilité de Dataflow.

Pour en savoir plus, consultez Interroger des flux de modifications. Pour en savoir plus sur la façon d'interroger les flux de modifications et d'interpréter les enregistrements renvoyés, consultez la section Modifier les partitions, les enregistrements et les requêtes de flux.

Utiliser le connecteur Kafka

Le connecteur Kafka génère directement les enregistrements du flux de modifications dans un sujet Kafka. Il masque les détails de la requête des flux de modifications à l'aide de l'API Spanner.

Pour en savoir plus sur l'interaction entre les flux de modifications et le connecteur Kafka, consultez Créer des connexions de flux de modifications avec le connecteur Kafka.

Limites

Les flux de modifications sont soumis à plusieurs limites, y compris le nombre maximal de flux de modifications qu'une base de données peut avoir et le nombre maximal de flux pouvant surveiller une seule colonne. Pour obtenir la liste complète, consultez la section Limites des flux de modifications.

Autorisations

Les flux de modifications utilisent les éléments suivants:

  • La création, la mise à jour ou la suppression de flux de modifications nécessite spanner.databases.updateDdl.

  • La lecture des données d'un flux de modifications nécessite spanner.databases.select.

Si vous utilisez le connecteur SpannerIO, le propriétaire de la tâche Dataflow qui lit les données de flux de modifications a besoin d'autorisations IAM supplémentaires, soit sur votre base de données d'application, soit sur une base de données de métadonnées distincte. Consultez Créer une base de données de métadonnées.

Étape suivante