performance_benchmarks - makr-code/ThemisDB GitHub Wiki

Performance & Benchmarks

Dieser Leitfaden konsolidiert die wichtigsten Performance-Themen und Microbenchmarks in ThemisDB: Kompression, Pagination, MVCC vs. WriteBatch, Index-Rebuilds und Vector-Suche. Er beschreibt Messmethodik, Interpretation und konkrete Tuning-Empfehlungen.

Ziele und Erfolgsmetriken

Schreibrate und -latenz unter realistischen Index-Setups
Leselatenzen für typische Abfragepfade (Equal/Range/Cursor)
Speicherbedarf und Write Amplification unter verschiedenen Kompressionsmodi
Rebuild-/Reindex-Durchsatz und Fortschrittsmetriken
Vector-Suche: Latenz vs. Genauigkeit (HNSW efSearch)

Methodik

Alle Microbenchmarks basieren auf Google Benchmark und laufen isoliert mit reproduzierbaren Seeds.
Ergebnisse hängen stark von Hardware, OS, Compiler und Cache-Zustand ab; mehrere Läufe und Mittelwerte bilden.
Metriken über Prometheus (/metrics) und RocksDB Properties ergänzen (z. B. SST-Größen, Compactions).

Benchmarks ausführen (optional)

Hinweis: Beispiel für Windows PowerShell, Release-Build und aktivierte Benchmarks.

# Im Build-Ordner (falls nicht vorhanden, erzeugen)
cmake -S .. -B . -DCMAKE_BUILD_TYPE=Release -DTHEMIS_BUILD_BENCHMARKS=ON
cmake --build . --config Release --parallel

# Alle Benchmarks
.\Release\themis_benchmarks.exe --benchmark_repetitions=3

# Nur Pagination
.\Release\themis_benchmarks.exe --benchmark_filter=BM_Pagination_.*

# Nur CRUD/MVCC
.\Release\themis_benchmarks.exe --benchmark_filter=CRUDFixture|MVCCFixture

Siehe auch: spezifische Seiten unten für Filter und Setups.

Kompression: none vs lz4 vs zstd

Quelle: benchmarks/bench_compression.cpp, Dokumentation: Kompressionsvalidierung & Benchmarks

Kernaussagen (aus Messungen):

Kleine Entities (≤ 1 KB): lz4/zstd oft schneller als none (I/O-Reduktion > CPU-Overhead)
Mittlere Größen (~4 KB): ähnlich; zstd minimal besser bei hoher Kompressibilität
Große Blobs (≥ 16 KB): none schneller (CPU-Kosten der Kompression dominieren)
Reads (warm cache): none am schnellsten; in I/O-limitierten Szenarien kann Kompression dennoch helfen

Empfohlene Hybrid-Konfiguration:

"compression": {
  "default": "lz4",
  "bottommost": "zstd"
}

Write Amplification einschätzen und messen:

SST-Größe reduziert Kompaktionsarbeit → geringere Write Amplification bei kompressiblen JSON
Exakt messen über RocksDB GetProperty("rocksdb.total-sst-files-size") vor/nach Workloads

Weitere Details und Tabellen: siehe compression_benchmarks.md

Pagination: Offset vs Cursor (Anchor)

Quelle: benchmarks/bench_query.cpp, Dokumentation: Pagination Benchmarks

Offset: Aufwand wächst linear mit dem Offset (Index traversiert alle Einträge bis zur Seite)
Cursor/Anchor: konstante Arbeit pro Seite via start-after (cursor_value, cursor_pk) und LIMIT count+1
Praxisempfehlung: Cursor-Pagination für große Datenmengen; siehe Cursor/Pagination für API/Beispiele

Optional reproduzieren:

.\Release\themis_benchmarks.exe --benchmark_filter=BM_Pagination_.*

MVCC vs WriteBatch und CRUD-Durchsatz

Quelle: benchmarks/bench_mvcc.cpp, benchmarks/bench_crud.cpp

MVCC (Transaction) bietet Snapshot-Isolation und komfortable Rollbacks; leichter Overhead vs. WriteBatch
WriteBatch ist minimal schneller bei Bulk-Inserts, aber ohne Isolation/Locks
Indexschwere Workloads (mehrere Sekundärindizes) skalieren besser mit Batching (100+ pro Commit)

Empfehlungen:

Einzel- und kleine Writes: MVCC für Korrektheit, besonders bei parallelen Reads
Bulk-Import: WriteBatch nutzen, WAL optional deaktivieren, danach flush()
Allgemein: Batches von 100–1000 Entities für Throughput optimieren

Index-Rebuilds und Reindex

Quelle: benchmarks/bench_index_rebuild.cpp, Dokumentation: Index-Statistiken & Wartung

Rebuild pro Index-Typ (Regular/Composite/Range/Sparse/Geo/TTL/Fulltext) separat messbar
Gesamt-Reindex pro Tabelle berücksichtigt alle Indizes; IO- und CPU-limitierte Phasen möglich
Fortschritt über Prometheus-Metriken und interne Counters beobachten

Wichtige Metriken (Auswahl):

themis_index_rebuild_count, themis_index_rebuild_duration_ms_total
themis_index_rebuild_entities_processed_total
themis_index_cursor_anchor_hits_total, themis_index_range_scan_steps_total

Vector-Suche (HNSW) Tuning

Voraussetzung: Build mit HNSW (THEMIS_HNSW_ENABLED). Konfiguration siehe Deployment:

engine: "hnsw"
hnsw_m: Nachbarschaftsgrad (Speicher/Genauigkeit)
hnsw_ef_construction: Aufbau-Qualität (Indexierzeit/Genauigkeit)
Laufzeit-Tuning: setEfSearch(ef) steigert Recall mit mehr Sucharbeit (höhere Latenz)