Startseite
Fachnachrichten
Die versteckten Kosten der Change Data Capture: Die Abwägungen von CDC auf Proxylösungen wie DataSunrise verstehen

Die versteckten Kosten der Change Data Capture: Die Abwägungen von CDC auf Proxylösungen wie DataSunrise verstehen

Change Data Capture (CDC) ist ein viel genutzter Ansatz in datengetriebenen Unternehmen, um Änderungen in einer Datenbank nachzuverfolgen. CDC ermöglicht es Organisationen, Datenänderungen (wie Einfügungen, Aktualisierungen und Löschungen) zu überwachen und diese Änderungen effizient an nachgelagerte Systeme weiterzugeben. Während CDC einen Wert bei der Aufrechterhaltung der Datenkonsistenz über mehrere Systeme hinweg bieten kann, kann die Implementierung von CDC mittels Proxylösungen wie DataSunrise zu erheblichen Leistungsproblemen und betrieblichen Kopfschmerzen führen.

In diesem Artikel werden wir beleuchten, was CDC ist, die Herausforderungen bei der Implementierung mittels Proxylösungen wie DataSunrise diskutieren und erläutern, warum diese Praxis als ineffizient gilt. Wir werden auch detaillierte Beispiele einbeziehen, um die mit diesem Ansatz verbundenen Probleme und Leistungseinflüsse zu illustrieren.

Was ist Change Data Capture (CDC)?

Change Data Capture (CDC) ist ein Mechanismus, um Änderungen in einer Datenbank in Echtzeit oder nahezu Echtzeit zu identifizieren und nachzuverfolgen. Durch das Erfassen von Einfügungs-, Aktualisierungs- und Löschoperationen stellt CDC sicher, 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 Aufrechterhaltung der Synchronisation zwischen verschiedenen Datenbanken.
Einführung von Daten in Streaming-Systeme für Echtzeit-Analysen.
Überwachung zur Prüfung und Einhaltung von Vorschriften.

CDC kann auf verschiedene Weise implementiert werden, beispielsweise:

Log-basierte CDC. Liest direkt aus den Transaktionslogs der Datenbank.
Trigger-basierte CDC. Verwendet Datenbank-Trigger, um Änderungen zu erfassen.
Polling-basierte CDC. Fragtabellen periodisch ab, 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 die proxy-basierte CDC und die damit verbundenen Probleme, insbesondere im Kontext von Lösungen wie DataSunrise.

Wie CDC mit Proxylösungen wie DataSunrise funktioniert

DataSunrise fungiert als Middleware-Proxy, der zwischen der Anwendung und der Datenbank sitzt und alle eingehenden SQL-Abfragen abfängt. Ziel ist es, Sicherheits-, Audit- und CDC-Funktionalitäten bereitzustellen, was bedeutet, dass jede Änderung der Daten erfasst werden muss.

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

Ausführen einer SELECT-Abfrage vor einer Aktualisierung unter Verwendung der gleichen Bedingungen wie die UPDATE-Anweisung, um den aktuellen Zustand der Daten zu erfassen.
Ausführen einer weiteren SELECT-Abfrage nach der Aktualisierung (oder 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 Leistungseinbußen führt.

Leistungsimplikationen von CDC über Proxylösungen

Erhöhte Anzahl von Abfragen

Einer der Hauptnachteile der Implementierung von CDC über einen Proxy sind die zusätzlichen SELECT-Abfragen, die erforderlich sind, um den Zustand der Daten vor und nach einer Änderung zu erfassen. Betrachten wir das folgende Szenario:

Beispiel-Szenario. Aktualisierungsoperation

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:

Vor-Aktualisierung-Snapshot. DataSunrise führt eine SELECT-Abfrage aus, um die aktuellen Werte zu erfassen:

SELECT * FROM customers WHERE customer_id = 12345;

Diese Abfrage erfasst den Zustand vor der Aktualisierung, einschließlich des Wertes von balance vor der Anwendung der Änderung.

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

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

Nach-Aktualisierung-Snapshot. DataSunrise führt dann eine weitere Abfrage aus, um den Zustand nach der Änderung zu erfassen:

SELECT * FROM customers WHERE customer_id = 12345;

Alternativ kann, falls unterstützt, die RETURNING-Klausel verwendet werden:

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

Auswirkungen. Für jede UPDATE-Abfrage gibt es jetzt zwei zusätzliche SELECT-Abfragen (oder einen alternativen RETURNING-Mechanismus). Dieser Ansatz verdreifacht die Anzahl der auf der Datenbank ausgeführten Abfragen, was in folgendes resultiert:

Erhöhte Datenbanklast. Die Datenbank muss eine erheblich höhere Anzahl von Abfragen verarbeiten.
Erhöhtes Netzwerkaufkommen. Mehr Daten werden zwischen Proxy und Datenbank übertragen.
Latenzprobleme. Die zusätzlichen Abfragen führen zu längeren Antwortzeiten für die Anwendung.

Sperren und mögliche Deadlocks

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

Beispiel-Szenario. Datenbanksperren und Deadlocks

Betrachten wir folgendes Beispiel, bei dem mehrere gleichzeitige Transaktionen denselben Datensatz aktualisieren:

Transaktion A versucht, das Guthaben für customer_id = 12345 zu aktualisieren.
Gleichzeitig versucht Transaktion B, ein anderes Feld, wie z. B. die E-Mail, für denselben Kunden zu aktualisieren.

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

Dies könnte zu einer Situation führen, in der:

Transaktion A eine gemeinsame Sperre für die SELECT-Abfrage auf customer_id = 12345 hält.
Transaktion B ebenfalls eine gemeinsame Sperre für dieselbe SELECT-Abfrage hält.
Wenn beide Transaktionen versuchen, exklusive Sperren für die UPDATE-Anweisungen zu erhalten, blockieren sie sich gegenseitig, 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 hochgradig parallelen Umgebung erhöht.

Lastverstärkung

CDC über Proxylösungen führt zu einer Lastverstärkung auf der Datenbank. Für jede Änderungsoperation (Einfügung, Aktualisierung, Löschung) werden mehrere zusätzliche Abfragen generiert, wodurch die Last mindestens um den Faktor drei verstärkt wird. Dies kann schwerwiegende Folgen haben:

CPU- und I/O-Overhead. Der Datenbankserver muss viele Abfragen zusätzlich verarbeiten, was zu erhöhter CPU- und Festplatten-I/O-Nutzung führt.
Abfragekonkurrenz. Mit einer größeren Anzahl von Abfragen gibt es mehr Konkurrenz um Datenbankressourcen wie CPU, Speicher und Sperren. Dies kann zu längeren Abfragewartezeiten und geringerer Verarbeitungskapazität führen.
Skalierbarkeitsprobleme. Die zusätzliche Last erschwert die Skalierung der Datenbank, um mehr Benutzer oder höhere Transaktionsvolumen zu unterstützen. Die Proxylösung selbst kann zum Engpass werden, wodurch die Gesamtskalierbarkeit des Systems eingeschränkt wird.

Unwirtschaftlichkeit bei komplexen SQL-Abfragen

Für bestimmte komplexe SQL-Abfragen ist die Verwendung einer RETURNING-Klausel möglicherweise nicht praktikabel. Betrachten Sie beispielsweise ein UPDATE, das 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 auszuführen. Dies führt zu noch komplexeren Abfrageausführungsplänen und belastet die Datenbank weiter.

Echtes Beispiel: Leistungsbenchmark

Betrachten wir ein Szenario, bei dem eine Einzelhandelsanwendung eine Datenbank mit einem hohen Transaktionsvolumen hat. Die Anwendung führt 1.000 Aktualisierungsoperationen pro Sekunde an einer Tabelle mit Informationen zu Kundenbestellungen aus. Vergleichen wir den Einfluss der Verwendung von CDC über DataSunrise im Vergleich zu einem log-basierten CDC-Mechanismus:

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

1.000 Vor-Aktualisierung-SELECT-Anweisungen.
1.000 UPDATE-Anweisungen.
1.000 Nach-Aktualisierung-SELECT-Anweisungen (oder Äquivalent).

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

Höhere CPU- und Speicherauslastung. Erhöhte Last erfordert mehr Ressourcen.
Abfragelatenz. Erhöhte Roundtrips fügt der Transaktion Latenz hinzu, was sich auf das Endbenutzererlebnis auswirkt.
Skalierbarkeitsprobleme. Die Datenbank hat Schwierigkeiten, über das ursprüngliche Transaktionsvolumen hinaus zu skalieren, aufgrund der Lastverstärkung.

Alternativen zur Proxy-basierten CDC

Um die Leistungseinbrüche zu vermeiden, die mit CDC über Proxylösungen wie DataSunrise verbunden sind, sollten die folgenden Alternativen in Betracht gezogen werden:

Log-basierte CDC:

Log-basierte CDC liest direkt aus dem Transaktionslog, welches von der Datenbank geführt wird. Dieser Ansatz ist effizient, da keine zusätzlichen SELECT-Abfragen erforderlich sind und der normale Workflow der Anwendung nicht gestört wird.
Beispiele für log-basierte CDC-Tools umfassen Debezium, Oracle GoldenGate und AWS Database Migration Service (DMS).

Trigger-basierte CDC:

Datenbank-Trigger können verwendet werden, um Änderungen auf Zeilenebene zu erfassen. Allerdings können Trigger ebenfalls Overhead einführen, insbesondere bei Tabellen mit hohem Volumen.
Dieser Ansatz kann für kleine bis mittlere Arbeitslasten geeignet sein, bei denen die Komplexität des Trigger-Managements gerechtfertigt ist.

Datenbank-Native CDC:

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

Auch die Implementierung von CDC zu Überwachungszwecken durch alternative Methoden ermöglicht es, nur Änderungen zu überwachen. SELECT- und UPDATE-/DELETE-Abfragen, die keine Änderungen hervorrufen, werden nicht in die Überwachung einbezogen.

Schlussfolgerung

Die Implementierung von Change Data Capture (CDC) unter Verwendung 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 Möglichkeit von Datensperren und Deadlocks. Die Notwendigkeit zusätzlicher SELECT-Abfragen vor und nach jeder Aktualisierung erzeugt eine übermäßige Last auf der Datenbank, was die Leistung erheblich beeinträchtigen kann, insbesondere in hochgradig parallelen Umgebungen.

Statt sich auf Proxy-basierte CDC zu verlassen, ist es ratsam, effizientere Alternativen wie log-basierte CDC, trigger-basierte CDC oder native CDC-Funktionen der Datenbank zu verwenden. Diese Ansätze erfassen Veränderungen ohne unnötigen Overhead, wodurch sichergestellt wird, dass Ihre Anwendung und Datenbank effizient skalieren und dabei die Datenintegrität wahren.

Letztendlich sollte die Wahl der CDC-Implementierung auf einer sorgfältigen Bewertung der Leistungsanforderungen, Skalierbarkeitsbedürfnisse und Betriebskomplexität basieren. Es ist wichtig, die Ziele und die Einschränkungen jeder Technologie zu verstehen und möglicherweise verschiedene Technologien zu kombinieren, um eine vollständige Überwachung zu gewährleisten. Durch die Vermeidung der Fallstricke der Proxy-basierten CDC können Sie sicherstellen, dass Ihr System leistungsfähig und zuverlässig bleibt, selbst wenn das Datenvolumen wächst.