Multi-Datenbank-Replikation mit 2 GB RAM — Case Study

Problem

Replikation großer Krankenhaus-Datensätze über Oracle, MSSQL, MySQL und PostgreSQL hinweg — mit hartem 2-GB-RAM-Budget, ohne Datenverlust oder Inkonsistenzen.

Lösung

Streaming-Read- und Batched-Write-Pipeline in Spring Boot mit quellenspezifischem Connection-Tuning und sorgfältigem JDBC-Cursor-Management — zuverlässige Cross-Vendor-Replikation in engen Speichergrenzen.

Architektur

$ render architecture.mmd

flowchart LR
  subgraph SRC[Hospital Sources]
    O[(Oracle)]
    M[(MSSQL)]
    MY[(MySQL)]
  end
  SRC --> Reader[Streaming Reader<br/>JDBC cursor]
  Reader --> Buf{{Bounded Buffer<br/>backpressure}}
  Buf --> Mapper[Schema Mapper<br/>Spring Boot]
  Mapper --> Writer[Batched Writer]
  Writer --> PG[(PostgreSQL<br/>warehouse)]
  Mapper -. metrics .-> Mon[Health · Prometheus]
  classDef src fill:#0c4a6e,stroke:#0ea5e9,color:#fff
  classDef pg fill:#14532d,stroke:#22c55e,color:#fff
  class O,M,MY src
  class PG pg

Technische Entscheidungen

$ git log --oneline decisions/

#01

Streaming-Reads statt Full-Loads

JDBC fetchSize pro Vendor abgestimmt (Oracle 500, MSSQL 1000, MySQL Forward-Only-Cursor) — Speicher wuchs nicht mit der Tabellengröße.

#02

Bounded Buffer mit Backpressure

Eine fixe Queue zwischen Reader und Writer verhinderte JVM-Heap-Überlauf bei langsamerem PostgreSQL-Sink.

#03

Batched Writes, deterministische Commits

500-Zeilen-Batches mit expliziten Transaktionen und Idempotency-Keys — sichere Replays nach Crashes, keine Duplikate.

#04

Schema-Mapping pro Quelle

Typ-Eigenheiten je Vendor isoliert (Oracle NUMBER, MSSQL DATETIME2, MySQL JSON) — keine undichte gemeinsame Abstraktion.

Ähnliche Herausforderung?

Lass uns sprechen