# Kompressionsvalidierung und Benchmarks

**Stand:** 5. Dezember 2025  
**Version:** 1.0.0  
**Kategorie:** Performance

---


**Datum:** 27. Oktober 2025  
**System:** Windows 11, MSVC 19.44, 20 CPU cores @ 3.7 GHz

## Validierung

Die Kompression wurde zur Laufzeit verifiziert:
- **none:** `default=none, bottommost=none`
- **lz4:** `default=lz4, bottommost=lz4`
- **zstd:** `default=zstd, bottommost=zstd`

RocksDB nutzt die in vcpkg.json aktivierten Features (`lz4`, `zstd`) korrekt.

## Benchmark-Ergebnisse

### Sequential Write (1000 keys per iteration)

| Compression | Blob Size | Time/Iter | Throughput (MB/s) | Items/s |
|-------------|-----------|-----------|-------------------|---------|
| none        | 512B      | 23.6 ms   | 22.7 MB/s         | 46.4k   |
| **lz4**     | 512B      | 22.0 ms   | 24.1 MB/s         | 49.3k   |
| **zstd**    | 512B      | 21.9 ms   | 25.6 MB/s         | 52.5k   |
| none        | 4KB       | 29.7 ms   | 147.7 MB/s        | 37.8k   |
| **lz4**     | 4KB       | 31.2 ms   | 141.0 MB/s        | 36.1k   |
| **zstd**    | 4KB       | 31.6 ms   | 148.6 MB/s        | 38.1k   |
| none        | 16KB      | 49.8 ms   | 348.8 MB/s        | 22.3k   |
| **lz4**     | 16KB      | 54.1 ms   | 289.5 MB/s        | 18.5k   |
| **zstd**    | 16KB      | 53.4 ms   | 294.1 MB/s        | 18.8k   |

### Random Read (warm cache, 1000 pre-populated keys)

| Compression | Blob Size | Latency (µs) | Items/s   |
|-------------|-----------|--------------|-----------|
| none        | 4KB       | 2.32         | 434k      |
| **lz4**     | 4KB       | 2.63         | 383k      |
| **zstd**    | 4KB       | 2.61         | 412k      |

## Interpretation

### Write Performance
- **Kleine Blobs (512B):**  
  ZSTD und LZ4 **schneller** als `none` (~7-13% Verbesserung). Die Kompression reduziert I/O und Write Amplification stärker als die CPU-Kosten wiegen.
  
- **Mittlere Blobs (4KB):**  
  Alle drei Varianten ähnlich (~147 MB/s). ZSTD minimal schneller bei hoher Kompressibilität.

- **Große Blobs (16KB):**  
  `none` **deutlich schneller** (+20% gegenüber LZ4/ZSTD). CPU-Kosten für Kompression überwiegen I/O-Einsparungen bei großen Payloads.

### Read Performance
- LZ4 und ZSTD fügen ~14% Latenz hinzu (Dekompressions-Overhead).
- Bei Cache-Hits (reiner memcpy) ist `none` am schnellsten.
- Im realen Betrieb mit Disk-I/O kann Kompression durch geringere Datenmengen schneller sein.

## Empfehlungen

1. **Für hohen Write-Throughput mit kleineren Entities (< 1KB):**  
   → **ZSTD** (default) oder **LZ4** (bottommost) nutzen

2. **Für große BLOBs (> 8KB) oder read-heavy Workloads:**  
   → **LZ4** für Reads mit weniger Latenz; oder **none** für maximalen Read-Durchsatz

3. **Hybrid-Konfiguration (empfohlen):**
   ```json
   "compression": {
     "default": "lz4",
     "bottommost": "zstd"
   }
   ```
   Frische Daten (L0) mit LZ4 schnell komprimiert; ältere Levels (bottommost) mit ZSTD platzsparend.

## Write Amplification

Ohne direkte Messung lässt sich aus den Benchmarks ableiten:
- Kompression reduziert SSTable-Größe → weniger Compaction-Aufwand
- Bei kompressiblen JSON-Daten (Faktor ~3-5x) führt Kompression zu **niedrigerer Write Amplification**

Für genaue Werte: RocksDB-Property `rocksdb.total-sst-files-size` vor/nach Schreibvorgängen prüfen.

## Nächste Schritte

- [ ] Write Amplification mit RocksDB `GetProperty("rocksdb.total-sst-files-size")` messen
- [ ] Disk-I/O Benchmarks (cold cache) mit verschiedenen Kompressionen
- [ ] Speicherplatzvergleich nach 10k/100k Entities