Le guide de capture des données modifiées (CDC) pour PostgreSQL

Cet article sert de guide complet pour modifier la capture de données (CDC) dans PostgreSQL, également connu sous le nom de Postgres. Il vous présentera les différentes manières de mettre en œuvre Postgres CDC, y compris les avantages et les inconvénients, ainsi qu'une alternative automatisée à toutes les méthodes manuelles. 

Il abordera également l'importance de PostgreSQL CDC. Avant de commencer, clarifions quelques notions de base. 

Qu'est-ce que PostgreSQL ? 

PostgreSQL est un open-source base de données relationnelle système de gestion (SGBDR). Sa polyvalence permet son utilisation à la fois comme base de données et comme entrepôt de données en cas de besoin. 

PostgreSQL est également entièrement gratuit et ses utilisateurs bénéficient systématiquement d'un développement open source étendu et d'un support fiable. Ce sont quelques-unes des principales raisons de sa longévité impressionnante : PostgreSQL existe depuis plus de deux décennies et continue de se classer parmi les bases de données relationnelles les plus utilisées. pour la gestion des données dès aujourd’hui. 

Fonctionnalités et applications de PostgreSQL 

• En plus d'être gratuit, PostgreSQL a également acquis une excellente réputation pour son adaptabilité et son extensibilité. Il s'intègre parfaitement à vos systèmes existants et adhère aux normes SQL, vous savez donc à quoi vous attendre.
  
• Avec la prise en charge intégrée de la capture des données modifiées, Postgres fournit un mécanisme robuste pour suivre et capturer les modifications apportées à la base de données.
• Il est Conforme à l'ACID, hautement sécurisé et gère efficacement les erreurs de traitement, vous pouvez donc compter sur la validité des données.
  
• Il prend en charge les requêtes JSON et SQL.
  
• En tant que base de données relationnelle, PostgreSQL stocke les éléments de données sous forme de tables où les lignes sont également appelées tuples, et chaque tuple est identifié par une clé unique. Les colonnes stockent les attributs de chaque élément de données correspondant. 

Ces fonctionnalités font de PostgreSQL le bon choix pour de nombreuses applications, quelques dont comprennent : 

• Base de données transactionnelle: Lorsque vous avez fréquemment besoin d'un accès rapide aux informations à utiliser dans un produit ou une application, PostgreSQL est le bon choix de base de données car sa structure relationnelle récupère les données pertinentes à grande vitesse.
• Entreposage de données: Une base de données fonctionne bien pour les opérations de données transactionnelles mais pas pour l'analyse, et l'inverse est vrai pour un entrepôt de données. Les deux se complètent afin que vous puissiez influence vos données plus facilement. La compatibilité de PostgreSQL avec les outils de Business Intelligence en fait un outil pratique option pour répondre à vos besoins en matière d'exploration de données, d'analyse et de BI.
• Services basés sur la localisation: Le PostGIS extension, vous pouvez utilisez PostgreSQL pour stocker, indexer et interroger des données géospatiales selon vos besoins. Cela fait un choix intelligent pour les services géolocalisés et les systèmes d'information géographique (SIG).
• Transactions OLTP: PostgreSQL est couramment utilisé pour les transactions de traitement des transactions en ligne (OLTP) dans de nombreux secteurs, notamment e-commerce (achats en ligne et mise à jour des stocks), banque (virements de fonds, retraits aux distributeurs automatiques), et contrôles de solde), ventes (transactions de détail, génération de factures et points de fidélité), et les services (prise de rendez-vous, mises à jour des services, ainsi que le Paiements pour les prestations rendu). 

Constat As-tu besoin Postgres CDC? 

Supposons que vous ayez besoin des données les plus récentes à des fins de reporting. maintenant, sauf que vous ne pouvez pas l'avoir pour l'instant puisque la prochaine synchronisation est prévue pour heures à partir de maintenant. La synchronisation manuelle est une option, mais si vous êtes une grande entreprise traitant de vastes volumes de données, le traitement par lots peut rapidement devenir un obstacle. Cela peut conduire à des erreurs, à l’utilisation d’informations obsolètes et à des rapports incorrects.

En fin de compte, votre prise de décision sera affectée car vous ne disposerez pas des données mises à jour dont vous avez besoin pour prendre les mesures nécessaires. 

C'est exactement le genre de scénario que vous pouvez éviter avec Postgres CDC. 

Postgres Les méthodes CDC vous aident à suivre et à gérer les modifications apportées à vos bases de données. L'action la plus courante dans de tels cas est la réplication des modifications apportées à la source vers un magasin de données de destination. Ce vous permet de garder vos données synchronisées entre plusieurs bases de données. 

Comment Fonctionnement du CDC PostgreSQL et que fait-il ? 

Postgres CDC garantit que tous les systèmes disposent d'un accès cohérent à la version la plus récente de vos données. vous êtes travaillant toujours avec des informations à jour. Postgres ccapture de données suspendues a aussi quelques supplémentaire avantages, tels que: 

• Postgres CDC peut vous aider à réduire Un flux efficace peut augmenter les coûts d'utilisation du réseau puisque seules les dernières modifications seront traitées lors de chaque synchronisation au lieu de l'ensemble de données dans son intégralité.
• Aanalytique et tâches similaires nécessitent plus de ressources éxécuter, donc des impacts fréquents sur les traitements par lots les performances de la base de données Postgres au fil du temps et perturbe ses fonctionnalités. Postgres CDC effectue initialement des copies de la base de données, puis les met à jour progressivement avec les données modifiées. Ce le processus est beaucoup plus léger que le traitement par lots, gardant votre base de données plus rapide et plus efficace.
• Votre Gestion des données de référence (MDM) Le système fonctionner plus facilement avec Postgres CDC en effet. Avec des données modifiées provenant de sources disparates continuellement mises à jour dans le système MDM, toutes vos équipes pourront utilisé les mêmes données mises à jour. Cela peut améliorer la collaboration et la coordination et accélérer de meilleures décisions commerciales.
• Vous pouvez même utiliser modifier la capture des données avec Postgres comme mécanisme de reprise après sinistre pour vos données. CDC en temps réel vous aide à sauvegarder les bases de données critiques et à créer des redondances qui peuvent être utiles dans cas de panne du système, d’attaques de logiciels malveillants, d’erreurs humaines et d’autres situations similaires.    

Meméthodes à mettre en œuvre PostgreSQL CCHANGEMENT Data Capture 

Comme indiqué ci-dessus, Postgres CDC suivra et répliquera toutes les modifications de données sur plusieurs bases de données. La méthode CDC de votre choix peut être soit par lots, soit en temps réel puisque CDC ne collecte avoir des exigences liées au temps.  

Vous pouvez implémenter Postgres CDC en quelques joursdistinct moyens en fonction de vos besoins opérationnels, et nous allons regardez-les de plus près ci-dessous : 

Tgréeurs 

Postgres CDC basé sur des déclencheurs est également connu sous le nom de « sourcing d'événements ». » Dans cette méthode, un journal des événements dédié est créé pour servir de principale source d'informations. Comme son nom l'indique, cette méthode s'appuie fortement sur des déclencheurs, qui sont crucial dans chaque transaction de base de données et capturer les événements dans en temps réel. 

Un déclencheur programme la base de données pour qu'elle se comporte d'une manière particulière à chaque fois qu'un événement spécifié se produit. Cet événement peut être l'introduction de nouvelles données, la mise à jour de données existantes ou la suppression de données existantes de la base de données. 

Les déclencheurs Postgres CDC sont hautement personnalisables. Vous pouvez les configurer pour qu'ils s'exécutent avant ou après les événements mentionnés ci-dessus, pour qu'ils s'exécutent pour chaque modification individuelle ou pour qu'ils s'exécutent une fois pour un groupe de modifications. Vous pouvez même imposer des conditions de fonctionnement aux déclencheurs : les faire fonctionner uniquement lorsqu'un tuple spécifique est modifié ou exécuté uniquement en réponse à certaines actions. 

Les déclencheurs de Postgres CDC fonctionnent bien pour suivre les modifications dans les tables, les enregistrer dans une table différente et créer un journal de chaque modification. Pour implémenter Postgres basé sur des déclencheurs modifier la capture de données, vous pouvez créer des déclencheurs d'audit sur votre base de données Postgres qui suivront tous les événements liés à des actions telles que INSERT, UPDATE et DELETE. 

Puisque cette méthode exploite au niveau SQL, vous pouvez vous référer à la table Change Data Capture et identifier tous les changements. Voici un exemple de fonction déclencheur : 

Ce code créera une table nommée 'utilisateurs_cdc'pour stocker les informations de capture de données modifiées, capturer des informations telles que l'ID utilisateur, l'opérationtype d'ion (INSERT, UPDATE, DELETE), horodatage du changement et nom de l'utilisateur avant et après le changement d'information. 

Ce code définit un PL/pgSQL fonction ('capture_changes') déclenché après les opérations INSERT, UPDATE ou DELETE sur la table 'users'. Les 'CAS' déclaration détermine le type d'opération basé sur la valeur of  »TG_OP' (opération de déclenchement). 

Ce code crée un déclencheur nommé 'utilisateurs_trigger' sur la table 'users' qui se déclenchera après toute opération INSERT, UPDATE ou DELETE.

Au dessus CDC Postgres Par exemple, chaque fois qu'un changement se produit dans la table 'users', le déclencheur correspondant activera le 'capture_changes', qui enregistrera les modifications apportées au 'utilisateurs_CDC' tableau. La table CDC capturera le type d'opération, l'horodatage et les données pertinentes avant et après le changement.

Ensemble, ces éléments vous aideront à suivre toutes les modifications apportées au tableau d'origine au fil du temps. 

Avantages du CDC Postgres basé sur des déclencheurs 

• Postgres CDC basé sur des déclencheurs est fiable et complet.
• Capture de toutes les modificationss et la tenue des dossiers s'effectue dans le système SQL.
• La capture instantanée des modifications permet le traitement des événements en temps réel.
• Vous pouvez créer des déclencheurs pour différents types d'événements. 

Inconvénients du CDC Postgres basé sur des déclencheurs:

• Étant donné que tous les déclencheurs que vous créez s'exécutent sur votre base de données Postgres principale, ils peuvent ralentir la base de données. Comme toute autre opération, l'exécution Postgres CDC via Les déclencheurs nécessitent également des ressources et augmentent la pression sur la base de données.
• Minimiser l'impact sur les ressources de la base de données implique de créer une autre table reflétant la table principale et d'utiliser cette table secondaire pour l'implémentation du déclencheur. Cependant, vous devrez également créer un pipeline distinct pour refléter toutes les modifications apportées à toute destination située en dehors de l'instance Postgres applicable du déclencheur.

Requêtes 

CDC Postgres basé sur des requêtes a besoin plus d'effort manuel que en utilisant des déclencheurs. Vous devez activement interroger votre base de données Postgres pour identifier tout changement au lieu de s’appuyer sur des déclencheurs préconfigurés. Vous avez besoin d'une colonne d'horodatage dans votre tablee pour utiliser cette méthode personnalisée. Chaque fois qu'un enregistrement est ajouté ou modifié, la colonne d'horodatage sera mise à jour pour inclure la date et l'heure du changement. 

Toute requête que vous effectuez sur votre base de données Postgres utilisera cette colonne d'horodatage pour obtenir tous modifié Articles depuis votre dernière requête, puis affichez les modifications capturées.  

Vous pouvez également utiliser des scripts pour moniteur votre base de données Postgres pour les modifications et les enregistrer dans une base de données de destination, mais cela option est encore plus laborieux que la simple interrogation de la base de données. 

Continuant le Postgres modifier la capture de données exemple ci-dessus, Voici comment interroger une table « utilisateurs » : 

Cette requête récupère tous les enregistrements de the 'utilisateurs' tableau où le »dernière mise à jour» L'horodatage est supérieur au « 2024-01-01 ». Il est utilisé pour récupérer les enregistrements utilisateur qui ont été mis à jour depuis la date spécifiée.

Thce code créera la table 'utilisateurs_changes' avec des informations sur chaque modification, telles que le type d'opération (INSERT, UPDATE ou DELETE), son horodatage et les données pertinentes avant et après la modification.

Avantages du CDC Postgres basé sur des requêtes 

• C'est plus facile que de configurer Capture de données de modification Postgres via déclencheurs.
• Il donne vous avez plus de contrôle sur le processus CDC.
• Vous n'avez besoin d'aucun outil externe pour le CDC basé sur des requêtes. 

Inconvénients du CDC Postgres basé sur des requêtes

• Nécessite une approche plus proactive que la méthode basée sur le déclenchement « réglez-le et oubliez-le » Postgres CDC. Vous devrez interroger régulièrement la base de données pour garantir un suivi précis et ponctuel des modifications.
• La couche de requête est cruciale pour l'extraction de données dans cette méthode, ce qui peut imposer une charge supplémentaire à la base de données Postgres. 

PostgreSQL Réplication logique 

Postgres CDC avec réplication logique est également appelé décodage logique. Considérez-le comme une représentation en continu d'un journal à écriture anticipée (WAL). Depuis WAL capture et enregistre toutes les modifications de données dans la base de données Postgres, ces modifications sont considérées comme des flux de décodage logiques et sont classées comme un emplacement de réplication logique au niveau de la base de données. 

En d’autres termes, un emplacement de réplication n’est rien d’autre qu’un flux de modifications intervenant dans une base de données. Chaque base de données peut avoir plusieurs emplacements ou flux de modifications.  

Exécution PostgreSQL la réplication logique nécessite un plugin de décodage logique. Les versions 10 et ultérieures de Postgres comportent la valeur par défaut 'pgoutput' brancher. Il permet de traiter les modifications de la base de données Postgres sous forme de flux. Cependant, si vous utilisez une version antérieure à 10, vous devrez installer manuellement un plugin tel que 'décodeurs' ou 'wal2json'. 

Le 'pgoutput' Le plugin est utile pour répliquer des données entre deux ou plusieurs instances PostgreSQL. Pourtant, c'est peuvent être difficile pour transférer les données du flux de modifications Postgres vers un autre plateforme ou base de données. 

Si vous souhaitez déplacer les données du flux de modifications vers une plate-forme non Postgres, vous pouvez utiliser le 'wal2json'plugin pour transformer les données du flux de modification en JSON. Cela permettra à vos plateformes de destination de le lire au format JSON, ce qui est plus simple que de lire pgoutput sortie binaire. 

Outre un plugin, l'autre composant essentiel de CDC via la réplique logique PostgreSQLation est un modèle d'abonnement avec des éditeurs et des abonnés. Ce modèle d'abonnement permet à un ou plusieurs abonnés de s'abonner à une (ou plusieurs) publications à l'aide du nœud éditeur. Les abonnés extraient les données des publications et peuvent les republier pour les répliquer ou les reconfigurer davantage. 

Suivez les étapes ci-dessous à mettre en œuvre Postgres CDC avec réplication logique depuis une base de données source (nous utiliserons le 'utilisateurs' table des exemples précédents) vers une base de données de destination, que nous appellerons la 'utilisateurs_changes' tableau.

N'oubliez pas de remplacer les espaces réservés tels que 'source_db' ainsi que le 'utilisateur_réplication' avec les informations réelles de votre base de données. 

Tout d'abord, activez la représentation logique dans le fichier de configuration Postgres 'postgresql.conf'. Utilisez les paramètres ci-dessus et redémarrez Postgres une fois ces modifications apportées. 

Cette section créera une table nommée 'utilisateurs' et une publication intitulée 'mon_pub» pour le 'utilisateurs' tableau. Cette publication est à l'origine des modifications à répliquer. 

Cette section créera un tableau nommé »utilisateurs_changes» dans la base de données de destination pour stocker les modifications de la source.

Ce code sera établir l'abonnement 'mon_sub», qui se connectera à la base de données source et s'abonnera au »mon_sub» publication. 

Ce code définit une fonction déclencheur 'capture_changes' pour capturer les changements dans le 'utilisateurs' tableau. C'est moiinserts informations pertinentes dans le 'utilisateurs_changements' tableau en fonction du type d'opération (INSERT, UPDATE, DELETE). Cela crée également le déclencheur 'utilisateurs_trigger' pour exécuter cette fonction après chaque fichier de lignevel changement dans le 'utilisateurs' tableau. 

Il s'agit d'une instruction SQL permettant de surveiller les modifications apportées à l'emplacement de réplication logique nommé 'mon_sub' et les aller chercher. Remplacer 'mon_sub' avec le nom de votre abonnement spécifique. 

Avantages de Postgres CDC avec réplication logique : 

• Le CDC basé sur les journaux permet la capture des modifications des données en temps réel à l'aide d'un mécanisme piloté par les événements. Cela permet aux applications en aval d'accéder de manière cohérente aux données mises à jour à partir d'une base de données Postgres.
• Cette méthode CDC peut identifier toutes sortes d'événements de changement dans une base de données Postgres.
• Étant donné que cette méthode accède directement au système de fichiers, elle exerce moins de pression sur la base de données. 

Inconvénients de Postgres CDC avec réplication logique : 

• La réplication logique n'est pas disponible pour les versions de PostgreSQL antérieures à 9.4.
• Selon le cas d'utilisation, la logique complexe requise pour traiter ces événements et leur éventuelle conversion en instructions pour la base de données cible peut potentiellement affecter l'achèvement du projet. 

Postgres CDC utilisant le journal d'écriture anticipée (WAL) 

Postgres CDC basé sur des déclencheurs et des requêtes peut créer une latence et affecter les performances de votre base de données au fil du temps. Si, vous auriez plutôt influence Fonctionnalités intégrées de Postgres et réutilisez-les pour les processus CDC au lieu d'utiliser les techniques décrites ci-dessus, vous pouvez utiliser le WAL. 

Le WAL est un journal de transactions qui note toutes les modifications apportées à la base de données. Son objectif principal est la récupération et la garantie de l'intégrité des données, Faisant c'est utile pour le CDC basé sur les événements. Puisqu'il s'agit d'une fonctionnalité intégrée, vous travaillerez principalement avec les propres paramètres de la base de données Postgres pour la configurer pour CDC. 

Voici les étapes à suivre pour Mettre en oeuvre Chan Postgrescapturer des données à l'aide du journal des transactions: 

Tout d'abord, activez WAL dans votre configuration Postgres. Bien qu'il s'agisse généralement du paramètre par défaut, cochez la case 'postgresql.conf'fichier à confirmer. Postgres permet aux utilisateurs d'examiner le contenu du WAL. A titre d'exemple, nous utiliserons le 'pg_waldump' outil. RRemplacez l'espace réservé 'chemin_vers_wal_file>' avec le chemin réel de votre fichier WAL lorsque vous utilisez ce code.

Ensuite, qConsultez le contenu des WAL à l'aide de requêtes SQL. Le »pglogique' Le package d'extension inclut le 'pg_decode', qui est l'extension la plus fréquemment utilisée à cette fin.

• 'CREATE EXTENSION' créera et installera le 'pglogique' extension qui fournit des capacités de réplication logique pour Postgres.
• L'instruction SQL 'SELECT' crée un emplacement de réplication logique nommé 'mon_emplacement» en utilisant le 'pg_create_logical_representation_slot' fonction.
  
• »pgoutput' spécifie le plugin de sortie à utiliser pour changements de décodage et ici il est un plugin de sortie intégré pour la réplication logique.
• 'pg_logical_slot_peek_changes' est utilisé pour examiner les modifications capturées dans un emplacement de réplication logique
• »mon_emplacement' est l'emplacement de réplication logique interrogé. Ce nom est un espace réservé et vous devez le remplacer par le nom de l'emplacement réel que vous souhaitez interroger.
• »NULL NULL' est l'endroit où vous pouvez placer les paramètres spécifiant la plage de modifications à récupérer. En utilisant 'NULL NULL' signifie ici récupérer toutes les modifications disponibles sans plage spécifique. 

Notez que vous devrez peut-être effectuer du codage, en particulier si vous êtes planifier l’automatisation de l’extraction et de la gestion des modifications. 

Avantages de l'utilisation de WAL pour Postgres CDC

• Tandis que il y a encore du codage impliqué dans l'utilisation du WAL, il nécessite globalement moins de codage que les autres méthodes Postgres CDC dont nous avons discuté.
• Solutions et plateformes tierces telles que 'pglogique' sont disponibles pour simplifier les étapes les plus complexes du processus. 

Inconvénients de l'utilisation de WAL pour Postgres CDC

• Les données que vous extrayez du WAL peuvent être au format brut. Le transformer pour l'aligner sur la structure de données de votre application a besoin travail supplémentaire.
• La surveillance des modifications dans le WAL pourrait nécessiter des scripts ou une automatisation supplémentaires.
• La compréhension et l'interprétation des enregistrements WAL nécessitent une compréhension approfondie du fonctionnement interne de votre base de données Postgres. 

Automatiser Postgres CDC avecième Astera 

L'exemple suivant explique comment vous pouvez automatiser déclencher-basé CDC Postgres en utilisant Astera. Let de assumer vous êtes travailler avec un PostgreSQL base de données et avoir configuré un Source de table de base de données pour lire les informations de cette base de données.  

Tout d'abord, vous aurez activer CDC sur cette base de donnéesase par la sélection Activer la capture des données modifiées sur la table. 

Ensuite, sélectionnez les champs sur lesquels vous souhaitez activer le CDC, via le Sélectionner les colonnes boite de dialogue. 

Tandis que you peut sélectionner un ou tous les champs d'une base de données, il est obligatoire de choisir une clé primaire. Dans ce cas, vous pouvez choisir EmployésID. 
 

Une fois vous avez choisi les champs, cliquez sur 'OK". Vous aurez voir la boîte de dialogue indiquant que vous avez activé avec succès CDC sur cette base de données. 

Ensuite, configurer la table de destination pour stocker les données mises à jour à partir de la table source. Ajoutez un objet de destination de base de données depuis la boîte à outils à votre gauche. 

Configurez l'objet de destination en ouvrant ses propriétés. Dans le Définir les ports d'entrée pour Maping  , sélectionnez le Insérer case à cocher avec une source CDC car les données entrantes le feront Probable contiennent les enregistrements nouveaux et mis à jour. Dans Sélectionnez les champs pour la base de données correspondantecorde, '; '; ; EmployésID depuis il est la clé primaire et unique pour chaque enregistrement de la base de données source. 

Ensuite, utilisez le glisser-déposer pour mapper tous les champs de l’objet source de la base de données à l’objet de destination. Le flux de données vers la mise en œuvre de Postgres CDC est maintenant terminée. 

Lorsque vous exécutez le flux de données et vérifiez la fenêtre de progression de la tâche, vous aurez Trouve ça Astera a lu et écrit le entrées de la table source vers la table de destination. 

CDC Postgres incrémentiel

Il s'agit d'avoir un lien direct avec le cœur des opérations de votre facile à configurer Incremental CDC dans une base de données PostgreSQL en utilisant Astera, vous permettant de charger les données De votre table de base de données progressivement au lieu de compléter les charges à chaque course.

LET suppose que ont été travailler avec les données des compagnies maritimes dans ce cas d'utilisation et souhaitez stocker ces données dans un nouveau base de données tableau. Nous voulons pouvoir mettre à jour la nouvelle table à tout moment il existe un changement dans la source, sans avoir à charger complètement la table source.

Bien utilisez une source de table de base de données préconfigurée avec les informations pertinentes. 

Accédez aux propriétés de l'objet source en faire un clic droit son en-tête et en sélectionnant Propriétés.

Connectez-vous à la base de données et cliquez sur « Suivant » pour procéder. 

Sur l'écran suivant vous aurez voir la Options de lecture incrémentielle .  

Selectionnez Charge incrémentielle basée sur les champs d'audit as le Lire la stratégie qui affichera d’autres options. 

Champs d'audit sont mis à jour lorsqu'un enregistrement est créé ou modifié, tels que la date et l'heure de création, la date et l'heure de modification et le numéro automatique. La lecture incrémentielle suit la valeur la plus élevée pour tous les champs d'audit que vous spécifiez. Lors de la prochaine exécution, seuls les enregistrements ayant une valeur supérieure à la valeur enregistrée récupéré. 

• Ajoutez un chemin de fichier pour le Fichier d'informations sur les transferts incrémentiels, Qui Astera crée pour stocker des informations sur la dernière entrée de la table de base de données. Il comparera ce fichier avec la table de base de données à chaque exécution pour vérifier les nouvelles entrées.
   
• Configurer une table de destination par glisser-déposer Destination de la table de base de données à partir de la boîte à outils. 

• Une fois configuré, mappez la source de la table à l’objet de destination de la table.  

• Vous aurez voir que la table de destination est vide. Vous pouvez vérifier son contenu comme indiqué ci-dessous, et cela ouvrira une requête SQL pour visualiser les données du tableau. 

• Lorsque vous exécutez le flux de données, vérifiez le Progression du travail fenêtre et vous verrez que le entrées de la table source sont considérés code écrit à la table de destination. 

 

• Vous pouvez le vérifier en prévisualisant la table de destination. 

 

Choisir la bonne méthode PostgreSQL CDC pour votre cas d'utilisation 

Il existe plusieurs méthodes pour implémenter CDC dans une base de données PostgreSQL, et vous devez prendre en compte plusieurs facteurs pour décider quelle méthode choisir. Chaque méthode a ses avantages et ses inconvénients, que nous avons brièvement décrit au-dessus de. De plus, voici quelques autres points à prendre en compte : 

Volume de données et fréquence de changement : 

• Dans les environnements où les changements de données sont modérés et nécessitent un suivi en temps réel, le CDC basé sur des déclencheurs est votre meilleur choix.
  
• La réplication logique convient aux scénarios comprenant des taux de modification de données élevés car il offre des capacités de réplication en temps réel.
• Si l'extraction de modifications de données est peu fréquente dans vos flux de travail, choisissez Postgres CDC basé sur des requêtes. 

Performances et frais généraux : 

• Postgres CDC basé sur des déclencheurs peut ajouter une surcharge supplémentaire, surtout si des taux de transaction élevés sont impliqués.
• La réplication logique a un faible impact et est simple pour le système source, ce qui en fait le bon choix pour les scénarios hautes performances.
• Le CDC basé sur les requêtes ne consomme généralement pas trop de ressources, mais il peut affecter les performances en cas de requêtes intensives. 

Complexité du cas d'utilisation : 

• Le CDC basé sur des déclencheurs est utile pour les cas complexes qui nécessitent une personnalisation et un suivi détaillé des modifications.
• La réplication logique convient aux cas nécessitant simplicité et réplication en temps réel.
• CDC basé sur des requêtes est une option simple pour les cas d'utilisation simples qui ne nécessitent pas de déclencheurs complexes. 

Intégration et compatibilité : 

• CDC basé sur des déclencheurs peut s'intégrer de manière transparente à vos applications et bases de données actuelles
  
• La réplication logique est idéale pour les scénarios où il existe un besoin de compatibilité entre différentes instances de Postgres.
• Le CDC basé sur des requêtes implique des requêtes personnalisées. En tant que tel, c'est la bonne option pour répondre à des besoins d'intégration sur mesure. 

Simplicité et fonctionnalité : 

• CDC basé sur des déclencheurs est une solution robuste offrant un suivi détaillé des modifications, mais cela ajoute à sa complexité. Idéal pour les environnements nécessitant beaucoup de personnalisation.
• La réplication logique trouve ici le bon équilibre, ce qui en fait un choix pratique pour une variété de scénarios et idéal pour répondre aux exigences de réplication en temps réel.
• Le CDC basé sur des requêtes est assez simple et flexible, mais cela signifie qu'il peut potentiellement nécessiter davantage d'interventions manuelles. C'est la bonne technique pour l'extraction occasionnelle de modifications. 

Conclusion 

Dans ce blog, nous avons examiné en profondeur diverses options que vous pouvez utiliser pour implémenter CDC dans PostgreSQL. Nous avons également discuté des avantages et des inconvénients de chaque méthode et mis en évidence les facteurs que vous devriez Pour conférer avant de choisir une méthode CDC pour votre entreprise. 

Tandis que il n'y a pas solution universelle quand il s'agit de changer la saisie des données, l'automatisation du processus devrait être dans votre liste de priorités. En fin de compte, comment vous la mise en œuvre de Postgres CDC dépend de votre les exigences de performances, les préférences de personnalisation et cas d'utilisation individuel. 

At Astera, nous croyons en la fourniture d'une solution simplifiée de gestion des données de bout en bout. Notre interface intuitive par glisser-déposer avec construit-dans les connecteurs et les transformations supprime le codage et démocratise les opérations de données, les rendant également accessibles et pertinentes pour les parties prenantes non techniques et techniques. 

Notre suite vous permet de simplifier votre intégration de données les process, construire robuste entrepôts de donnéeset la rationalisez votre EDI et Gestion des API, le tout sans écrire une seule ligne de code. 

Expérimentez la Astera différence. Commencer votre essai gratuit aujourd'hui ou demander un devis pour commencer.