LevelDB

Wenn du eine kleine, eingebettete DB brauchst und RocksDB zu "fett" (zu viele Dependencies/Complexity) ist. In Go Apps oft beliebt (goleveldb). Oder wenn du Blockchain-Nodes betreibst (Ethereum/Bitcoin).

1. Levels

Der Name kommt von der Struktur:

• MemTable (RAM).
• Level 0 (Frische Daten auf Disk, unsortiert).
• Level 1 (Sortiert, 10 MB).
• Level 2 (Sortiert, 100 MB). Daten "fließen" wie ein Wasserfall von oben nach unten. Je tiefer, desto älter und kompakter.

2. Snappy

LevelDB nutzt standardmäßig Snappy Compression (auch von Google). Es komprimiert nicht maximal (wie GZIP), aber extrem schnell. Das ist wichtig, um die CPU nicht beim Schreiben zu blockieren.

1. Write Amplification und SSTable Compaction Penalty

Das brutale Manko der ursprünglichen LevelDB Architektur wird zur "Write Amplification" zusammengefasst. Nehmen wir an, LevelDB empfängt intensive Schreib-Ops, die kontinuierlich Level 0 (die reinen MemTable Disk-Flushes) füllen. Sobald L0 sein Limit erreicht, erzwingt die Engine eine Minor Compaction auf Level 1, die sofort zu Kaskaden (Major Comapctions) nach Level 2 und 3 eskalieren kann. Da eine SSTable im klassischen LevelDB bei jedem Merger-Durchlauf komplett gelesen, entsorgt (Tombstones) und bitgenau im neuen Level wieder sequenziell heruntergeschrieben wird, führt ein 1 MB Write am Input oftmals zu 15 MB physikalischem SSD Disk-I/O! Ab der 100-Mio-Keys Grenze führt dieses sture, single-threaded Background-Merging teils dazu, dass die Datenbank "stehen bleibt" (Write Stalls), da L0 voll ist und LevelDB jegliche INSERTS des Nutzers hart blockiert.

2. Log-Structured Caching (BlockCache vs OS Cache)

Lese-Zugriffe wandern in LevelDB erst durch MemTable, dann von oben durch die O(1)-Levels der Disk. Da Festplatten-IO vernichtend langsam ist, setzt das System aggressives Caching ein. Die Daten sitzen im komprimierten "Table Cache" (File Descriptor/Header), gepuffert primär über den System/OS-Page Cache des Linux Kernels. Dazu kommt ein unkomprimierter Block Cache von LevelDB. Der LevelDB-Code holt aus der SSD stets 4KB Blöcke, dekomprimiert sie (snappy dec) und verwaltet sie im eigenen Userspace RAM (LRUCache). Ein Performance-Gotcha in Produktion: Admin-Speicher-Zuweisungen müssen die OS-Page-Cache Reservierung extrem vorsichtig neben dem Heap der Applikation balancieren. Wenn das Python-Programm 90% Host-RAM frisst, swapped LevelDB seinen Block-Cache qualvoll auf Disk um und killt die Get()-Latenz in den Boden.

3. Snappy CRC32 und Zero-Tearing (WAL)

LevelDB glänzt mit absoluter Datenintegrität bei Crash-Systemen. Die Festplatte protokolliert alles im Voraus in das Write-Ahead Log (WAL). Aber was, falls beim Schreiben eines JSON-Blobs bei 50% der Strom ausfällt (Torn Write)? Das WAL besitzt extrem robuste Integritäts-Mechanismen. Jeder Chunk in der binären LevelDB WAL Log-Datei ist akribisch in 32-KB Blöcke ge-chunked und streng mit einem CRC32C Header versehen. Startet Googles Chrome Browser (IndexedDB), scannt LevelDB beim Boot das File. Der Checksummen-Verification-Test zerlegt exakt dort defokussiert das WAL-Log, wo das letzte saubere Byte lag, schneidet Korruptionen gnadenlos ab und baut die MemTable zum letzten nanosekundengenauen Atom-Commit-Zustand auf, völlig immun gegen halb-verschmierten Platten-Müll.