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 présente un aperçu général des flux de modifications Spanner : leur fonctionnement et leur utilité. Pour découvrir comment créer et gérer des flux de modifications dans votre base de données et les connecter à d'autres services, suivez les liens de la section Étape suivante.

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éclencher une 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.

Configuration des 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 d'autres objets de schéma gérés par 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 comporter plusieurs flux de modifications, et une table ou une colonne particulière peut être surveillée par plusieurs flux, dans certaines limites.

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

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

Surveillance implicite des tables et des 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 qu'il soit nécessaire de modifier la configuration de ce flux de modifications. De même, le flux de modifications cesse automatiquement de surveiller les colonnes qui sont supprimées de cette table.

Les flux de modifications de l'ensemble de la base de données fonctionnent de la même manière. Ils surveillent implicitement chaque colonne de chaque table, surveillent automatiquement toutes 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.

Surveillance explicite des tables et des colonnes

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

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ées par les flux de modifications

Les modifications de données surveillées par un flux de modifications incluent toutes les insertions, mises à jour et suppressions effectuées dans les tables et les colonnes qu'il surveille. Ces modifications peuvent provenir des éléments suivants :

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, les 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 résultent directement des modifications de schéma, autres que les remplissages pour les valeurs par défaut. Par exemple, un flux de modifications qui surveille une base de données entière ne considère pas et n'enregistre pas la suppression d'une table comme une modification de données, 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 espace de stockage interne. L'écriture de la modification de données et l'enregistrement de 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 minimise le traitement des écritures. La transaction est ensuite répliquée sur 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 de 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 affecté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ées en fonction de la définition du flux de modifications.

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

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

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

  • Horodatage de 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 de données, consultez la section Enregistrements de modification de 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 trente jours. Vous pouvez utiliser LDD pour spécifier une limite de conservation des données autre que la valeur par défaut de sept jours lors de la création initiale d'un flux de modifications, ou l'ajuster à tout moment ultérieur. Notez que la réduction de la limite de conservation des données d'un flux de modifications rendra immédiatement et définitivement indisponibles pour les lecteurs de ce flux de modifications toutes les données de modification historiques antérieures à la nouvelle limite.

Cette période de conservation des données présente un compromis : une période de conservation plus longue entraîne des exigences 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 façon dont il stocke les valeurs d'une ligne modifiée. Vous pouvez utiliser LDD pour spécifier l'un des types de capture de valeur suivants pour un flux de modifications :

  • OLD_AND_NEW_VALUES: ce type de capture enregistre à la fois les anciennes et les nouvelles valeurs des colonnes modifiées d'une ligne.

  • NEW_VALUES: ce type de capture enregistre uniquement les nouvelles valeurs des colonnes non clés, mais pas les anciennes valeurs.

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

  • NEW_ROW_AND_OLD_VALUES: ce type de capture enregistre toutes les nouvelles valeurs des colonnes modifiées et non modifiées, ainsi que les anciennes valeurs des colonnes modifiées.

Exclure les suppressions basées sur la durée de vie

Dans Spanner, la valeur TTL (Time To Live) vous permet de définir des règles pour supprimer régulièrement des données des tables Spanner. Par défaut, les flux de modifications incluent toutes les suppressions basées sur la TTL. Vous pouvez utiliser exclude_ttl_deletes pour définir votre flux de modifications afin d'exclure les suppressions basées sur la TTL. Lorsque vous définissez ce filtre pour exclure les suppressions basées sur la TTL, seules les futures suppressions basées sur la 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 la TTL, définissez le filtre sur true. Vous pouvez soit ajouter le filtre lorsque vous créez un flux de modifications soit modifier un flux de modifications existant pour inclure le filtre.

Type de modification de 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 : exclure toutes les modifications de table INSERT
  • exclude_update : exclure toutes les modifications de table UPDATE
  • exclude_delete : exclure toutes les modifications de 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 LDD 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 soit activer cette option lorsque vous créez un flux de modifications soit modifier un flux de modifications existant.

Exclure une transaction 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 TransactionOptions et BatchWriteRequest méthodes. La valeur par défaut de 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 la section 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. Si vous le faites, l'API renvoie une erreur d'argument non valide.

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

  • Si l'option LDD 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 LDD 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, tous les flux de modifications qui surveillent les colonnes modifiées par les transactions capturent les mises à jour effectuées dans cette transaction.

Lire des flux de modifications

Spanner propose plusieurs façons de lire les données d'un flux de modifications :

  • Via Dataflow, à l'aide du connecteur Apache Beam SpannerIO. 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 permet de bénéficier d'une vitesse et d'une flexibilité maximales, mais au détriment de l'abstraction et des fonctionnalités des pipelines Dataflow.

  • À l'aide du connecteur Kafka basé sur Debezium pour les flux de modifications Spanner. Ce connecteur diffuse les enregistrements de modifications directement dans les sujets Kafka.

  • À l'aide de Datastream pour diffuser directement vos modifications vers BigQuery, les tables BigLake Iceberg ou Cloud Storage.

Vous pouvez fournir une isolation partielle pour les lectures de flux de modifications à l'aide de lectures dirigées. Les lectures dirigées peuvent aider à minimiser l'impact sur les charges de travail transactionnelles de votre base de données. Vous pouvez utiliser l'API Spanner pour acheminer les lectures de flux de modifications vers un type d'instance dupliquée 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.

Utilisation de Dataflow

Utilisez le connecteur Apache Beam SpannerIO pour créer des pipelines Dataflow qui lisent les 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 unique et illimité PCollection , prêt à être traité par les transformations suivantes 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 streaming 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 vers un ensemble de données BigQuery ou leur copie dans un bucket Cloud Storage.

Pour obtenir une présentation plus détaillée du fonctionnement conjoint des flux de modifications et de Dataflow, consultez la section Créer des connexions de flux de modification 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. Cela vous permet de lire les enregistrements de modification de 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 la section Interroger des flux de modifications. Pour une discussion plus détaillée 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 de flux de modifications dans un sujet Kafka. Il abstrait les détails de l'interrogation des flux de modifications à l'aide de l'API Spanner.

Pour en savoir plus sur le fonctionnement conjoint des flux de modifications et du connecteur Kafka, consultez la section Créer des connexions de flux de modification avec le connecteur Kafka.

Utiliser Datastream

Utilisez Datastream, un service de capture des données modifiées (CDC) et de réplication facile à utiliser et sans serveur disponible dans Google Cloud. Datastream est compatible avec les flux de modifications Spanner et vous permet de lire et de diffuser vos données de modification vers différentes destinations.

Pour en savoir plus sur la façon dont Datastream est compatible avec Spanner pour la lecture et la diffusion de données de modification, consultez la section Spanner en tant que source.

Limites

Il existe plusieurs limites concernant les flux de modifications, y compris le nombre maximal de flux de modifications qu'une base de données peut comporter 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écessitent 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 du job Dataflow qui lit les données de flux de modifications nécessite des autorisations Identity and Access Management (IAM) supplémentaires, soit sur la base de données de votre application, soit sur une base de données de métadonnées distincte. Consultez la section Créer une base de données de métadonnées.

Étape suivante