Benchmark Results (2026081000)

Raw JSON (In-mem 8B) Raw JSON (In-mem 1KB) Raw JSON (LTM 1KB) Raw JSON (LTM 64KB) Raw JSONL (Reorg Scaling, In-Mem 8B) Raw JSONL (Reorg Scaling, In-Mem 1KB) Raw JSONL (Reorg Scaling, LTM 1KB) Raw JSONL (Reorg Scaling, LTM 64KB)

AWS 32コア物理環境における vmemkv と RocksDB/RocksDB-BlobDB/LMDB の性能比較ベンチマーク。本ラウンドの主要変更は get_impl() に ScanBaseSequential が既に持つ base_mmap(base領域専用、MADV_SEQUENTIAL・PROT_READのみの第二mmap)を経由する高速パスを追加したこと。 従来 Get は常に主mmap(MADV_RANDOM)+ seqlock 経由で読んでおり、LTM環境下で大きい値(64KB)を読む際にページフォルト単位(4KB)でしか読み込めず、RocksDB比で大きく劣後していた(LTM/64KB Get/Hitで0.15〜0.36x)。共有ヘルパー try_read_base_record() を新設して scan_impl() と get_impl() の両方から呼ぶ形に統合し、base領域(不変)のレコードは seqlock 不要でこの mmap から直接読めるようにした。 base_mmap はファイルバックのクリーンページとして扱われる(書き込みなし)ため、スワップ先読みではなく通常のpage cache先読みが効き、AWS実測(i4i.2xlarge threads:1/4/8、i4i.8xlarge実32コア threads:1/4/16/32)では2.71x〜8.24xの改善が並列度に依存せず一貫して確認された(過去に試した T2NoMadviseRandom アブレーションは低並列でのみ有効で実32コアではBaselineより悪化したため削除している -- 詳細は docs/benchmark/20260810_get_base_mmap_fast_path.md 参照)。 本レポートはこの修正を含む本番マトリクス全体(In-Memory/LTM × 8B/1KB/64KB × 全ストア)を、4台の独立したAWSスポットインスタンスに分割並列実行して取得した最新結果。

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
  • +ScanBaseSequential: +Prefault + base領域専用mmap(MADV_SEQUENTIAL)。本ラウンドから Get もこのmmapの高速パスを使う(全部盛り、= VMemKVStore)

Environment

  • Instance: AWS i4i.8xlarge (ap-northeast-1) x4 (4並列独立インスタンス、run_4parallel_bench.sh)
  • CPU: Intel Xeon Platinum 8375C @ 2.90GHz (32 cores)
  • RAM: 247.7 GiB
  • RAM (Larger-Than-Memory): cgroup で DRAM を 1GiB に制限、target_ratio=8.0でコーパスを約8倍の規模に構築後、cgroup内で計測(ストアごとに独立したcgroupスコープ + drop_caches)
  • Disk: Local NVMe SSD (Swap Media for LTM)
  • Kernel: 6.17.0-1019-aws
  • Git Rev: 7bf7d6a972ab (clean -- get_impl() base_mmap 高速パスを含む)

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.53x) vmemkv (+Inline) vs RocksDB-BlobDB
✅ WIN (1.59x) vmemkv (All opts) vs RocksDB-BlobDB
✅ WIN (1.55x) vmemkv (All opts) vs RocksDB
✅ WIN (2.58x) vmemkv (+Inline) vs RocksDB-BlobDB
Update (Zipf)
✅ WIN (1.48x) vmemkv (All opts) vs RocksDB
✅ WIN (1.56x) vmemkv (All opts) vs RocksDB
✅ WIN (2.14x) vmemkv (All opts) vs RocksDB-BlobDB
✅ WIN (3.26x) vmemkv (+Prefault) vs LMDB
Delete
✅ WIN (1.56x) vmemkv (All opts) vs RocksDB-BlobDB
✅ WIN (1.67x) vmemkv (+Inline) vs RocksDB
✅ WIN (1.67x) vmemkv (+Prefault) vs RocksDB
✅ WIN (3.58x) vmemkv (All opts) vs RocksDB-BlobDB
Get (Miss)
✅ WIN (2.65x) vmemkv (+Prefault) vs RocksDB
✅ WIN (2.81x) vmemkv (+Prefault) vs LMDB
✅ WIN (2.78x) vmemkv (+Prefault) vs RocksDB
✅ WIN (2.62x) vmemkv (+BF) vs LMDB
Get (Hit, Zipf)
✅ WIN (1.42x) vmemkv (+Prefault) vs LMDB
✅ WIN (1.17x) vmemkv (All opts) vs LMDB
❌ LOSE (0.62x) vmemkv (+Inline) vs RocksDB-BlobDB
❌ LOSE (0.38x) vmemkv (All opts) vs RocksDB
Get (Hit, Uniform)
WIN (1.07x) vmemkv (+Prefault) vs LMDB
WIN (1.10x) vmemkv (All opts) vs LMDB
❌ LOSE (0.82x) vmemkv (+Inline) vs RocksDB-BlobDB
❌ LOSE (0.51x) vmemkv (All opts) vs RocksDB-BlobDB
Scan (Zipf)
❌ LOSE (0.63x) vmemkv (All opts) vs LMDB
≈ EVEN (1.02x) vmemkv (All opts) vs LMDB
LOSE (0.88x) vmemkv (All opts) vs RocksDB
❌ LOSE (0.49x) vmemkv (All opts) vs LMDB
Scan (Uniform)
❌ LOSE (0.64x) vmemkv (All opts) vs LMDB
WIN (1.08x) vmemkv (All opts) vs LMDB
✅ WIN (1.43x) vmemkv (All opts) vs RocksDB
≈ EVEN (1.01x) vmemkv (All opts) vs RocksDB-BlobDB
YCSB-E (Timeline Workload)
✅ WIN (2.74x) vmemkv (All opts) vs RocksDB
✅ WIN (1.62x) vmemkv (All opts) vs RocksDB
LOSE (0.91x) vmemkv (All opts) vs RocksDB
❌ LOSE (0.60x) vmemkv (All opts) vs RocksDB

Tier 1 Reorganize (T1only)

Average and worst-case times to reorganize the active buffer.

Scenario 8B 1KB 64KB
In-MemoryAvg: 1.46s
Max: 2.70s		Avg: 0.65s
Max: 0.73s		-
LTM-Avg: 1.17s
Max: 1.34s		Avg: 0.11s
Max: 0.18s

Tier 1+2 Reorganize (Full)

Average and worst-case times for a full T1+T2 reorganize / checkpoint.

Scenario 8B 1KB 64KB
In-MemoryAvg: 23.72s
Max: 38.97s		Avg: 13.29s
Max: 21.19s		-
LTM-Avg: 42.07s
Max: 60.00s
*(1/4 points timed out)		Avg: 33.13s
Max: 54.50s

Insert Workload

実験概要: ユニークキーを空のストアに順次挿入する際の書き込みスループット。

Update (Zipf) Workload

実験概要: Zipf 分布での既存キーに対する更新スループット(ステートフルな上書き)。

Delete (Zipf) Workload

実験概要: T1 Tombstone 付与による並行削除スループット。

Get Miss (Zipf) Workload

実験概要: 存在しないキーへの読み取り。Bloom Filter の偽陽性回避効果を評価。

Get Hit (Zipf) Workload

実験概要: Zipf 分布(ホットキー偏重)での既存キーに対するポイントルックアップ。get_impl() の base_mmap 高速パス(本ラウンドの主要変更)が最も効くケース。

Get Hit (Uniform) Workload

実験概要: 一様分布での既存キーに対するポイントルックアップ。同上。

Scan (Zipf) Workload

実験概要: Zipf 分布で選ばれたレンジのスキャン。現行 bench_kv は reorganize 状態を単一の Scan ベンチマークとして測定する形に統合済み(旧レポートの Scan_WithReorg / Scan_T1T2Reorg モード分割は撤去済み)。

Scan (Uniform) Workload

実験概要: 一様分布で選ばれたレンジのスキャン(同上)。

YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)

YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。 藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー)。 橘色の点線: t=15秒時点で強制的に1回実行されるT1 Reorganize。

Scan QPS タイムライン

32 threads / 30 seconds

Reorganize Duration vs. Corpus Size (T1-only vs T1+T2)

単発のreorganize()呼び出し1回の所要時間を、コーパスサイズ(件数)を横軸にスイープ計測。 藍色 = T1-only、赤色 = T1+T2。 ▲マーカーはタイムアウトを示す。

Reorganize Duration

single-shot, threads:1

Insert Workload

実験概要: ユニークキーを空のストアに順次挿入する際の書き込みスループット。

Update (Zipf) Workload

実験概要: Zipf 分布での既存キーに対する更新スループット(ステートフルな上書き)。

Delete (Zipf) Workload

実験概要: T1 Tombstone 付与による並行削除スループット。

Get Miss (Zipf) Workload

実験概要: 存在しないキーへの読み取り。Bloom Filter の偽陽性回避効果を評価。

Get Hit (Zipf) Workload

実験概要: Zipf 分布(ホットキー偏重)での既存キーに対するポイントルックアップ。get_impl() の base_mmap 高速パス(本ラウンドの主要変更)が最も効くケース。

Get Hit (Uniform) Workload

実験概要: 一様分布での既存キーに対するポイントルックアップ。同上。

Scan (Zipf) Workload

実験概要: Zipf 分布で選ばれたレンジのスキャン。現行 bench_kv は reorganize 状態を単一の Scan ベンチマークとして測定する形に統合済み(旧レポートの Scan_WithReorg / Scan_T1T2Reorg モード分割は撤去済み)。

Scan (Uniform) Workload

実験概要: 一様分布で選ばれたレンジのスキャン(同上)。

YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)

YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。 藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー)。 橘色の点線: t=15秒時点で強制的に1回実行されるT1 Reorganize。

Scan QPS タイムライン

32 threads / 30 seconds

Reorganize Duration vs. Corpus Size (T1-only vs T1+T2)

単発のreorganize()呼び出し1回の所要時間を、コーパスサイズ(件数)を横軸にスイープ計測。 藍色 = T1-only、赤色 = T1+T2。 ▲マーカーはタイムアウトを示す。

Reorganize Duration

single-shot, threads:1

Insert Workload

実験概要: ユニークキーを空のストアに順次挿入する際の書き込みスループット。

Update (Zipf) Workload

実験概要: Zipf 分布での既存キーに対する更新スループット(ステートフルな上書き)。

Delete (Zipf) Workload

実験概要: T1 Tombstone 付与による並行削除スループット。

Get Miss (Zipf) Workload

実験概要: 存在しないキーへの読み取り。Bloom Filter の偽陽性回避効果を評価。

Get Hit (Zipf) Workload

実験概要: Zipf 分布(ホットキー偏重)での既存キーに対するポイントルックアップ。get_impl() の base_mmap 高速パス(本ラウンドの主要変更)が最も効くケース。

Get Hit (Uniform) Workload

実験概要: 一様分布での既存キーに対するポイントルックアップ。同上。

Scan (Zipf) Workload

実験概要: Zipf 分布で選ばれたレンジのスキャン。現行 bench_kv は reorganize 状態を単一の Scan ベンチマークとして測定する形に統合済み(旧レポートの Scan_WithReorg / Scan_T1T2Reorg モード分割は撤去済み)。

Scan (Uniform) Workload

実験概要: 一様分布で選ばれたレンジのスキャン(同上)。

YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)

YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。 藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー)。 橘色の点線: t=15秒時点で強制的に1回実行されるT1 Reorganize。

Scan QPS タイムライン

32 threads / 30 seconds

Reorganize Duration vs. Corpus Size (T1-only vs T1+T2)

単発のreorganize()呼び出し1回の所要時間を、コーパスサイズ(件数)を横軸にスイープ計測。 藍色 = T1-only、赤色 = T1+T2。 ▲マーカーはタイムアウトを示す。

Reorganize Duration

single-shot, threads:1

Insert Workload

実験概要: ユニークキーを空のストアに順次挿入する際の書き込みスループット。

Update (Zipf) Workload

実験概要: Zipf 分布での既存キーに対する更新スループット(ステートフルな上書き)。

Delete (Zipf) Workload

実験概要: T1 Tombstone 付与による並行削除スループット。

Get Miss (Zipf) Workload

実験概要: 存在しないキーへの読み取り。Bloom Filter の偽陽性回避効果を評価。

Get Hit (Zipf) Workload

実験概要: Zipf 分布(ホットキー偏重)での既存キーに対するポイントルックアップ。get_impl() の base_mmap 高速パス(本ラウンドの主要変更)が最も効くケース。

Get Hit (Uniform) Workload

実験概要: 一様分布での既存キーに対するポイントルックアップ。同上。

Scan (Zipf) Workload

実験概要: Zipf 分布で選ばれたレンジのスキャン。現行 bench_kv は reorganize 状態を単一の Scan ベンチマークとして測定する形に統合済み(旧レポートの Scan_WithReorg / Scan_T1T2Reorg モード分割は撤去済み)。

Scan (Uniform) Workload

実験概要: 一様分布で選ばれたレンジのスキャン(同上)。

YCSB-E — Scan + Insert 混合スループット(30秒タイムライン)

YCSB-E ワークロード: 95% Scan(100件レンジスキャン)+ 5% Insert を 32スレッドで 30秒間実行。 藍色の点線: 自然発生のT1 Reorganize(Adaptive Soft Limitによる自動トリガー)。 橘色の点線: t=15秒時点で強制的に1回実行されるT1 Reorganize。

Scan QPS タイムライン

32 threads / 30 seconds

Reorganize Duration vs. Corpus Size (T1-only vs T1+T2)

単発のreorganize()呼び出し1回の所要時間を、コーパスサイズ(件数)を横軸にスイープ計測。 藍色 = T1-only、赤色 = T1+T2。 ▲マーカーはタイムアウトを示す。

Reorganize Duration

single-shot, threads:1