Startseite
Fachnachrichten
Die versteckten Kosten der Change Data Capture: Verstehen der Kompromisse von CDC bei Proxy-Lösungen wie DataSunrise

Die versteckten Kosten der Change Data Capture: Verstehen der Kompromisse von CDC bei Proxy-Lösungen wie DataSunrise

Change Data Capture (CDC) ist ein weit verbreiteter Ansatz in datengetriebenen Unternehmen, um Änderungen in einer Datenbank zu verfolgen. CDC ermöglicht es Organisationen, Datenänderungen (wie Einfügungen, Aktualisierungen und Löschungen) zu überwachen und diese Änderungen effizient auf nachgelagerte Systeme zu übertragen. Während CDC dazu beitragen kann, die Datenkonsistenz über mehrere Systeme hinweg aufrechtzuerhalten, kann die Implementierung von CDC mit Proxy-Lösungen wie DataSunrise zu erheblichen Leistungsproblemen und betrieblichen Kopfschmerzen führen.

In diesem Artikel werden wir untersuchen, was CDC ist, welche Herausforderungen mit der Implementierung von CDC mit Proxy-Lösungen wie DataSunrise verbunden sind und warum diese Praxis als ineffizient gilt. Wir werden auch detaillierte Beispiele einbeziehen, um die Probleme und die Auswirkungen auf die Leistung, die mit diesem Ansatz verbunden sind, zu veranschaulichen.

Was ist Change Data Capture (CDC)?

Change Data Capture (CDC) ist ein Mechanismus zur Identifizierung und Verfolgung von Änderungen in einer Datenbank in Echtzeit oder nahezu Echtzeit. Durch das Erfassen von Einfügungen, Aktualisierungen und Löschungen sorgt CDC dafür, dass Datenänderungen für Analysen, Data Warehousing, ETL-Prozesse und Datenreplikationszwecke verfügbar gemacht werden. CDC ist für Anwendungsfälle wie:

Datenreplikation zur Synchronisierung zwischen verschiedenen Datenbanken.
Einspielen von Daten in Streaming-Systeme für Echtzeitanalysen.
Überwachungs- und Compliance-Überwachung.

CDC kann auf verschiedene Weise implementiert werden, wie zum Beispiel:

Log-basierte CDC. Liest direkt aus den Transaktionslogs der Datenbank.
Trigger-basierte CDC. Verwendet Datenbank-Trigger, um Änderungen zu erfassen.
Pollen-basierte CDC. Pollen von Tabellen in regelmäßigen Abständen, um Änderungen zu erkennen.
Proxy-basierte CDC. Verwendet einen Middleware-Proxy, um Datenänderungen abzufangen und zu protokollieren.

In diesem Artikel konzentrieren wir uns speziell auf Proxy-basierte CDC und die Probleme, die sie insbesondere im Kontext von Lösungen wie DataSunrise mit sich bringen.

Wie CDC mit Proxy-Lösungen wie DataSunrise funktioniert

DataSunrise fungiert als Middleware-Proxy, der zwischen Anwendung und Datenbank sitzt und alle eingehenden SQL-Abfragen abfängt. Es soll Sicherheits-, Überwachungs- und CDC-Funktionen bereitstellen, was bedeutet, dass jede Änderung an Daten erfasst werden muss.

Um CDC zu implementieren, muss DataSunrise die genauen Änderungen für jede Aktualisierungsoperation bestimmen. Dieser Prozess erfordert in der Regel:

Ausführen einer SELECT-Anweisung vor einer Aktualisierung mit denselben Bedingungen wie die UPDATE-Anweisung, um den aktuellen Zustand der Daten zu erfassen.
Eine weitere SELECT-Anweisung nach der Aktualisierung (oder die Verwendung von Datenbankfunktionen wie RETURNING), um die aktualisierten Werte zu erfassen.

Diese zusätzlichen Schritte erhöhen die Anzahl der auf der Datenbank ausgeführten Abfragen erheblich, was zu einer Verschlechterung der Leistung führt.

Leistungsimplikationen von CDC über Proxy-Lösungen

Erhöhte Anzahl von Abfragen

Einer der größten Nachteile der Implementierung von CDC über einen Proxy ist die zusätzlichen SELECT-Abfragen, die erforderlich sind, um den “Vorher”- und “Nachher”-Zustand der Daten zu erfassen. Betrachten wir das folgende Szenario:

Beispielszenario. Update-Operation

Angenommen, eine Anwendung führt eine UPDATE-Abfrage aus, um Kundendaten zu ändern:

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

Um CDC zu implementieren, muss DataSunrise sowohl den vorherigen als auch den neuen Zustand der Daten erfassen. Dies umfasst die folgenden Schritte:

Voraktualisierungs-Snapshot. DataSunrise gibt eine SELECT-Anweisung aus, um die aktuellen Werte zu erfassen:

SELECT * FROM customers WHERE customer_id = 12345;

Diese Abfrage erfasst den “Vorher”-Zustand, einschließlich des Werts des Saldos vor der Anwendung der Aktualisierung.

Anwendung der Aktualisierung. Die ursprüngliche UPDATE-Abfrage wird ausgeführt:

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

Nachaktualisierungs-Snapshot. DataSunrise gibt dann eine weitere Abfrage aus, um den “Nachher”-Zustand zu erfassen:

SELECT * FROM customers WHERE customer_id = 12345;

Alternativ, wenn unterstützt, könnte es die RETURNING-Klausel verwenden:

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

Auswirkung. Für jede UPDATE-Abfrage gibt es jetzt zwei zusätzliche SELECT-Anweisungen (oder ein alternatives RETURNING-Mechanismus). Dieser Ansatz verdreifacht die Anzahl der ausgeführten Abfragen auf der Datenbank, was führt zu:

Erhöhte Datenbanklast. Die Datenbank muss eine signifikant höhere Anzahl von Abfragen verarbeiten.
Erhöhter Netzwerkverkehr. Zwischen dem Proxy und der Datenbank werden mehr Daten übertragen.
Latenzprobleme. Die Rundreisen der zusätzlichen Abfragen führen zu einer Verzögerung, was zu langsameren Antwortzeiten der Anwendung führen kann.

Sperren und potenzielle Deadlocks

Ein weiteres großes Problem bei der Ausführung zusätzlicher SELECT-Anweisungen ist die Auswirkung auf Datenbanksperren und das Risiko von Deadlocks.

Beispielszenario. Datensperren und Deadlocks

Betrachten Sie das folgende Beispiel, bei dem mehrere gleichzeitige Transaktionen dieselben Datensätze aktualisieren:

Transaktion A versucht, den Saldo für customer_id = 12345 zu aktualisieren.
Gleichzeitig versucht Transaktion B, ein anderes Feld zu aktualisieren, beispielsweise die E-Mail-Adresse für denselben Kunden.

Um CDC zu implementieren, muss DataSunrise zunächst die vorhandenen Werte für beide Transaktionen lesen. Die vor der Aktualisierung ausgegebenen SELECT-Anweisungen können gemeinsame Sperren auf den Datensätzen erwerben. Wenn jedoch die UPDATE-Anweisungen ausgeführt werden, benötigen beide Transaktionen exklusive Sperren.

Dies kann zu einer Situation führen, in der:

Transaktion A eine gemeinsame Sperre für das SELECT für customer_id = 12345 hält.
Transaktion B ebenfalls eine gemeinsame Sperre für dasselbe SELECT hält.
Wenn beide Transaktionen versuchen, exklusive Sperren für das UPDATE zu erwerben, werden sie gegenseitig blockiert, was zu einem Deadlock führt.

Deadlocks führen dazu, dass eine oder mehrere Transaktionen abgebrochen werden, was die Zuverlässigkeit des Systems beeinträchtigt. Die erhöhte Anzahl von SELECT-Abfragen bedeutet auch, dass mehr Sperren für längere Zeiträume gehalten werden, was die Wahrscheinlichkeit von Deadlocks in einer Umgebung mit hoher Parallelität erhöht.

Lastverstärkung

CDC über Proxy-Lösungen führt zu einer Lastverstärkung auf der Datenbank. Für jede Änderungsoperation (Einfügen, Aktualisieren, Löschen) werden mehrere zusätzliche Operationen generiert, wodurch die Last um mindestens den Faktor drei multipliziert wird. Dies kann schwerwiegende Konsequenzen haben:

CPU- und I/O-Überlastung. Der Datenbankserver muss viele weitere Abfragen verarbeiten, was zu einer erhöhten CPU- und Festplatten-I/O-Nutzung führt.
Abfragen-Konkurrenz. Mit einer größeren Anzahl ausgeführter Abfragen gibt es mehr Konkurrenz um Datenbankressourcen wie CPU, Speicher und Sperren. Dies kann zu längeren Wartezeiten für Abfragen und verringerter Durchsatz führen.
Skalierungsprobleme. Die zusätzliche Last erschwert es, die Datenbank so zu skalieren, dass mehr Benutzer oder höhere Transaktionsvolumina unterstützt werden können. Die Proxy-Lösung selbst kann zum Engpass werden, was die Gesamtskalierbarkeit des Systems begrenzt.

Ineffizienz bei komplexen SQL-Abfragen

Für bestimmte komplexe SQL-Abfragen ist die Verwendung einer RETURNING-Klausel möglicherweise nicht machbar. Betrachten Sie beispielsweise eine Aktualisierung, die ein JOIN über mehrere Tabellen umfasst:

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

In solchen Fällen ist es möglicherweise nicht möglich, eine RETURNING-Klausel zu verwenden, um alle aktualisierten Werte zu erfassen, was DataSunrise zwingt, zusätzliche SELECT-Abfragen auszugeben. Dies führt zu noch komplexeren Abfrageausführungsplänen und belastet die Datenbank weiter.

Reales Beispiel: Leistungs-Benchmark

Betrachten Sie ein Szenario, in dem eine Einzelhandelsanwendung eine Datenbank mit einem hohen Transaktionsvolumen hat. Die Anwendung führt 1.000 Aktualisierungsoperationen pro Sekunde an einer Tabelle durch, die Kundenbestellinformationen speichert. Lassen Sie uns die Auswirkungen der Verwendung von CDC über DataSunrise im Vergleich zu einem log-basierten CDC-Mechanismus vergleichen:

Ohne CDC. Die Anwendung führt 1.000 UPDATE-Operationen pro Sekunde aus.
Log-basierte CDC. Änderungen werden direkt aus dem Transaktionslog erfasst, was dazu führt, dass keine zusätzlichen Abfragen von der Anwendung ausgeführt werden.
Proxy-basierte CDC über DataSunrise:

1.000 Voraktualisierungs-SELECT-Anweisungen.
1.000 UPDATE-Anweisungen.
1.000 Nachaktualisierungs-SELECT-Anweisungen (oder Äquivalent).

Dies führt zu 3.000 Abfragen pro Sekunde statt der ursprünglichen 1.000. Die Datenbank muss die dreifache Last verarbeiten, was führt zu:

Höherer CPU- und Speicherauslastung. Die erhöhte Last erfordert mehr Ressourcen.
Abfragelatenz. Erhöhte Rundreisen erhöhen die Latenz jeder Transaktion, was die Endbenutzererfahrung beeinträchtigt.
Skalierungsprobleme. Die Datenbank hat Schwierigkeiten, über das ursprüngliche Transaktionsvolumen hinaus zu skalieren, da die Last verstärkt wird.

Alternativen zu Proxy-basierter CDC

Um die Leistungsprobleme zu vermeiden, die mit CDC über Proxy-Lösungen wie DataSunrise verbunden sind, sollten Sie die folgenden Alternativen in Betracht ziehen:

Log-basierte CDC:

Log-basierte CDC liest direkt aus dem Transaktionslog, das von der Datenbank verwaltet wird. Dieser Ansatz ist effizient, da er keine zusätzlichen SELECT-Anweisungen erfordert oder in den normalen Workflow der Anwendung eingreift.
Beispiele für log-basierte CDC-Tools sind Debezium, Oracle GoldenGate und AWS Database Migration Service (DMS).

Trigger-basierte CDC:

Mit Datenbank-Triggern können Änderungen auf Zeilenebene erfasst werden. Trigger können jedoch auch Overhead einführen, insbesondere bei Tabellen mit hohem Volumen.
Dieser Ansatz kann für kleine bis mittlere Workloads geeignet sein, bei denen die Komplexität der Verwaltung von Triggern gerechtfertigt ist.

Native CDC der Datenbank:

Einige Datenbanken bieten native CDC-Funktionen, die für die Erfassung von Änderungen mit minimalem Overhead optimiert sind. Zum Beispiel bietet SQL Server eine integrierte CDC-Funktion, und PostgreSQL unterstützt logische Replikation.

Auch die Implementierung von CDC für Überwachungszwecke auf alternative Weise ermöglicht die Überwachung nur von Änderungen. SELECT- und UPDATE-/DELETE-Abfragen, die keine Änderungen erzeugen, werden nicht in die Überwachung einbezogen.

Fazit

Die Implementierung von Change Data Capture (CDC) mit einer Proxy-basierten Lösung wie DataSunrise kann zu erheblichen Leistungs- und Stabilitätsproblemen führen, hauptsächlich aufgrund der erhöhten Anzahl von Abfragen und der potenziellen Gefahr von Datensperren und Deadlocks. Die Notwendigkeit zusätzlicher SELECT-Abfragen vor und nach jeder Aktualisierung erzeugt eine übermäßige Last auf der Datenbank, was besonders in Umgebungen mit hoher Parallelität die Leistung erheblich beeinträchtigen kann.

Anstelle der Verwendung von Proxy-basierter CDC wird empfohlen, effizientere Alternativen wie log-basierte CDC, trigger-basierte CDC oder native CDC-Funktionen der Datenbank zu verwenden. Diese Ansätze erfassen Änderungen, ohne unnötigen Overhead hinzuzufügen, und stellen sicher, dass Ihre Anwendung und Datenbank effizient skalieren können und gleichzeitig die Datenintegrität aufrechterhalten wird.

Letztendlich sollte die Wahl der CDC-Implementierung auf einer sorgfältigen Bewertung der Leistungsanforderungen, Skalierungsbedürfnisse und betrieblichen Komplexität basieren. Es ist wichtig, dass die Ziele verstanden und die Grenzen jeder Technologie erkannt werden. Und vielleicht ist es für eine vollständige Überwachung notwendig, verschiedene Technologien zu kombinieren. Durch das Vermeiden der Fallstricke einer Proxy-basierten CDC können Sie sicherstellen, dass Ihr System leistungsfähig und zuverlässig bleibt, selbst wenn das Datenvolumen wächst.