Der Kunde ist eines der größten Finanzinstitute in der Tschechischen Republik. Jahrzehnte des Betriebs auf Oracle-Datenbanken bedeuteten steigende Lizenzkosten, Skalierbarkeitseinschränkungen und eine zunehmend komplexe Infrastrukturwartung. Die IT-Leitung entschied sich für eine strategische Migration des Transaktionsspeichers zu Azure Cosmos DB — einer vollständig verwalteten NoSQL-Datenbank für globale Verteilung und elastische Leistung.
Unsere Aufgabe war es, eine vollständige Migrationsstrategie für 200 Millionen historische Transaktionsdatensätze zu entwerfen und umzusetzen — ohne jegliche Ausfallzeit für Endbenutzer.
Herausforderung¶
Datenvolumen und Komplexität¶
Die Transaktionsdatenbank enthielt 200 Millionen Datensätze, die über mehr als 15 Jahre angesammelt wurden. Die Daten umfassten:
- Zahlungstransaktionen — Kartenzahlungen, Überweisungen, Lastschriften mit komplexen Beziehungen zu Konten, Kunden und Händlern
- Historische Aufzeichnungen — regulatorische Anforderung zur vollständigen Aufbewahrung der Transaktionshistorie über 10 Jahre
- Referenzdaten — Verknüpfungen mit Dutzenden anderer Systeme (CRM, AML, Reporting)
- Indizes und Views — Hunderte von SQL-Views und Stored Procedures, die über Jahre des Betriebs erstellt wurden
Eine direkte Migration war nicht möglich. Das relationale, normalisierte Oracle-Datenmodell unterschied sich grundlegend vom dokumentenbasierten, denormalisierten Zielmodell in Cosmos DB. Jeder Datensatz musste transformiert, angereichert und validiert werden.
Null Ausfallzeit¶
Das Finanzsystem verarbeitet Transaktionen rund um die Uhr. Jeder Ausfall hätte direkte finanzielle Auswirkungen auf Millionen von Kunden. Die Anforderung war eindeutig: Die Migration muss ohne jede Dienstunterbrechung, ohne Leistungseinbußen und ohne Datenverlust erfolgen.
Datenkonsistenz¶
Im Bankwesen muss jeder Cent stimmen. Jede Abweichung zwischen Quell- und Zielsystem wäre inakzeptabel. Wir benötigten einen Mechanismus, der 100%ige Datenkonsistenz während und nach der Migration gewährleistet.
Lösung¶
Benutzerdefinierte CDC-Pipeline¶
Wir entwarfen eine benutzerdefinierte Change Data Capture (CDC)-Pipeline auf Basis von Apache Kafka, die alle Änderungen in der Oracle-Datenbank in Echtzeit erfasste und nach Cosmos DB replizierte:
- Oracle LogMiner-Integration — Lesen der Redo-Logs zur Erfassung jeder Änderung ohne Auswirkung auf die Produktionslast
- Kafka Connect — zuverlässiger Transport von Änderungsereignissen mit garantierter Zustellung (Exactly-Once-Semantik)
- Transformationsschicht — Python-Microservices zur Transformation des relationalen Modells in das Cosmos-DB-Dokumentenmodell
- Cosmos DB Writer — optimierter Bulk-Writer mit Retry-Logik und Backpressure-Management
Die Pipeline verarbeitete durchschnittlich 50.000 Änderungen pro Minute mit einer End-to-End-Latenz unter 500ms.
Parallele Validierung¶
Ein Schlüsselelement der Migration war ein paralleles Validierungssystem, das kontinuierlich Daten in beiden Systemen verglich:
- Prüfsummen-Validierung — laufender Hash-Vergleich von Datenblöcken zwischen Oracle und Cosmos DB
- Geschäftsregel-Validierung — automatisierte Konsistenzprüfungen (Saldosummen, Transaktionszählungen, Aggregate)
- Stichprobenbasierte Tiefenvalidierung — zufällige Stichproben und detaillierter Vergleich einzelner Datensätze
- Reconciliation Engine — automatische Identifikation und Korrektur von Abweichungen
Das Validierungssystem lief während der gesamten Migration ununterbrochen und erstellte tägliche Konsistenzberichte.
Rollback-Strategie¶
Für jede Phase der Migration existierte ein detaillierter Rollback-Plan:
- Phase 1 — historische Daten — Einweg-Migration mit der Möglichkeit, auf das Oracle-Backup zurückzugreifen
- Phase 2 — Dual-Write — beide Systeme akzeptieren Schreibvorgänge parallel; das Umschalten der Lesezugriffe ist sofort möglich
- Phase 3 — Cutover — Cosmos DB wird zum Primärsystem; Oracle bleibt 30 Tage als Read-Only-Fallback
Bei jedem Problem war ein Rückschalter auf Oracle innerhalb von 5 Minuten möglich.
Stufenweise Migration¶
Die Migration erfolgte in 4 Wellen über 18 Monate:
- Welle 1 — historische Transaktionen älter als 5 Jahre (80M Datensätze) — geringes Risiko, Validierung der Zugriffsmuster
- Welle 2 — Transaktionen 1–5 Jahre alt (70M Datensätze) — mäßig aktive Daten, Leistungsvalidierung
- Welle 3 — Transaktionen unter 1 Jahr (40M Datensätze) — aktive Daten, Dual-Write-Aktivierung
- Welle 4 — Live-Cutover (10M aktive Datensätze) — Umstellung auf Cosmos DB als Primärsystem
Ergebnisse¶
60 % Kostenreduzierung¶
Die Eliminierung der Oracle-Lizenzen und der Wechsel zum Pay-per-Request-Modell von Cosmos DB brachten jährliche Einsparungen von 60 % im Vergleich zum vorherigen Zustand. Elastische Leistung bedeutet, dass der Kunde nur für tatsächlich verbrauchte Ressourcen bezahlt.
3× schnellere Abfragen¶
Das für Anwendungszugriffsmuster optimierte Dokumentenmodell brachte dramatische Beschleunigungen. Abfragen, die auf Oracle Hunderte von Millisekunden dauerten, laufen nun unter 30ms. Aggregationsabfragen für das Reporting verbesserten sich um das 5-Fache.
99,99 % Verfügbarkeit während der Migration¶
Während der gesamten 18-monatigen Migration gab es keine Dienstausfallzeit. Die Kunden der Bank bemerkten keine Änderung der Verfügbarkeit oder Leistung. Alle Umschaltungen erfolgten transparent.
Grundlage für Modernisierung¶
Die neue Datenplattform auf Cosmos DB ebnete den Weg für weitere Modernisierung — Echtzeit-Analytik, Event-Driven-Architektur und globale Datenverteilung für zukünftige Expansion.