Présentation des flux de modifications

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

Cette page présente les 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 associer à d'autres services, suivez les liens de la section Étapes suivantes.

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 apportées aux 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

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 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 spécifique peut être surveillée par plusieurs flux, dans les limites autorisées.

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

L'exécution du LDD qui crée un flux de modifications lance une opération de longue durée. Une fois cette 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 des colonnes à cette table, le flux de modifications commence automatiquement à les surveiller, sans nécessiter de modification de la configuration de ce flux. De même, le flux de modifications cesse automatiquement de surveiller les colonnes supprimées de cette table.

Les flux de modifications de base de données entières 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.

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 ensuite des colonnes à cette table, le flux de modifications ne commencera pas à surveiller ces colonnes, sauf si vous le reconfigurez pour qu'il le fasse.

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 qu'un flux de modifications surveille incluent toutes les insertions, mises à jour et suppressions apportées aux tables et aux 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 elles font 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, à l'exception des 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 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 espace de stockage interne. L'écriture de la modification des données et l'enregistrement de la modification des données sont effectués 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 dans les réplicas 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.

  • Anciennes valeurs des colonnes de la ligne. La disponibilité des anciennes valeurs et du contenu qu'elles suivent (colonnes modifiées uniquement ou ligne suivie entière) 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 des 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 modifications de données pendant une période comprise entre un et trente jours. Vous pouvez utiliser le langage LDD pour spécifier une limite de conservation des données autre que la limite par défaut d'un jour lorsque vous créez un flux de modifications, ou l'ajuster à tout moment par la suite. 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 toutes les données de modifications 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 besoins de stockage plus importants dans 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 modification contrôle la façon dont les valeurs d'une ligne modifiée sont stockées. Vous pouvez utiliser le LDD pour spécifier l'un des types de capture de valeur suivants pour un flux de modifications :

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

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

  • NEW_ROW : capture toutes les nouvelles valeurs des colonnes observées, qu'elles aient été modifiées ou non, chaque fois que l'une de ces colonnes change. Les anciennes valeurs ne sont pas enregistrées.

  • 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 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 le TTL. Vous pouvez utiliser exclude_ttl_deletes pour configurer 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 futures suppressions 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 la 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 apportées aux tables, 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 tableau, définissez le filtre sur true. Vous pouvez définir un ou plusieurs filtres à la fois.

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 des transactions

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 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 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 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 colonnes de surveillance des flux de modifications 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, toutes les colonnes de surveillance des flux de modifications modifiées par les transactions capturent 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 Apache Beam SpannerIO. Il s'agit de la solution que nous recommandons 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 renoncer à l'abstraction et aux capacités des pipelines Dataflow pour une vitesse et une flexibilité maximales.

  • En utilisant le connecteur Kafka basé sur Debezium pour les flux de modifications Spanner. Ce connecteur diffuse les enregistrements de modifications directement dans les 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 aider à 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écifiques 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 Lectures dirigées.

Utiliser 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 spécifique, il génère automatiquement de nouveaux enregistrements de modifications de données dans un seul ensemble de données PCollection illimité, 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 quasi en temps 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 vers un bucket Cloud Storage.

Pour obtenir une présentation plus détaillée de la façon dont les flux de modifications et Dataflow fonctionnent ensemble, 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 modification, vous pouvez écrire du code qui utilise l'API Spanner pour lire directement les enregistrements d'un flux de modification. Cela vous permet de 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 du flux de modifications au lieu de fournir la flexibilité de Dataflow.

Pour en savoir plus, consultez Interroger les 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 Partitions, enregistrements et requêtes des flux de modifications.

Utiliser le connecteur Kafka

Le connecteur Kafka génère directement des 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 combiné des flux de modifications et du connecteur Kafka, consultez Créer des connexions de flux de modifications avec le connecteur Kafka.

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 même colonne. Pour obtenir la liste complète, consultez 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 du 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. Pour en savoir plus, consultez Créer une base de données de métadonnées.

Étapes suivantes