Accueil
Actualités Professionnelles
Les coûts cachés de la capture de données de changement : Comprendre les compromis de la CDC sur des solutions proxy comme DataSunrise

Les coûts cachés de la capture de données de changement : Comprendre les compromis de la CDC sur des solutions proxy comme DataSunrise

La capture de données de changement (CDC) est une approche largement utilisée dans les entreprises axées sur les données pour suivre les modifications dans une base de données. La CDC permet aux organisations de surveiller les modifications de données (telles que les insertions, les mises à jour et les suppressions) et de propager efficacement ces changements vers les systèmes en aval. Bien que la CDC puisse apporter une valeur en maintenant la cohérence des données entre plusieurs systèmes, la mise en œuvre de la CDC en utilisant des solutions proxy, telles que DataSunrise, peut entraîner des problèmes de performance importants et des maux de tête opérationnels.

Dans cet article, nous explorerons ce qu’est la CDC, les défis liés à sa mise en œuvre en utilisant des solutions proxy comme DataSunrise, et pourquoi cette pratique est considérée comme inefficace. Nous inclurons également des exemples détaillés pour illustrer les problèmes et l’impact sur la performance associés à cette approche.

Qu’est-ce que la capture de données de changement (CDC) ?

La capture de données de changement (CDC) est un mécanisme pour identifier et suivre les modifications dans une base de données en temps réel ou quasi temps réel. En capturant les opérations d’insertion, de mise à jour et de suppression, la CDC garantit que les modifications de données sont mises à disposition pour les analyses, l’entreposage de données, les processus ETL et les objectifs de réplication de données. La CDC est devenue cruciale pour des cas d’utilisation tels que :

La réplication de données pour maintenir la synchronisation entre différentes bases de données.
L’alimentation de systèmes de streaming pour des analyses en temps réel.
La surveillance d’audit et de conformité.

La CDC peut être mise en œuvre de diverses manières, telles que :

CDC basée sur les journaux. Lit directement à partir des journaux de transaction de la base de données.
CDC basée sur les déclencheurs. Utilise des déclencheurs de la base de données pour capturer les changements.
CDC basée sur le sondage. Interroge les tables périodiquement pour détecter les changements.
CDC basée sur le proxy. Utilise un proxy intermédiaire pour intercepter et enregistrer les modifications de données.

Dans cet article, nous nous concentrerons spécifiquement sur la CDC basée sur le proxy et les problèmes qu’elle introduit, en particulier dans le contexte de solutions comme DataSunrise.

Comment la CDC fonctionne-t-elle avec des solutions proxy comme DataSunrise

DataSunrise agit comme un proxy intermédiaire qui se situe entre l’application et la base de données, interceptant toutes les requêtes SQL entrantes. Il vise à fournir des fonctionnalités de sécurité, d’audit et de CDC, ce qui signifie qu’il doit capturer chaque changement apporté aux données.

Pour mettre en œuvre la CDC, DataSunrise doit déterminer les modifications exactes pour chaque opération de mise à jour. Ce processus nécessite généralement de :

Exécuter une instruction SELECT avant une mise à jour, en utilisant les mêmes conditions que l’instruction UPDATE pour capturer l’état actuel des données.
Exécuter une autre instruction SELECT après la mise à jour (ou utiliser des fonctionnalités de la base de données comme RETURNING) pour capturer les valeurs mises à jour.

Ces étapes supplémentaires augmentent considérablement le nombre de requêtes exécutées sur la base de données, ce qui entraîne une dégradation des performances.

Implications sur la performance de la CDC via des solutions proxy

Augmentation du nombre de requêtes

Un des principaux inconvénients de la mise en œuvre de la CDC via un proxy est les requêtes SELECT supplémentaires nécessaires pour capturer les états “avant” et “après” des données. Considérons le scénario suivant :

Scénario exemple. Opération de mise à jour

Supposons qu’une application exécute une requête UPDATE pour modifier les données des clients :

UPDATE customers SET balance = balance + 100 WHERE customer_id = 12345;

Pour mettre en œuvre la CDC, DataSunrise doit capturer à la fois les états précédents et nouveaux des données. Cela implique les étapes suivantes :

Instantané avant mise à jour. DataSunrise émet une instruction SELECT pour capturer les valeurs actuelles :

SELECT * FROM customers WHERE customer_id = 12345;

Cette requête capture l’état “avant”, y compris la valeur du solde avant l’application de la mise à jour.

Appliquer la mise à jour. La requête UPDATE originale est exécutée :

UPDATE customers SET balance = balance + 100 WHERE customer_id = 12345;

Instantané après mise à jour. DataSunrise émet ensuite une autre requête pour capturer l’état “après” :

SELECT * FROM customers WHERE customer_id = 12345;

Alternativement, si pris en charge, il peut utiliser la clause RETURNING :

UPDATE customers SET balance = balance + 100 WHERE customer_id = 12345 RETURNING *;

Impact. Pour chaque requête UPDATE, il y a maintenant deux instructions SELECT supplémentaires (ou un mécanisme de RETURNING alternatif). Cette approche triple le nombre de requêtes exécutées sur la base de données, ce qui entraîne :

Augmentation de la charge de la base de données. La base de données doit gérer un nombre de requêtes beaucoup plus élevé.
Augmentation du trafic réseau. Plus de données sont transférées entre le proxy et la base de données.
Problèmes de latence. Les allers-retours pour les requêtes supplémentaires introduisent de la latence, ce qui peut entraîner des temps de réponse plus lents pour l’application.

Verrouillage et éventuels verrous morts

Un autre problème majeur avec l’exécution de requêtes SELECT supplémentaires est l’impact sur les verrous de la base de données et le risque de verrouillage mortel.

Scénario exemple. Verrouillage des données et verrous morts

Considérons l’exemple suivant où plusieurs transactions concurrentes mettent à jour le même ensemble de records :

La transaction A tente de mettre à jour le solde pour customer_id = 12345.
En même temps, la transaction B essaie de mettre à jour un autre champ, comme l’email, pour le même client.

Pour mettre en œuvre la CDC, DataSunrise doit d’abord lire les valeurs existantes pour les deux transactions. Les instructions SELECT avant mise à jour émises par les deux transactions peuvent acquérir des verrous partagés sur les enregistrements. Cependant, lorsque les instructions UPDATE sont exécutées, les deux transactions ont besoin de verrous exclusifs.

Cela peut conduire à une situation où :

La transaction A détient un verrou partagé pour le SELECT sur customer_id = 12345.
La transaction B détient également un verrou partagé pour le même SELECT.
Lorsque les deux transactions tentent d’acquérir des verrous exclusifs pour l’UPDATE, elles deviennent mutuellement bloquées, ce qui entraîne un verrou mortel.

Les verrous morts entraînent l’annulation d’une ou plusieurs transactions, ce qui affecte la fiabilité du système. Le nombre accru de requêtes SELECT signifie également que plus de verrous sont détenus pendant des durées plus longues, augmentant la probabilité de verrous morts dans un environnement très concurrentiel.

Amplification de la charge

La CDC via des solutions proxy conduit à une amplification de la charge sur la base de données. Pour chaque opération de modification (insertion, mise à jour, suppression), plusieurs opérations supplémentaires sont générées, amplifiant la charge par un facteur d’au moins trois. Cela peut avoir des conséquences graves :

Surcharges de CPU et de I/O. Le serveur de base de données doit traiter beaucoup plus de requêtes, entraînant une utilisation accrue du CPU et des entrées/sorties disque.
Contestation de requêtes. Avec un plus grand nombre de requêtes exécutées, il y a une contention accrue pour les ressources de la base de données comme le CPU, la mémoire et les verrous. Cela peut entraîner des temps d’attente plus longs pour les requêtes et une réduction du débit.
Défis de scalabilité. La charge supplémentaire rend difficile l’extension de la base de données pour accueillir plus d’utilisateurs ou des volumes de transactions plus élevés. La solution proxy elle-même peut devenir un goulot d’étranglement, limitant la scalabilité globale du système.

Inefficacité avec des requêtes SQL complexes

Pour certaines requêtes SQL complexes, l’utilisation d’une clause RETURNING peut ne pas être envisageable. Par exemple, considérons une mise à jour impliquant une jointure entre plusieurs tables :

UPDATE customers
SET balance = balance + 100
FROM transactions
WHERE customers.customer_id = transactions.customer_id AND transactions.status = 'completed';

Dans de tels cas, il peut ne pas être possible d’utiliser une clause RETURNING pour capturer toutes les valeurs mises à jour, forçant DataSunrise à émettre des requêtes SELECT supplémentaires. Cela entraîne des plans d’exécution de requêtes encore plus complexes et exerce une pression supplémentaire sur la base de données.

Exemple réel : Benchmark de performance

Considérons un scénario où une application de vente au détail dispose d’une base de données avec un volume élevé de transactions. L’application effectue 1 000 opérations de mise à jour par seconde sur une table stockant des informations de commande client. Comparons l’impact de l’utilisation de la CDC via DataSunrise par rapport à l’utilisation d’un mécanisme de CDC basé sur les journaux :

Sans CDC. L’application effectue 1 000 opérations UPDATE par seconde.
CDC basée sur les journaux. Les modifications sont capturées directement à partir du journal des transactions, ce qui n’entraîne aucune requête supplémentaire exécutée par l’application.
CDC basée sur le proxy via DataSunrise :

1 000 opérations SELECT avant mise à jour.
1 000 opérations de mise à jour.
1 000 opérations SELECT après mise à jour (ou équivalent).

Cela entraîne 3 000 requêtes par seconde au lieu des 1 000 d’origine. La base de données doit gérer trois fois la charge, ce qui entraîne :

Utilisation accrue de la CPU et de la mémoire. Une charge accrue signifie que plus de ressources sont nécessaires.
Latence des requêtes. Les allers-retours supplémentaires ajoutent de la latence à chaque transaction, affectant l’expérience de l’utilisateur final.
Problèmes de scalabilité. La base de données a du mal à évoluer au-delà du volume de transactions d’origine en raison de l’amplification de la charge.

Alternatives à la CDC basée sur le proxy

Pour éviter les pièges de performance associés à la CDC via des solutions proxy comme DataSunrise, envisagez les alternatives suivantes :

CDC basée sur les journaux :

La CDC basée sur les journaux lit directement à partir du journal des transactions, qui est maintenu par la base de données. Cette approche est efficace car elle ne nécessite pas de requêtes SELECT supplémentaires ni n’interfère avec le workflow normal de l’application.
Des exemples d’outils de CDC basés sur les journaux incluent Debezium, Oracle GoldenGate et AWS Database Migration Service (DMS).

CDC basée sur les déclencheurs :

Les déclencheurs de base de données peuvent être utilisés pour capturer les modifications au niveau de la ligne. Cependant, les déclencheurs peuvent également introduire une surcharge, en particulier pour les tables à haut volume.
Cette approche peut convenir à des charges de travail petites à moyennes où la complexité de la gestion des déclencheurs est justifiée.

CDC native à la base de données :

Certaines bases de données fournissent des capacités natives de CDC optimisées pour capturer les changements avec un minimum de surcharge. Par exemple, SQL Server offre une fonctionnalité CDC intégrée et PostgreSQL prend en charge la réplication logique.

De plus, la mise en œuvre de la CDC à des fins de surveillance par d’autres moyens permet de surveiller uniquement les modifications. Les requêtes SELECT et UPDATE/DELETE qui ne produisent aucun changement ne seront pas incluses dans la surveillance.

Conclusion

La mise en œuvre de la capture de données de changement (CDC) en utilisant une solution basée sur le proxy comme DataSunrise peut entraîner d’importants problèmes de performance et de stabilité, principalement en raison de l’augmentation du nombre de requêtes et de la possibilité de verrous de données et de verrous morts. La nécessité de requêtes SELECT supplémentaires avant et après chaque mise à jour crée une charge excessive sur la base de données, ce qui peut considérablement dégrader les performances, en particulier dans les environnements à forte concurrence.

Au lieu de compter sur la CDC basée sur le proxy, il est conseillé d’utiliser des alternatives plus efficaces telles que la CDC basée sur les journaux, la CDC basée sur les déclencheurs ou les fonctionnalités de CDC natives de la base de données. Ces approches permettent de capturer les changements sans ajouter de surcharge inutile, garantissant que votre application et votre base de données peuvent évoluer efficacement tout en maintenant l’intégrité des données.

Finalement, le choix de la mise en œuvre de la CDC doit être fait en fonction d’une évaluation minutieuse des exigences de performance, des besoins de scalabilité et de la complexité opérationnelle. Il est important de partir des objectifs et de comprendre les limitations de chaque technologie. Et peut-être que pour une surveillance complète, il est nécessaire de combiner différentes technologies. En évitant les pièges de la CDC basée sur le proxy, vous pouvez vous assurer que votre système reste performant et fiable, même lorsque les volumes de données augmentent.