Du brauchst einen nächtlichen Job, der zwanzig Millionen Zeilen liest, transformiert und Ergebnisse schreibt. Wie schreibst du ihn, damit er den Speicher nicht sprengt?

Streamen statt materialisieren: lies mit einem scrollbaren Cursor oder Keyset-Paging, setz eine Fetch Size, damit der Treiber nicht alles puffert, und verarbeite in Chunks mit einem Commit pro Chunk. Nutzt du JPA, leer den Persistence Context zwischen den Chunks oder nimm eine Stateless Session, sonst bleibt jede Entity im First Level Cache. Batche die Schreibzugriffe mit JDBC Batching und mach den Job vom letzten committeten Chunk aus neu startbar.

Die Kernregel ist, dass kein Schritt zwanzig Millionen von irgendetwas hält. Ich lese mit Keyset-Paging auf dem Primärschlüssel oder mit einem scrollbaren Cursor mit expliziter Fetch Size, und man sollte wissen, dass manche Treiber das ignorieren und das gesamte Result Set puffern, solange man nicht zusätzlich in einer Transaktion mit ausgeschaltetem Autocommit läuft, was Leute schmerzhaft entdecken, wenn der Heap voll ist, bevor die Verarbeitung überhaupt beginnt. Dann verarbeite ich in Chunks von ein paar tausend, schreibe mit JDBC Batching, damit es ein Roundtrip pro Chunk ist statt pro Zeile, und committe pro Chunk. Bei JPA kommt die zusätzliche Falle mit dem Persistence Context: jede gelesene Entity bleibt managed, der Speicher wächst also und Flushes werden langsamer, weil das Dirty Checking mehr Objekte durchläuft. Ich leere ihn pro Chunk oder nehme eine Stateless Session. Neustartbarkeit zählt genauso viel wie Speicher, der Job merkt sich also den letzten committeten Schlüssel, ein Fehler bei Zeile achtzehn Millionen setzt also fort statt neu zu starten. Und ich drossle ihn, denn ein Batch-Job, der die Datenbank um zwei Uhr nachts sättigt, trifft trotzdem alle, die wach sind.