RocksDB

Wenn du Java/Go/Rust entwickelst und lokalen State brauchst (Stateful Stream Processing). Du speicherst "Key=User123, Value=JSON". RocksDB kümmert sich um Caching, Compaction (Aufräumen) und Crash Recovery. Es ist viel komplexer zu tunen als SQLite, aber viel schneller bei massiven Datenmengen (Terabytes).

1. Write Amplification vs Read Amplification

Da RocksDB auf LSM-Trees basiert (Immutable Files), muss es Daten oft kopieren (Compaction). Das nennt man Write Amplification (1 MB User-Data -> 10 MB Disk-Write). Man kann RocksDB tunen:

• Leveled Compaction: Minimiert Platz (gut für Read), erhöht Write Amp.
• Universal Compaction: Minimiert Write Amp (gut für Write), braucht mehr Platz. Es gibt hunderte Parameter (Memtable Size, Bloom Filter Bits, Block Cache).

2. Prefix Seek

RocksDB speichert Keys sortiert. Das erlaubt Seek("User:123:"). Man kann sehr effizient Ranges scannen. Das macht es ideal für Time-Series oder Graph-DBs (die Kanten als Keys speichern).

1. LSM-Tree Architecture & SSTables

Im Herzen von RocksDB rotiert der Log-Structured Merge-Tree (LSM). Alle neuen Daten (Puts) wandern zuerst blitzschnell ins RAM (in eine MemTable). Ist das RAM voll ($64\text{ MB}$), friert RocksDB die MemTable ein und flushst sie als persistente Datei auf die SSD. Diese unveränderliche Datei ist eine SSTable (Sorted String Table). Die SSD erfährt so nur große, sequenzielle Bursts ($64\text{ MB}$ auf einmal), was für NAND-Flash extrem schonend und schnell ist. Das Problem: Wenn du nun foo suchst, musst du in allen SSTables auf der SSD kramen. Deshalb durchdringt RocksDB den Speicher mit Leveln ($L0, L1, \dots L6$). L0 hat keine Sortiergarantie über Files hinweg, ab L1 existieren keine Keys doppelt in verschiedenen Dateien. Eine Lesesuche durchbohrt das System von RAM bis $L6$, bis der Key matcht. Ein gelöschter Key wird nicht gelöscht! Er bekommt einen "Tombstone" (Grabstein) geschrieben, der den Lesevorgang abfängt und $NULL$ zurückgibt.

2. The Compaction Tax (Tombstone Hell)

Die SSTables müllen langsam das Dateisystem voll (Updates, Tombstones). Ein Background-Thread muss zwingend Compaction durchführen. Er nimmt 4 SSTables aus $L1$, lädt sie ins RAM, mergt sie sortiert zusammen, wirft Tombstones weg und speichert 1 große Datei in $L2$. Hier entstehen massive Production-Gotchas: Die "Write Amplification". Um 1 Byte netto zu aktualisieren, bewegt die DB durch das Level-Merging bis zu 30 Byte auf der I/O-Pest (Disk). Wenn die Load auf einer Kafka-Stream Applikation explodiert, frisst der Compaction-Daemon (Merge) alle SSD-IOPS auf. Die Datenbank beginnt "Stalling" (künstliches Ausbremsen der eingehenden RAM-Requests), da sonst das Memory überläuft. Die Latenz schießt von 2ms auf 500ms (!), bis die Disk hinterherkommt.

3. Read Amplification & Blühende Bloom Filter

Ein Read auf Key $X$ ist im Worst-Case verheerend: Die CPU müsste $5\text{ GB}$ an L1- bis L6-Files auf der SSD anfassen und durchsuchen, nur um festzustellen: "Key $X$ existiert gar nicht". Die Rettung ist der Bloom Filter, ein In-Memory-Array (meist 10 Bit pro Key). Bevor RocksDB die SSD anfasst, fragt es den Filter im RAM. Sagt der Filter False, überspringt RocksDB die SSD-Datei sofort – es weiß deterministisch, die Daten sind nicht dort. Sagt er True, könnte der Key darin sein (False Positives sind typisch bei Hashes). Der Bloom Filter senkt SSD Read-Loads (Read Amplification) dramatisch, frisst aber sehr viel Headroom im RAM des Systems auf, der ansonsten dem Block-Cache gegönnt wäre.