À propos des flux de modifications

Un flux de modifications surveille et diffuse en temps réel les modifications apportées aux données (insertions, mises à jour et suppressions) de Cloud Spanner.

Cette page offre une vue d'ensemble des flux de modifications Spanner: leur rôle et leur fonctionnement. Pour savoir comment créer et gérer des flux de modifications dans votre base de données et les connecter à d'autres services, consultez les liens de la section Étape suivante.

Objectif des flux de changements

Les flux de modification offrent un moyen flexible et évolutif de diffuser les modifications de données dans 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 pour l'analyse

  • Déclencher une logique d'application en fonction des modifications de données envoyées à une file d'attente de messages, comme Pub/Sub

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

Modifier la configuration du flux

Vous pouvez ajouter des flux de modification à n'importe quelle base de données de dialecte SQL standard Google.

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

Vous pouvez configurer un flux de modifications pour surveiller les modifications des données dans toute une base de données, ou limiter sa portée à des tables et des colonnes spécifiques. Une base de données peut comporter plusieurs flux de modification, et une table ou une colonne spécifique peut être associée à plusieurs flux qui la regardent, dans des limites.

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

Surveiller implicitement des tables et des colonnes

Les flux qui surveillent une table entière regardent implicitement toutes les colonnes de cette table, même lorsque cette définition est mise à jour. Par exemple, lorsque vous ajoutez des colonnes à cette table, le flux de modifications commence automatiquement à surveiller ces nouvelles colonnes, sans qu'aucune modification ne soit nécessaire sur cette configuration de flux. De même, le flux de modifications cesse automatiquement de surveiller les colonnes supprimées de cette table.

Le fonctionnement des flux de modifications dans l'intégralité de la base de données fonctionne de la même manière. Ils surveillent implicitement toutes les colonnes de chaque table, tout en suivant automatiquement les tables ou les colonnes ajoutées après la création du flux de modifications, et en arrêtant de surveiller les tables ou les colonnes supprimées.

Explication explicite des tables et colonnes

Si vous configurez un flux de modifications pour n'afficher que certaines colonnes d'une table et que vous ajoutez ultérieurement des colonnes à cette table, le flux de modifications ne surveillera pas ces colonnes tant que vous ne le reconfigurerez pas.

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 regardent 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 regarde explicitement.

Types de modifications des données modifiées par les flux

Les données surveillées par un flux de modifications incluent toutes les insertions, mises à jour et suppressions apportées aux tables et aux colonnes qu'il surveille. Ces modifications peuvent provenir de différentes situations:

Les flux de modification ne peuvent surveiller les modifications de données que dans les colonnes et les tables créées par l'utilisateur. Elles ne surveillent pas les colonnes générées, les index, les vues, les autres flux de modifications ni les tables système telles que les schémas d'informations ou les statistiques.

De plus, les flux de modifications ne surveillent pas les modifications de schéma ni les modifications de données résultant directement des modifications de schéma. Par exemple, un flux de modification regardant une base de données entière ne traitera pas la suppression d'une table comme une modification des 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 des données dans une colonne surveillée par un flux de modifications, il enregistre dans sa mémoire de stockage interne. Il le fait de manière synchrone avec cette modification des données, dans la même transaction. Spanner colocalise ces deux écritures pour qu'elles soient traitées par le même serveur, ce qui réduit le traitement en écriture.

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:

  • 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 modifiées de la ligne

  • Anciennes valeurs des colonnes modifiées de la ligne (pour la mise à jour et la suppression)

  • Nouvelles valeurs des colonnes modifiées de la ligne (pour les mises à jour et les insertions)

  • Type de modification (insérer, mettre à jour ou supprimer)

  • Horodatage du commit

  • L'ID de transaction

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

  • Type de capture de valeur de l'enregistrement de modification des données, toujours OLD_AND_NEW_VALUES

Pour voir toutes les valeurs d'une ligne au moment où une modification a eu lieu, effectuez une lecture obsolète de cette ligne, en fonction de l'horodatage du commit de l'enregistrement des modifications. La modification du modèle Dataflow vers BigQuery fournit un exemple d'inclusion de ce comportement dans un pipeline de traitement des données.

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

Conservation des données

Un flux de modification conserve ses enregistrements de modification de données pendant une période comprise entre un et sept jours. Vous pouvez utiliser l'instruction LDD pour spécifier une limite de conservation des données autre que celle par défaut lors de la création initiale d'un flux de modifications, ou pour l'ajuster à tout moment. Notez que si vous réduisez la limite de conservation des données d'un flux de modifications, toutes les données de l'historique des modifications dépassant la nouvelle limite seront immédiatement et définitivement indisponibles pour les lecteurs de ce flux.

Cette durée de conservation représente un compromis. En effet, plus cette durée est importante, plus la charge de stockage est importante dans la base de données du flux.

Lire les flux de modifications

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

  • Via Dataflow, à l'aide du connecteur Apache Beam Spanner. Cette solution est 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 ; Ainsi, l'abstraction et les fonctionnalités des pipelines Dataflow offrent une vitesse et une flexibilité maximales.

Utiliser Dataflow

Utilisez le connecteur Apache Beam Spanner IO pour créer des pipelines Dataflow qui lisent les flux de modifications. Une fois que vous avez configuré le connecteur avec les détails d'un flux de modification particulier, il génère automatiquement de nouveaux enregistrements de modifications dans un seul ensemble de données PCollection illimité, prêt pour un traitement supplémentaire par les transformations suivantes dans le pipeline Dataflow.

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

Pour en savoir plus sur la façon dont les flux de modifications et Dataflow fonctionnent ensemble, 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 les enregistrements d'un flux de modifications directement. Cela vous permet de lire les enregistrements de modification de données de la même manière que le connecteur Spanner, en échangeant l'abstraction qu'il fournit en échange des latences les plus basses possibles lors de la lecture des données de flux de modification.

Pour en savoir plus, consultez la section Flux de modification de requête. Pour en savoir plus sur l'interrogation des flux de modification et l'interprétation des enregistrements renvoyés, consultez la page Modifier les partitions, enregistrements et requêtes d'un flux.

Limites

Il existe plusieurs limites concernant les flux de modifications, y compris le nombre maximal de flux de modification 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 Modifier les limites de flux.

Autorisations

Les flux de modification utilisent quelques autorisations IAM standards de Spanner :

  • Pour créer, mettre à jour ou supprimer des flux de modifications, vous devez utiliser spanner.databases.updateDdl.

  • Pour lire les données d'un flux de modification, vous devez utiliser le 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 nécessite des autorisations IAM supplémentaires, que ce soit sur votre base de données d'application ou 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.

Bonnes pratiques

Analysez les nouveaux flux de modifications et redimensionnez-les si nécessaire

Avant d'ajouter des flux de modification à votre instance de production, envisagez d'appliquer une charge de travail réaliste à une instance de préproduction, avec les flux de modifications activés. Cela vous permet de déterminer si vous devez ajouter des nœuds à votre instance pour augmenter ses capacités de calcul et de stockage.

Exécutez ces tests jusqu'à ce que les métriques de processeur et de stockage se stabilisent. Idéalement, l'utilisation du processeur de l'instance devrait rester inférieure à 90%, et l'utilisation de son stockage ne devrait pas dépasser la limite de stockage de l'instance.

Utiliser différentes régions pour équilibrer les charges

Lorsque vous utilisez des flux de modification dans une instance multirégionale, envisagez d'exécuter leurs pipelines de traitement dans une région différente de celle de la région principale par défaut. Cela permet de répartir la charge de streaming entre des instances dupliquées non principales. Si vous devez privilégier le délai de streaming le plus faible possible plutôt que l'équilibrage de charge, exécutez la charge de streaming dans la région principale.

Étapes suivantes