Große Dateien: Chunking-Pattern

1. Einführung

In der modernen Welt wachsen Daten schneller als Pilze nach dem Regen. Manchmal hat man es mit Dateien im Umfang von Dutzenden oder sogar Hunderten Gigabyte zu tun – das können Logdateien, Datenbank-Dumps oder riesige Archive sein. Der Versuch, eine solche Datei vollständig in den Speicher zu laden, endet meist schlecht: Das Programm „frisst“ entweder den gesamten Arbeitsspeicher (RAM) oder wird quälend langsam.

Die Gründe liegen auf der Hand. Der Arbeitsspeicher ist nicht unendlich, und wenn die Datei dessen Kapazität übersteigt, riskieren Sie einen OutOfMemoryError. Selbst wenn der Speicher reicht, kann das sequentielle Lesen und Verarbeiten einer gigantischen Datei in einem einzigen Thread Stunden dauern. Hinzu kommt die Begrenzung des Datenträgers selbst: Seine Lesegeschwindigkeit ist fix – aber mit mehreren Threads, insbesondere auf SSDs, lässt sich der Prozess spürbar beschleunigen.

Darum lautet die wichtigste Erkenntnis: Große Dateien sollte man stückweise verarbeiten, in sogenannten Chunks, und dies nach Möglichkeit parallel. Genau dieser Ansatz ermöglicht die Arbeit mit Gigabytes an Daten ohne unnötige Qualen.

2. Lösung: Chunking-Pattern

Chunking ist ein Pattern, bei dem eine große Datei in kleine, gut beherrschbare Stücke (Chunks) zerlegt wird, die unabhängig voneinander verarbeitet werden können.

Analogie:
Anstatt eine ganze Wassermelone auf einmal zu essen, schneiden Sie sie in Scheiben und essen eine nach der anderen. So ist es einfacher und schneller!

Wie funktioniert das?

1. Ermittlung der Dateigröße.
   • Mit File.length() oder Files.size(Path) ermitteln wir, wie viele Bytes die Datei hat.
2. Berechnung der Chunk-Größe (chunk size).
   • Üblich sind 10–20 MB (mehr oder weniger – abhängig von Aufgabe und Hardware).
   • Die Chunk-Größe speichert man sinnvollerweise in der Variablen chunkSize und wählt sie möglichst als Vielfaches der Blockgröße des Datenträgers für maximale Performance.
3. Erstellen einer Aufgabenliste.
   • Jede Aufgabe ist die Verarbeitung eines Chunks: Lesen, Parsen, Verschlüsseln, Komprimieren usw.
   • Die Aufgaben können parallel gestartet werden, indem man einen Thread-Pool nutzt.

Visualisierung:

+-------------------+
|       Datei       |
+-------------------+
|  [chunk 1]        |
|  [chunk 2]        |
|  [chunk 3]        |
|  ...              |
|  [chunk N]        |
+-------------------+

3. Parallele Verarbeitung implementieren

Verwendung von ExecutorService oder ForkJoinPool

Um Chunks parallel zu verarbeiten, verwenden Sie die Standard-Multithreading-Werkzeuge von Java:

• ExecutorService – ein Thread-Pool fester Größe (Executors.newFixedThreadPool(n)).
• ForkJoinPool – für rekursive Aufgaben und den Divide-and-Conquer-Ansatz.

Beispiel:

ExecutorService pool = Executors.newFixedThreadPool(4); // 4 Threads

for (int i = 0; i < chunkCount; i++) {
    final int chunkIndex = i;
    pool.submit(() -> {
        processChunk(file, chunkIndex, chunkSize);
    });
}

pool.shutdown();
pool.awaitTermination(1, TimeUnit.HOURS);

Jede Aufgabe liest ihren eigenen Chunk und verarbeitet ihn unabhängig.

4. Zentrale Mechanismen: RandomAccessFile und FileChannel

RandomAccessFile

RandomAccessFile ermöglicht es, innerhalb der Datei zu „springen“ und ab einer gewünschten Position zu lesen.

try (RandomAccessFile raf = new RandomAccessFile(file, "r")) {
    raf.seek(chunkStart); // Zum Beginn des Chunks springen
    byte[] buffer = new byte[chunkSize];
    int bytesRead = raf.read(buffer);
    // Puffer verarbeiten
}

• seek(long pos) – verschiebt den „Cursor“ an die gewünschte Position.
• Es lassen sich nur die benötigten Bytebereiche lesen.

FileChannel

FileChannel ist eine modernere und schnellere Methode (insbesondere für große Dateien).

try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
    ByteBuffer buffer = ByteBuffer.allocate(chunkSize);
    channel.position(chunkStart);
    int bytesRead = channel.read(buffer);
    // Puffer verarbeiten
}

• position(long newPosition) – setzt die Leseposition.
• Man kann nur den benötigten Bereich lesen, ohne den Rest der Datei anzutasten.

5. Vergleich: Chunking vs. transferTo/transferFrom

transferTo/transferFrom

Die Methoden FileChannel.transferTo() und transferFrom() ermöglichen sogenanntes Zero-Copy. Die Idee ist einfach: Daten können direkt zwischen Dateien und Streams kopiert oder verschoben werden, ohne JVM-Puffer zu durchlaufen. Das macht Operationen sehr schnell. Die einzige Einschränkung: Daten lassen sich dabei nicht „on the fly“ verändern, sondern nur kopieren – für viele Aufgaben beschleunigt dieser Ansatz die Arbeit mit großen Datenmengen dennoch deutlich.

Beispiel:

try (FileChannel src = FileChannel.open(srcPath, READ);
     FileChannel dst = FileChannel.open(dstPath, WRITE)) {
    src.transferTo(0, src.size(), dst);
}

Chunking

Chunking ist eine Methode, große Dateien stückweise, also in Chunks, zu bearbeiten. Sie dient nicht nur zum Kopieren von Daten, sondern auch zu deren Verarbeitung: Man kann währenddessen parsen, verschlüsseln, komprimieren oder Informationen suchen. Jeder Chunk der Datei lässt sich unabhängig verarbeiten und bei Bedarf sogar parallel, was die Arbeit deutlich beschleunigt.

Die Idee ist einfach: Wenn die Aufgabe auf reines Kopieren hinausläuft, sollte man transferTo oder transferFrom verwenden – die Daten bewegen sich direkt, schnell und ohne unnötige Kopien. Wenn jedoch der Inhalt verarbeitet werden muss – suchen, ändern, analysieren –, ist Chunking unverzichtbar.

6. Einschränkungen und Stolpersteine

Overhead durch Threads

• Zu viele Threads können die Performance senken (Kontextwechsel, Ressourcen­konkurrenz).
• In der Regel wählt man die Zahl der Threads gleich oder leicht größer als die Anzahl der CPU-Kerne.

Begrenzungen des Datenträgers

• Auch mit 100 Threads kann ein Datenträger nicht schneller lesen als seine maximale Geschwindigkeit.
• Bei SSDs kann paralleles Lesen einen Gewinn bringen, bei HDDs – fast keinen.

Notwendigkeit der Synchronisation

• Wenn die Verarbeitung der Chunks unabhängig ist – alles einfach.
• Wenn ein Gesamtergebnis aggregiert werden muss (z. B. die Summe aller Zahlen in der Datei), muss der Zugriff auf gemeinsame Variablen synchronisiert werden (z. B. AtomicLong nutzen oder Ergebnisse in einer separaten Liste sammeln).

Chunk-Grenzen

• Bei Textdateien ist Vorsicht geboten: keine Zeile oder kein Zeichen in der Mitte zerschneiden.
• Bei Binärdateien (Archive, Bilder) kann man in der Regel beliebig schneiden.
• Für Textdateien macht man häufig eine „Überlappung“ der Chunks oder sucht den nächsten Zeilenumbruch.

7. Beispiel: Paralleles Summieren von Zahlen in einer großen Datei

Aufgabe:
Es gibt eine Datei mit Millionen Zahlen (jeweils eine pro Zeile). Die Summe soll schnell berechnet werden.

Schritt-für-Schritt-Plan:

1. Die Dateigröße ermitteln.
2. Die Chunk-Größe wählen (z. B. 10 MB).
3. Für jeden Chunk:
   • Den nächsten Zeilenumbruch finden (um keine Zahl zu zerschneiden).
   • Chunk lesen, Zahlen parsen, Summe berechnen.
4. Die Summen aller Chunks aggregieren.

Code-Skelett:

ExecutorService pool = Executors.newFixedThreadPool(4);
List<Future<Long>> results = new ArrayList<>();

for (int i = 0; i < chunkCount; i++) {
    final int chunkIndex = i;
    results.add(pool.submit(() -> {
        // RandomAccessFile öffnen, Chunk-Grenzen ermitteln
        // Lesen, Zahlen parsen, Summe berechnen
        long chunkSum = 0L;
        return chunkSum;
    }));
}

long total = 0;
for (Future<Long> f : results) {
    total += f.get();
}
pool.shutdown();
System.out.println("Summe: " + total);

8. Fazit und Best Practices

• Chunking ist ein universelles Pattern für die Verarbeitung großer Dateien: in Chunks aufteilen, unabhängig verarbeiten, Ergebnis zusammenführen.
• Verwenden Sie RandomAccessFile oder FileChannel zum Lesen ab einer gewünschten Position.
• Für parallele Verarbeitung – ExecutorService oder ForkJoinPool.
• Für Kopieren ohne Verarbeitung – transferTo/transferFrom (Zero-Copy) nutzen.
• Behalten Sie Chunk-Größen, Thread-Anzahl und Grenzen des Datenträgers im Blick.
• Bei Textdateien – Zeilengrenzen sorgfältig behandeln.
• Bei Binärdateien kann man in der Regel beliebig schneiden, sofern das Format keine Besonderheiten hat.

9. Häufige Fehler beim Umgang mit Chunking

Fehler Nr. 1: Zu große Datei. Sie versuchen, die gesamte Datei in den Speicher zu lesen – Ergebnis ist ein OutOfMemoryError.

Fehler Nr. 2: Zu viele Threads. Sie erstellen zu viele Threads – das System wird durch Kontextwechsel und Konkurrenz um Ressourcen ausgebremst.

Fehler Nr. 3: Zeilen zerschnitten. Zeilengrenzen in Textdateien werden ignoriert – das führt zu „zerrissenen“ Zeilen und Parse-Fehlern.

Fehler Nr. 4: Methoden falsch eingesetzt. Sie versuchen, transferTo/transferFrom zur Datenverarbeitung zu nutzen – das funktioniert nicht, diese Methoden sind nur zum Kopieren.

Fehler Nr. 5: Synchronisation vergessen. Die Aggregation der Ergebnisse wird nicht synchronisiert – das führt zu falschen Summen oder anderen Bugs.

Fehler Nr. 6: Ressourcenleck. Dateien/Kanäle werden nicht geschlossen – es kommt zu Ressourcenlecks.