# RocksDB RocksDB は LSM ツリーベースのキーバリューストアである。[[EcoTune]] 論文では、RocksDB ベースの Dostoevsky 実装に EcoTune と Moose を組み込み、Leveling（RocksDB 既定方針）、Lazy Leveling、Moose と比較した。論文は RocksDB の Leveling 方針が瞬時の読み取りアンプリフィケーションでは有利でも、平均クエリスループットではコンパクションの CPU/I/O 占有により不利になる場合を示す。(Source: [[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]]) [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]] は RocksDB を、ホスト誘導 SSD データ配置のシムレイヤー [[Valet]] のケーススタディ対象として用いる。RocksDB は書き込み先ファイル(Write-Ahead Log・Sorted String Tables)を区別する慣習的な配置とファイル拡張子を持つため、ヒューリスティックによる stream 識別に適している。同論文は、RocksDB 専用の ZNS バックエンドである [[zenfs]] を「アプリケーション固有ソリューションの gold standard」として Valet と比較し、fill/overwrite ワークロードで Valet が f2fs の2倍超のスループットを、zenfs に匹敵する性能を達成することを示した。(Source: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]]) [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] は RocksDB を OS ページキャッシュとのやり取りの主要ケーススタディに用いる。観測ツール [[cachestream]] は RocksDB の SST ファイル名から LSM ツリーレベルを特定し、コンパクションログのスレッド ID とページキャッシュイベントを突き合わせて、L0/L1 のヒット率がほぼ 100%で L3/L4 より顕著に高いことを実験的に示した。この診断結果から、コンパクションスレッドが挿入する folio をページキャッシュに入れない [[cache_ext]] の admission filter 方針を設計し、YCSB A ワークロードで read P99 レイテンシを 22.4%(1.16ms→0.90ms)改善、ヒット率を 9.1 ポイント(79.2%→88.3%)向上させた。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) *Observability Engineering* 第2版第30章は、[[Mark Callaghan]]が[[MongoDB]]のプラガブルストレージエンジン化を推進した際、RocksDBのMongoDBサポートをRocksDBロードマップに乗せることに成功した事例を、権威によらない技術的信用性が企業間のロードマップへ影響を与えた「ベンダーエンジニアリング」の実例として紹介する。この働きかけは[[Facebook]]によるParse買収を契機にMongoDBがParseを重要顧客として重視し始めた時期に行われた。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 30 The Art and Science of Vendor Partnerships]] "How to Influence Another Company's Roadmap") *Designing Data-Intensive Applications* 第2版第4章は、Bigtable が提案した「メムテーブル→SSTable→バックグラウンドコンパクション」のアルゴリズムを実装する具体例として、Cassandra・ScyllaDB・HBase と並べて RocksDB を挙げる。同章はさらに、高い書き込みスループット下でメムテーブルが埋まった際に RocksDB が読み書きを一時停止して *backpressure* をかけ、メムテーブルのディスク書き出しを待つ挙動を、LSM ストレージエンジン一般のレイテンシスパイク対策の代表例として紹介する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Constructing and merging SSTables", "Read performance") *詳説 データベース* 第3章は、マルチバイト数値のバイナリエンコーディング例としてRocksDBを挙げる。RocksDBはターゲットプラットフォームのバイトオーダー(エンディアンネス)を識別するプラットフォーム固有の定義を持ち、ターゲットプラットフォームのエンディアンが値のエンディアンと一致しない場合には `EndianTransform` を使ってバイトを反転させ、値を逆順にバイト単位で読み取って結果に追加する。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] §3.2.1) *詳説 データベース* 第7章は、平準化コンパクション(Leveled Compaction)を実装するシステムの例としてRocksDBを挙げる。ディスク上のテーブルを目標サイズを持つレベルに区分し、レベル1以上ではテーブルのキー範囲が重複しない設計であり、レベル間でサイズは指数関数的に増大する。また、墓石(tombstone)の保持期間についても触れ、RocksDBは最下位レベルに到達するまで墓石を維持すると説明する(対照的にApache Cassandraは結果整合性のためGCの猶予期間に到達するまで墓石を維持する)。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]] §7.1.6, §7.1.6.1) ## 関連 - ソース: [[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]] / [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]] / [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 30 The Art and Science of Vendor Partnerships]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]] - 概念: [[LSMツリー]] / [[LSMツリーコンパクション]] / [[ホスト誘導データ配置]] / [[eBPF]] / [[ベンダーエンジニアリング]] / [[バイナリエンコーディング]] - エンティティ: [[EcoTune]] / [[Valet]] / [[zenfs]] / [[f2fs]] / [[cache_ext]] / [[cachestream]] / [[Mark Callaghan]] / [[MongoDB]] / [[Facebook]]