Change Data Capture
CDC macht bestätigte Datenänderungen für nachgelagerte Verarbeitung zugänglich.
- ErfassungsquelleBestimmt, welche bestätigten Änderungen sichtbar werden und in welcher Form sie erscheinen.
- PositionMarkiert den zuletzt sicher verarbeiteten Punkt und steuert Wiederanlauf sowie Aufbewahrung.
- SchemavertragRegelt Bedeutung, Versionierung und Backfills unabhängig von internen Tabellenänderungen.
Einordnung
Warum das wichtig ist
Die Architekturentscheidung liegt in der Wahl des Änderungsfeeds und seiner Betriebszusagen, nicht allein im verwendeten Connector.
Das Profil umfasst allgemeines CDC und ordnet logbasiertes CDC als Ausprägung ein. Die Shop-Erweiterung mit Connector und Projektion ist hypothetisch; der aktuelle Shop besitzt sieben Module in einem Prozess und eine gemeinsame Datenbank.
CDC-Erfassungswege vergleichen
Der heutige Shop bleibt ein modularer Monolith mit den sieben Modulen Katalog, Warenkorb, Bestellung, Zahlung, Lager, Versand und Rechnung sowie einer gemeinsamen Datenbank. Für eine hypothetische Suchprojektion schreibt Bestellung eine Fachänderung und einen Outbox-Eintrag atomar. Ein logbasierter CDC-Connector liest den bestätigten Outbox-Datensatz, veröffentlicht ihn und speichert seine Position. Das Team stoppt den Connector nach der Veröffentlichung, startet ihn erneut und prüft Duplikatbehandlung, Lag und Schemawechsel, bevor es diese verteilte Ergänzung übernimmt.
So liest du das Bild
- Erfassungsquelle Log, Trigger, Änderungstabelle oder verwalteter Feed
- Position Offset erst nach erfolgreicher Wirkung bestätigen
- Schemavertrag Kompatibilität vor Connector-Rollout prüfen
| Vergleich | Erfassung | Stärke | Entscheidende Grenze |
|---|---|---|---|
| Logbasiert | Datenbanklog decodieren | Geringe Zusatzlast und commitnahe Reihenfolge | Logzugriff, Aufbewahrung und internes Schema |
| Trigger/Änderungstabelle | Änderung beim Schreiben protokollieren | Explizite Auswahl und Zusatzdaten möglich | Schreibpfad, Triggerpflege und Tabellenwachstum |
| Zeitstempelabfrage | Geänderte Zeilen wiederholt abfragen | Einfacher Start ohne Logzugriff | Lücken, Löschungen, Last und Pollinglatenz |
Nutzen & Grenzen
Hilft, wenn
- CDC passt, wenn mehrere nachgelagerte Sichten zeitnah aus bestätigten Datenänderungen versorgt werden sollen.
- Logbasiertes CDC passt, wenn die Datenbank einen stabilen Änderungsfeed bietet und zusätzliche Abfragen oder Trigger vermieden werden sollen.
- Eine Outbox plus CDC passt, wenn der veröffentlichte Vertrag gezielt von internen Tabellenänderungen getrennt werden soll.
Grenzen
- Interne Tabellenänderungen sind ohne Outbox selten ein stabiler Integrationsvertrag; Umbenennungen und Backfills müssen mit Konsumenten koordiniert werden.
- Replication Slots oder vergleichbare Positionen können Logaufbewahrung erzwingen; wachsender Rückstand gefährdet Speicher und Wiederanlauf.
- CDC liefert Änderungen, aber keine fachliche Genau-einmal-Wirkung. Konsumenten brauchen Idempotenz, Korrelation und eine geprüfte Wiederherstellung.
In der Praxis
- Führe einen Commit in der gemeinsamen Shopdatenbank aus und vergleiche Geschäftszeile, Outbox-Eintrag und veröffentlichtes Ereignis. Markiere dabei genau, welche Beobachtung aus dem Transaktionslog stammt.
- Unterbrich das Relay nach dem Lesen eines Logeintrags und starte es erneut. Prüfe, ob die Logposition korrekt fortgesetzt wird und ob eine erneute Zustellung am Empfänger idempotent bleibt.
- Vergleiche Polling auf der Outbox mit CDC anhand von Latenz, Datenbanklast und Schemaentwicklung. Entscheide, welche Betriebsverantwortung das Team übernehmen kann und wie es einen Rückstand nachweist.
Ausführliche Erklärung lesen
CDC beobachtet dauerhafte Änderungen nach dem Commit und übersetzt sie in einen für Konsumenten lesbaren Strom. Bei logbasiertem CDC decodiert ein Connector das Transaktionslog; andere Varianten lesen Änderungstabellen, Triggerausgaben oder Datenbank-Feeds.
Der Vertrag umfasst mehr als die Nutzlast: Tabellen- oder Themenauswahl, Reihenfolge innerhalb einer Partition, Startposition, Aufbewahrung, Schemaentwicklung und Verhalten bei Neustart. Ein bestätigter Offset schützt vor Datenverlust, kann bei einem Absturz zwischen Wirkung und Bestätigung aber zu erneuter Zustellung führen.
Outbox erzeugt gezielt veröffentlichbare Nachrichten in derselben Transaktion wie die Fachänderung. Idempotenz begrenzt die Wirkung wiederholter Zustellungen. CDC kann eine Outbox transportieren, ist jedoch auch für Replikation, Suche und analytische Projektionen einsetzbar.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Ausprägung liest direkt aus dem Transaktionslog?
Lösung mit Begründung ansehen
Logbasiertes CDC decodiert bestätigte Änderungen aus dem Transaktionslog.
AnwendenAuf eine neue Lage übertragen
Wo liegt im Shop die veröffentlichbare Grenze?
Lösung mit Begründung ansehen
Der Outbox-Datensatz bildet den gezielten Vertrag; CDC transportiert ihn aus der gemeinsamen Datenbank zur hypothetischen Suchprojektion.
BewertenEine Alternative abwägen
Wann ist direktes CDC auf Fachtabellen riskant?
Lösung mit Begründung ansehen
Wenn interne Schemaänderungen, Backfills oder Löschungen ohne stabilen externen Vertrag bei Konsumenten ankommen.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.