2026-09-03 AWS Benchmark Report
ベンチマークレポート生成パイプライン刷新後の初回計測。--without-rivals: RocksDB/RocksDB-BlobDB/LMDBは2026-08-27の数値を再利用(0828のデータは本パイプライン刷新の一環として削除済み)。Summary tabを大幅簡素化し、reorganize()/checkpoint()の固定コーパス(1KB×1,000万件)計測をbackground jobsテーブルとして新設。コード側の変更はなし(defragment実験・旧probe関連コードの整理、title/h1置換バグ修正のみ)。
Stacking Variants
各最適化の詳細は Design Document を参照。
- RocksDB: LSM-Tree のベースライン比較
- LMDB: B+Tree / mmap ベースの比較対象
- RocksDB-BlobDB: RocksDB の Blob 分離ストレージ変種(大きな Value 向け)
- Baseline: vmemkv 最適化なし
- +BF: + T1 Bloom Filter
- +Inline: +BF + T1 Inline Value(<8B のValueをT1のみで処理)
- +Prefault: +Inline + T2 Async Prefaulting(全部盛り、= VMemKVStore)。旧
ScanBaseSequentialアブレーションは実測の結果撤去され、その最適化(base領域専用mmap経路)はGet/Scan双方の標準パスへ無条件で統合済み。
Environment
AWS i4i.8xlarge (32 vCPU, local NVMe), 5-parallel spot instances (in_memory:8B/1KB, ltm:1KB/64KB, background-jobs-probe専用インスタンス), Ubuntu 24.04, Release -O3 -march=native.
Workloads
- Insert: 順次挿入(1/4/16/32 スレッド)
- Get Hit/Miss (Zipf/Uniform): ポイントルックアップ
- Update / Delete: Zipf 分布での更新・削除
- Scan (Zipf/Uniform): レンジスキャン(旧レポートにあった reorganize モード分割は撤去済み)
- YCSB-E: 95% Scan + 5% Insert 混合(32スレッド / 30秒タイムライン)
Overall Notes & Annotations
Workload Winners & Relative Speedup
Best VMemKV variant vs. whichever rival (RocksDB, LMDB, RocksDB-BlobDB) is FASTEST at that cell, at 32 threads (max concurrency tested) -- not the best-of-any-thread-count-or-rival figure, since both axes are known to shrink (sometimes invert) the ratio if picked favorably. The rival actually being compared against is named in small text under each badge.
| Workload | 8B In-Memory | 1KB In-Memory | 1KB LTM | 64KB LTM |
|---|---|---|---|---|
| Insert |
✅ WIN (1.71x)
vmemkv (+Inline)
vs RocksDB-BlobDB
|
✅ WIN (1.58x)
vmemkv (+Inline)
vs RocksDB-BlobDB
|
✅ WIN (1.37x)
vmemkv (+BF)
vs RocksDB
|
✅ WIN (1.69x)
vmemkv (Baseline)
vs RocksDB-BlobDB
|
| Update (Zipf) |
✅ WIN (1.51x)
vmemkv (Baseline)
vs RocksDB
|
✅ WIN (1.57x)
vmemkv (+Inline)
vs RocksDB-BlobDB
|
✅ WIN (1.81x)
vmemkv (+BF)
vs RocksDB-BlobDB
|
✅ WIN (3.12x)
vmemkv (+Inline)
vs LMDB
|
| Delete |
✅ WIN (1.71x)
vmemkv (Baseline)
vs RocksDB-BlobDB
|
✅ WIN (1.86x)
vmemkv (+Inline)
vs RocksDB
|
✅ WIN (1.82x)
vmemkv (Baseline)
vs RocksDB
|
✅ WIN (3.93x)
vmemkv (+Inline)
vs RocksDB-BlobDB
|
| Get (Miss) |
✅ WIN (2.67x)
vmemkv (+BF)
vs RocksDB-BlobDB
|
✅ WIN (2.79x)
vmemkv (+BF)
vs LMDB
|
✅ WIN (2.77x)
vmemkv (+BF)
vs LMDB
|
✅ WIN (2.95x)
vmemkv (+BF)
vs RocksDB
|
| Get (Hit, Zipf) |
✅ WIN (1.43x)
vmemkv (+Inline)
vs LMDB
|
✅ WIN (1.26x)
vmemkv (Baseline)
vs LMDB
|
❌ LOSE (0.66x)
vmemkv (+Inline)
vs RocksDB-BlobDB
|
✅ WIN (1.19x)
vmemkv (+Inline)
vs RocksDB
|
| Get (Hit, Uniform) |
WIN (1.10x)
vmemkv (+Inline)
vs LMDB
|
✅ WIN (1.19x)
vmemkv (Baseline)
vs LMDB
|
❌ LOSE (0.84x)
vmemkv (+Inline)
vs RocksDB-BlobDB
|
≈ EVEN (0.99x)
vmemkv (Baseline)
vs RocksDB-BlobDB
|
| Scan (Zipf) |
≈ EVEN (0.96x)
vmemkv (+BF)
vs LMDB
|
WIN (1.06x)
vmemkv (+BF)
vs LMDB
|
WIN (1.13x)
vmemkv (Baseline)
vs RocksDB
|
WIN (1.08x)
vmemkv (+Inline)
vs LMDB
|
| Scan (Uniform) |
LOSE (0.93x)
vmemkv (+Inline)
vs LMDB
|
WIN (1.12x)
vmemkv (+BF)
vs LMDB
|
✅ WIN (1.47x)
vmemkv (Baseline)
vs RocksDB
|
≈ EVEN (0.98x)
vmemkv (Baseline)
vs RocksDB-BlobDB
|
Background Jobs: reorganize() / checkpoint()
Fixed reference point (1KB values, 10,000,000 records; in-memory unconstrained, LTM cgroup-constrained to the same memory budget as the rest of the suite) -- not swept across the CRUD matrix's 4 scenario/value-size combos. Duration is a single call in isolation; the three degradation columns are the percentage drop in concurrent Insert/Update/Scan QPS while that one call runs, measured over a matched-duration window on both sides (see run_background_jobs_probe.sh).
| Job / Scenario | Duration (1 call) | Insert QPS degradation | Update QPS degradation | Scan QPS degradation |
|---|---|---|---|---|
| reorganize() / in-memory | 1.495s | 49% | -6% | 83% |
| reorganize() / LTM | did not complete (timeout) | |||
| checkpoint() / in-memory | 4.193s | 49% | 2% | 27% |
| checkpoint() / LTM | did not complete (timeout) | |||
Insert Workload
Update (Zipf) Workload
Delete (Zipf) Workload
Get Miss (Zipf) Workload
Get Hit (Zipf) Workload
Get Hit (Uniform) Workload
Scan (Zipf) Workload
Scan (Uniform) Workload
YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)
YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。
藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー、全バリアント共通)。
強制トリガーはバリアントごとに独立集計(全バリアント共通の1本の線には集約しない): t=5秒予定のreorganize()(細かい点線)、t=10秒・t=25秒予定のcheckpoint()(粗い点線)を、そのバリアント自身の色+マーカー形状(スキャンQPS線をホバーした際の点と同じ形。凡例のポイント形状も対応)で描画。
実際に発火する秒(線の位置)は予定秒とは限らない(将棋倒しに対するガード無し、書き込み負荷次第で数十秒遅延することがある)。8B In-Memoryのように挿入スループットが極端に高いワークロードでは、t=5秒予定のreorganize()自体が20秒以上かかり、後続のcheckpoint()トリガー(t=10s/25s)がこの30秒間に一度も発火しないまま終わることもある(この場合、線は1本しか出ない)。カーソルを線に合わせると、その秒に発火したバリアント・種類・予定秒・実発火秒・所要時間を表示。
Scan QPS タイムライン
32 threads / 30 secondsInsert Workload
Update (Zipf) Workload
Delete (Zipf) Workload
Get Miss (Zipf) Workload
Get Hit (Zipf) Workload
Get Hit (Uniform) Workload
Scan (Zipf) Workload
Scan (Uniform) Workload
YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)
YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。
藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー、全バリアント共通)。
強制トリガーはバリアントごとに独立集計(全バリアント共通の1本の線には集約しない): t=5秒予定のreorganize()(細かい点線)、t=10秒・t=25秒予定のcheckpoint()(粗い点線)を、そのバリアント自身の色+マーカー形状(スキャンQPS線をホバーした際の点と同じ形。凡例のポイント形状も対応)で描画。
実際に発火する秒(線の位置)は予定秒とは限らない(将棋倒しに対するガード無し、書き込み負荷次第で数十秒遅延することがある)。8B In-Memoryのように挿入スループットが極端に高いワークロードでは、t=5秒予定のreorganize()自体が20秒以上かかり、後続のcheckpoint()トリガー(t=10s/25s)がこの30秒間に一度も発火しないまま終わることもある(この場合、線は1本しか出ない)。カーソルを線に合わせると、その秒に発火したバリアント・種類・予定秒・実発火秒・所要時間を表示。
Scan QPS タイムライン
32 threads / 30 secondsInsert Workload
Update (Zipf) Workload
Delete (Zipf) Workload
Get Miss (Zipf) Workload
Get Hit (Zipf) Workload
Get Hit (Uniform) Workload
Scan (Zipf) Workload
Scan (Uniform) Workload
YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)
YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。
藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー、全バリアント共通)。
強制トリガーはバリアントごとに独立集計(全バリアント共通の1本の線には集約しない): t=5秒予定のreorganize()(細かい点線)、t=10秒・t=25秒予定のcheckpoint()(粗い点線)を、そのバリアント自身の色+マーカー形状(スキャンQPS線をホバーした際の点と同じ形。凡例のポイント形状も対応)で描画。
実際に発火する秒(線の位置)は予定秒とは限らない(将棋倒しに対するガード無し、書き込み負荷次第で数十秒遅延することがある)。8B In-Memoryのように挿入スループットが極端に高いワークロードでは、t=5秒予定のreorganize()自体が20秒以上かかり、後続のcheckpoint()トリガー(t=10s/25s)がこの30秒間に一度も発火しないまま終わることもある(この場合、線は1本しか出ない)。カーソルを線に合わせると、その秒に発火したバリアント・種類・予定秒・実発火秒・所要時間を表示。
Scan QPS タイムライン
32 threads / 30 secondsInsert Workload
Update (Zipf) Workload
Delete (Zipf) Workload
Get Miss (Zipf) Workload
Get Hit (Zipf) Workload
Get Hit (Uniform) Workload
Scan (Zipf) Workload
Scan (Uniform) Workload
YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)
YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。
藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー、全バリアント共通)。
強制トリガーはバリアントごとに独立集計(全バリアント共通の1本の線には集約しない): t=5秒予定のreorganize()(細かい点線)、t=10秒・t=25秒予定のcheckpoint()(粗い点線)を、そのバリアント自身の色+マーカー形状(スキャンQPS線をホバーした際の点と同じ形。凡例のポイント形状も対応)で描画。
実際に発火する秒(線の位置)は予定秒とは限らない(将棋倒しに対するガード無し、書き込み負荷次第で数十秒遅延することがある)。8B In-Memoryのように挿入スループットが極端に高いワークロードでは、t=5秒予定のreorganize()自体が20秒以上かかり、後続のcheckpoint()トリガー(t=10s/25s)がこの30秒間に一度も発火しないまま終わることもある(この場合、線は1本しか出ない)。カーソルを線に合わせると、その秒に発火したバリアント・種類・予定秒・実発火秒・所要時間を表示。