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

Les coûts cachés de la capture de données de changement : comprendre les compromis de CDC sur les 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 d’une base de données. CDC permet aux organisations de surveiller les modifications de données (comme les insertions, les mises à jour et les suppressions) et de propager efficacement ces modifications aux systèmes en aval. Bien que CDC puisse offrir une valeur ajoutée en maintenant la cohérence des données entre plusieurs systèmes, la mise en œuvre de CDC en utilisant des solutions proxy, telles que DataSunrise, peut entraîner des problèmes de performance significatifs 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 les performances 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 permettant d’identifier et de suivre les modifications dans une base de données en temps réel ou en quasi-temps réel. En capturant les opérations d’insertion, de mise à jour et de suppression, CDC garantit que les modifications de données sont disponibles pour les analyses, l’entreposage de données, les processus ETL et les besoins de réplication des données. CDC est devenu crucial pour des cas d’utilisation tels que :

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

CDC peut être mis en œuvre de différentes manières, telles que :

CDC basé sur le journal. Lecture directe à partir des journaux de transactions de la base de données.
CDC basé sur les déclencheurs. Utilisation des déclencheurs de base de données pour capturer les modifications.
CDC basé sur l’interrogation. Interrogation périodique des tables pour détecter les modifications.
CDC basé sur le proxy. Utilisation d’un proxy middleware pour intercepter et journaliser les modifications de données.

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

Comment fonctionne le CDC avec des solutions proxy comme DataSunrise

DataSunrise agit comme un proxy middleware 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 modification apportée aux données.

Pour mettre en œuvre 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 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 conduit à une dégradation des performances.

Implications sur les performances du CDC via des solutions proxy

Augmentation du nombre de requêtes

L’un des principaux inconvénients de la mise en œuvre du CDC via un proxy est les requêtes SELECT supplémentaires requises 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 implémenter CDC, DataSunrise doit capturer à la fois les états précédents et nouveaux des données. Cela implique les étapes suivantes :

Instantané pré-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é post-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 RETURNING alternatif). Cette approche triple le nombre de requêtes exécutées sur la base de données, entraînant :

Augmentation de la charge de la base de données. La base de données doit gérer un nombre considérablement plus élevé de requêtes.
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 aller-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 risques potentiels de blocages

Une autre préoccupation majeure concernant l’exécution d’instructions SELECT supplémentaires est l’impact sur les verrous de la base de données et le risque de blocages.

Scénario Exemple. Verrouillage des données et blocages

Considérons l’exemple suivant où plusieurs transactions simultanées mettent à jour le même ensemble d’enregistrements :

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

Pour implémenter CDC, DataSunrise doit d’abord lire les valeurs existantes pour les deux transactions. Les instructions SELECT pré-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, entraînant un blocage.

Les blocages entraînent l’avortement 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 maintenus pendant des durées plus longues, augmentant ainsi la probabilité de blocages dans un environnement à haute concurrence.

Amplification de la charge

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

Surcharge CPU et I/O. Le serveur de base de données doit traiter beaucoup plus de requêtes, ce qui entraîne une utilisation accrue du CPU et des entrées/sorties du disque.
Contention des 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 telles que 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 mise à l’échelle. La charge supplémentaire rend difficile la mise à l’échelle de la base de données pour accueillir plus d’utilisateurs ou de volumes de transactions plus élevés. La solution de 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 réalisable. 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 sollicite davantage 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 les informations de commande des clients. Comparons l’impact de l’utilisation de CDC via DataSunrise par rapport à un mécanisme de CDC basé sur le journal :

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

1 000 instructions SELECT pré-mise à jour.
1 000 instructions UPDATE.
1 000 instructions SELECT post-mise à jour (ou équivalent).

Cela conduit à 3 000 requêtes par seconde au lieu des 1 000 initiales. La base de données doit gérer trois fois la charge, entraînant :

Augmentation de l’utilisation du CPU et de la mémoire. Une charge plus élevée signifie plus de ressources sont requises.
Latence des requêtes. Les allers-retours supplémentaires ajoutent de la latence à chaque transaction, impactant l’expérience utilisateur finale.
Problèmes de mise à l’échelle. La base de données a du mal à se mettre à l’échelle au-delà du volume de transactions initial en raison de l’amplification de la charge.

Alternatives au CDC basé sur le proxy

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

CDC basé sur le journal :

Le CDC basé sur le journal 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 flux de travail normal de l’application.
Des exemples d’outils de CDC basés sur le journal incluent Debezium, Oracle GoldenGate et AWS Database Migration Service (DMS).

CDC basé 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 des surcharges, en particulier pour les tables à fort volume.
Cette approche peut être adaptée pour des charges de travail petites à moyennes où la complexité de la gestion des déclencheurs est justifiée.

CDC natif de la base de données :

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

De plus, la mise en œuvre de CDC à des fins de surveillance par des moyens alternatifs permet de surveiller uniquement les changements. 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 un proxy comme DataSunrise peut entraîner des problèmes significatifs de performance et de stabilité, principalement en raison de l’augmentation du nombre de requêtes et du potentiel de verrous de données et de blocages. Le besoin de requêtes SELECT supplémentaires avant et après chaque mise à jour génère une charge excessive sur la base de données, ce qui peut dégrader sévèrement les performances, en particulier dans des environnements à haute concurrence.

Au lieu de compter sur un CDC basé sur le proxy, il est conseillé d’utiliser des alternatives plus efficaces telles que le CDC basé sur le journal, le CDC basé sur les déclencheurs ou les fonctionnalités de CDC native de la base de données. Ces approches capturent 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.

En fin de compte, le choix de la mise en œuvre de CDC doit être basé sur une évaluation minutieuse des exigences de performance, des besoins d’évolutivité et de la complexité opérationnelle. Il est important de partir des objectifs et de comprendre les limites de chaque technologie. Et peut-être qu’il est nécessaire de combiner différentes technologies pour une surveillance complète. En évitant les pièges du CDC basé sur le proxy, vous pouvez garantir que votre système reste performant et fiable, même avec l’augmentation des volumes de données.