La Capture de Données Modifiées (CDC) est passée d'une technique de base de données de niche à un pilier des architectures de données modernes. Que vous construisiez un pipeline d'analyse en temps réel, synchronisiez des microservices ou alimentiez un lakehouse, la méthode choisie pour capturer les modifications de données détermine la latence, la fiabilité et la charge opérationnelle de votre système. Bien que Debezium ait ancré le CDC basé sur les journaux comme norme de l'industrie pour les bases de données relationnelles, les approches basées sur les déclencheurs conservent des avantages significatifs dans les environnements hétérogènes où l'accès aux journaux est restreint ou où la flexibilité du schéma est requise.
Comprendre les deux paradigmes
Le CDC basé sur les journaux consiste à analyser les journaux transactionnels (tels que le WAL de PostgreSQL ou le Binlog de MySQL) pour reconstruire les événements de modification. Cette méthode est non intrusive ; elle ne nécessite aucune modification du code applicatif ou du schéma de la base de données. Des outils comme Debezium exploitent cette approche pour fournir un flux de données à haut débit et à faible latence avec de fortes garanties de cohérence.
Le CDC basé sur les déclencheurs, en revanche, repose sur des déclencheurs de base de données (par exemple, `AFTER UPDATE` ou `AFTER DELETE`) pour écrire les événements de modification dans une table d'audit ou une file d'attente distincte. Bien que cette approche ajoute une charge d'écriture à la base de données source, elle est indépendante de la base de données et peut être implémentée sur des systèmes où l'accès aux journaux n'est pas disponible, tels que certaines bases de données hébergées dans le cloud ou des instances Oracle legacy.
Analyse des performances et de la surcharge
Le principal compromis réside dans l'impact sur le système source. Le CDC basé sur les journaux découple la capture des modifications du chemin d'écriture. Le moteur de base de données écrit dans son journal dans le cadre du traitement transactionnel normal, et le connecteur CDC suit ces journaux. Cela résulte en une latence ajoutée et une consommation de ressources minimales.
En revanche, le CDC basé sur les déclencheurs ajoute une opération d'écriture synchrone à chaque transaction. Si vous mettez à jour une ligne, la base de données doit également écrire une entrée dans la table d'audit. Cela augmente la charge d'E/S et peut introduire des contentions, surtout sous de forts volumes d'écriture. Cependant, les déclencheurs offrent un avantage distinct : ils peuvent capturer des données à partir de tables qui ne sont pas journalisées ou de bases de données qui n'exposent pas leurs journaux transactionnels aux consommateurs externes.
Exemples de code et implémentation
Considérez une configuration simple de déclencheur PostgreSQL pour capturer les modifications d'utilisateurs :
CREATE OR REPLACE FUNCTION log_user_changes()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO user_audit_log (id, action, changed_at, payload)
VALUES (
COALESCE(NEW.id, OLD.id),
TG_OP,
NOW(),
row_to_json(COALESCE(NEW, OLD))
);
RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER trg_user_changes
AFTER INSERT OR UPDATE OR DELETE ON users
FOR EACH ROW EXECUTE FUNCTION log_user_changes();En contraste, la configuration d'un connecteur Debezium pour la même table est définie de manière déclarative, souvent via les propriétés Kafka Connect :
name: postgres-cdc
connector.class: io.debezium.connector.postgresql.PostgresConnector
database.hostname: my-db
database.port: 5432
database.user: debezium
database.password: secret
database.dbname: mydb
database.server.name: mydb
plugin.name: pgoutput
publication.name: mypublicationRemarquez comment la configuration Debezium est purement opérationnelle, ne nécessitant aucune modification du schéma, tandis que l'approche par déclencheurs nécessite des modifications DDL et la maintenance du schéma d'audit.
Choisir la bonne stratégie pour les systèmes hétérogènes
Dans un environnement hétérogène, vous pouvez faire face à des exigences mixtes. Par exemple, vous pourriez utiliser Debezium pour les bases de données MySQL et PostgreSQL à fort volume afin d'assurer une faible latence et un impact minimal sur la source. Cependant, pour une base de données Oracle legacy ou un service cloud comme AWS RDS où l'accès au binlog/WAL est restreint ou non pris en charge, vous pourriez avoir besoin de revenir au CDC basé sur les déclencheurs ou même au sondage avec des requêtes incrémentielles.
Une stratégie hybride est souvent la plus pragmatique. Utilisez le CDC basé sur les journaux lorsque c'est possible pour les performances et la cohérence, et employez des mécanismes basés sur les déclencheurs ou le sondage comme solution de repli pour les cas limites. Assurez-vous que vos événements CDC sont normalisés dans un format commun (tel que Avro ou JSON) avant de les ingérer dans votre plateforme de streaming, permettant aux consommateurs en aval de rester agnostiques quant à la méthode de capture.
Conclusion
Il n'existe pas de solution universelle pour la Capture de Données Modifiées. Le CDC basé sur les journaux, exemplifié par des outils comme Debezium, offre de meilleures performances et une non-intrusivité pour les bases de données relationnelles standard, ce qui en fait le choix privilégié pour les scénarios à haut débit. Le CDC basé sur les déclencheurs reste un outil vital pour les systèmes avec un accès restreint aux journaux ou où un contrôle au niveau du schéma est requis. En évaluant vos systèmes sources spécifiques, vos exigences de performance et vos contraintes opérationnelles, vous pouvez concevoir une architecture CDC robuste et évolutive qui répond aux exigences de l'ingénierie des données moderne.