【RocksDB 内核机制】选型与存储栈阅读地图

本系列前 17 篇从 LevelDB 基线 追到 生产嵌入，从 WAL / MemTable 追到 LOG 排查。读者此时需要的不是又一篇 LSM 教程，而是 不带营销排名的收束：我的负载该落在 B-Tree、列存 scan、嵌入式 LSM 还是湖仓文件层？读完存储栈还缺哪几块？

本文是「RocksDB 内核机制」系列 第 18 篇（末篇）：

1. 选型决策树：写密集 KV、OLTP 行存、OLAP scan、湖仓批读四条路径。
2. 能力对照表：优化方向、事务、Compaction 运维、嵌入生态——不给假 benchmark。
3. 存储 + 数据平台阅读地图：闭合 postgresql-kernel → columnar-engine → lakehouse → stream-processing → query-engine/18 的依赖与接口。

环境说明：对照表依据各项目 2026 年官方文档（A 级）与本系列前文机制；吞吐排名不在此篇出现。HTAP / TiKV Raft 全文标注为 db-frontier/12 续作，不冒充已发布系列结论。

一、存储引擎三角：闭合点

第 1 篇 LSM 生态 把存储引擎粗分为三角：行存 B-Tree OLTP、列存 scan、写优化 LSM。RocksDB 占据第三角——不是替代 PG 或 ClickHouse，而是 负载分工。

flowchart TB
  subgraph triangle["Storage Engine Triangle"]
    PG["Row OLTP<br/>PostgreSQL / InnoDB"]
    COL["Columnar Scan<br/>MergeTree / DuckDB"]
    LSM["Write-Optimized LSM<br/>RocksDB / LevelDB"]
  end
  PG --- COL
  COL --- LSM
  LSM --- PG

本系列闭合点：读者应能解释 TiKV / Flink 为何选 LSM（第 16 篇），以及 L0 stall 如何从 LOG 钉到根因（第 17 篇）。

二、选型决策树

flowchart TD
  START["Storage need"]
  START --> Q1{"Need SQL + ACID<br/>multi-row transactions?"}
  Q1 -->|yes| Q2{"Primary access<br/>point/range on indexed keys?"}
  Q2 -->|yes| PG["PostgreSQL / InnoDB<br/>B-Tree row store"]
  Q2 -->|no| Q3{"Analytics scan<br/>dominates?"}
  Q3 -->|yes| HTAP["HTAP split or lakehouse<br/>see Section 6"]
  Q1 -->|no| Q4{"Embedded KV / stream state<br/>write-heavy?"}
  Q4 -->|yes| LSM["RocksDB embedded<br/>Flink / TiKV / KStreams"]
  Q4 -->|no| Q5{"Open files on object store<br/>batch analytics?"}
  Q5 -->|yes| LAKE["Lakehouse tables<br/>Parquet + Iceberg/Delta"]
  Q5 -->|no| Q6{"Single-node embedded<br/>analytics?"}
  Q6 -->|yes| DDB["DuckDB / embedded OLAP"]
  Q6 -->|no| QE["Distributed query engine<br/>query-engine series"]

2.1 路径说明

常见组合：PostgreSQL OLTP + Kafka/Flink 入湖 + Trino 查湖 + ClickHouse Serving；TiKV 在线 KV + TiFlash 列存副本（HTAP，见第六节）。

2.2 何时 不 选 RocksDB

• 需要 标准 SQL、跨行事务、外键 → 行存 RDBMS，不是嵌入式 LSM。
• 以 宽表聚合 scan 为主、少更新 → 列存或湖仓列式文件，不是 leveled LSM。
• 数据已在 S3/HDFS 上的 Parquet/Iceberg，查询通过 Trino/Spark → 查询引擎 + 表格式，不必再嵌一层 RocksDB。
• 状态可完全放进 JVM 堆 且规模可控 → Flink HashMapStateBackend 可能更简单（stream/12 对照表）。

2.3 何时 应 考虑 RocksDB

• 进程内 高吞吐顺序写、可容忍 compaction 运维（写放大公式 \(WA \approx T \times L\)，见 lsm-tree）。
• 需要 Column Family 隔离多类 key 空间（第 13 篇）。
• 依赖 不可变 SST + Checkpoint 做增量快照（Flink 增量 checkpoint，第 15–16 篇）。
• 已有 TiKV / MyRocks / Kafka Streams 等栈，需要读懂 LOG 与 stall。

三、RocksDB vs InnoDB vs 列存 vs 湖仓

口径：单机或嵌入层存储语义，非分布式集群全貌；无吞吐排名。

读放大 / 写放大：LSM 与 B-Tree、列存的公式推导不在此重复——分别见 storage/31、postgresql-kernel 缓冲池篇、columnar-engine merge 篇。

四、学术文献地图：选型不是排行榜

第三节对照表回答 工程能力；本节回答 论文坐标：每类存储在顶会里通常讨论什么、与 RocksDB 嵌入场景如何衔接。完整读法见 db-frontier/02 顶会阅读路线。

4.1 存储三角的论文锚点

争论边界（有文献、无口号）：

• Leveled 读友好 vs Tiering 写友好：Dostoevsky 在固定 \(T\) 与层数下比较 sorted run 数；RocksDB Universal 是工程上的中间策略，不是论文里的最优策略闭式解。
• 嵌入式 LSM vs 分布式 SQL：RocksDB 论文/ Wiki 讨论 单进程 KV；TiKV 把 LSM 包在 Raft Region 里——选型到 TiKV 时，本系列只覆盖 Region 内引擎，不覆盖 Percolator 与 PD（db-frontier/12）。

4.2 HTAP 与「第四角」：行列双维护

HTAP 不是三角的第四引擎，而是 在 OLTP 行存之上叠 OLAP 读路径 的系统问题。代表性 A 级文献：

未决争论：双引擎 HTAP（TiKV + TiFlash）与 统一 LSM 扛 OLAP scan 谁更省运维？工业界按新鲜度档位与 DDL 能力选型；顶会无「RocksDB 应替代列存」一类结论。

4.3 工程间隙：论文假设 vs 嵌入生产

本系列 1–17 篇 钉 单进程 RocksDB 语义；端到端 SLA 须叠加上层调度与分布式协议，不能从 LSM 论文实验直接外推。

4.4 开放问题（选型后的续读入口）

1. 自适应 compaction： workload 漂移时 leveled ↔︎ universal 能否 无 DBA 切换且 tail 可控？研究线与 RocksDB AutoTune 实验并存；生产默认仍靠阈值 + 人工 POC（storage/32）。
2. LSM 能否承担 HTAP 列扫：TiFlash 选择 独立列存副本 而非在 RocksDB SST 上做向量化 scan——是否最优仍开放；读 db-frontier/12 时对照 隔离方式 × 新鲜度 两轴。
3. Disaggregated LSM：NVMe-oF / CXL 下 compactions 是否应远程执行？NSDI/OSDI 存储分离论文与 RocksDB 产品功能 版本不同步，以 release note 为准。
4. ForSt / 替代嵌入后端：Flink 社区在评估 ForSt 等 LSM 变体；与 RocksDB 的 checkpoint 文件布局 兼容性决定迁移成本——属产品演进，非本系列已发布结论。

五、存储栈 + 数据平台阅读地图

flowchart LR
  PG["postgresql-kernel<br/>B-Tree OLTP"]
  INN["mysql-innodb<br/>InnoDB"]
  COL["columnar-engine<br/>OLAP scan"]
  LSM["rocksdb<br/>本系列"]
  LAKE["lakehouse<br/>表格式"]
  STREAM["stream-processing<br/>Flink/Kafka"]
  QE["query-engine<br/>Trino/Spark"]
  DF["db-frontier<br/>HTAP"]
  PG --> COL
  INN -.->|行存对照| PG
  COL --> LAKE
  LSM --> STREAM
  STREAM --> LAKE
  LAKE --> QE
  LSM -.->|TiKV Region| DF
  PG --> DF
  COL --> DF

5.1 推荐阅读顺序（按目标）

5.2 与 query-engine/18 的接口

query-engine 系列第 18 篇 收束 Trino / Spark / ClickHouse / DuckDB 的 查询层 选型。与本系列的分工：

闭合句：lakehouse 公式 Lakehouse = 列式文件 + 对象存储 + 表格式 + catalog + 查询引擎 中，文件与表 由 lakehouse/stream 覆盖；查询规划 由 query-engine 覆盖；进程内写优化 KV 由 本系列 覆盖。读完两系列 18 篇，应能说明：Flink 状态 bytes 如何变成 SST（本系列 16），以及 Trino 如何对 Iceberg 发起 split（query-engine 15）。

5.3 与 postgresql-kernel 的对照阅读

PostgreSQL 不会 用 leveled compaction 换写吞吐；RocksDB 不会 提供 SQL planner——选型在 工作负载，不在「哪个更先进」。

六、HTAP / TiKV 续作入口

分布式 HTAP（同一份数据 OLTP + OLAP）在 db-frontier/12 HTAP 讨论：TiDB + TiFlash 行列双副本、SingleStore Universal Storage、Lakehouse 可更新性等。Huang et al. (VLDB 2020) 把 Raft Learner + 列存副本 作为准实时 HTAP 的代表架构——与本系列 单 Region RocksDB 的关系见 §4.2。

与本系列关系：

TiKV 读者路径：本系列 01 → 13 → 16 → 17 → 18 建立单 Region LSM 心智 → db-frontier/12 看 Raft + 列存副本 如何叠在 RocksDB 之上。

七、本系列核心结论收束

1. RocksDB = LevelDB 骨架 + 多线程 flush/compaction + CF + RateLimiter + 丰富 utilities（第 2–3 篇）。
2. 写路径：WAL → MemTable → Flush → SST → MANIFEST（第 4–6 篇）；读路径：SuperVersion → MergeIterator → Block Cache / Bloom（第 7–9 篇）。
3. Compaction 驱动写 stall 与三种放大（第 10–12 篇）；Column Family 共享 WAL、隔离 LSM（第 13 篇）。
4. Checkpoint / Ingest 服务备份与 bulk load（第 15 篇）；Flink 增量 checkpoint 是 Checkpoint + 不可变 SST 的嵌入特例（第 16 篇）。
5. 生产稳定性 靠 GetProperty、LOG、Statistics 与磁盘容量规划（第 17 篇、storage/76）。
6. 选型 按负载分工嵌入存储三角，对照 §4 论文坐标 与决策树；不与 InnoDB / 列存 / 湖仓做 fictitious 排名（本篇）。

八、开放边界（不承诺）

• 替代 RocksDB Wiki 与 storage/32 参数手册。
• TiKV PD / Raft / 分布式事务独立系列（见 db-frontier 与后续规划）。
• 各引擎 2026 年后 新特性（Ribbon 默认、ForSt 生产化等）以官方 release note 为准。

九、小结

存储引擎没有「万能内核」。RocksDB 适合 写密集、嵌入、可运维 compaction 的场景；InnoDB / PostgreSQL 适合 SQL 事务 OLTP；列存适合 scan 聚合；湖仓适合 开放格式 + 批处理 + 多引擎读。论文侧 Leveled/Tiering、RUM、HTAP 双副本 提供争论坐标，不替代 本机 POC。

数据平台栈在 query-engine/18 闭合 查询层；本系列闭合 写优化 LSM 层。

继续深入：数据库索引、全部系列索引、db-frontier HTAP。

上一篇：经典故障与排查

下一篇：系列目录

返回 系列目录 · PostgreSQL 内核 · query-engine/18

参考资料

1. O’Neil et al., The Log-Structured Merge-Tree, Acta Informatica 1996（LSM 奠基；A 级）。
2. Dayan & Idreos, The Log-Structured Merge-Bush / Dostoevsky, SIGMOD 2017–2018（compaction 策略；A 级）。
3. Data et al., RUM Conjecture, SIGMOD 2016（放大三角；A 级）。
4. Sears & Ramanan, bLSM, SIGMOD 2012（stall / 多核 compaction；A 级）。
5. Huang et al., TiDB: A Raft-based HTAP Database, VLDB 2020（HTAP 行列副本；A 级）。
6. RocksDB Wiki, Overview / Architecture（A 级）。
7. PostgreSQL、MySQL/InnoDB、ClickHouse、Apache Iceberg 官方文档（2026 stable；A 级）。
8. query-engine 第 18 篇（数据平台查询层收束）。
9. db-frontier/02 阅读路线、db-frontier/12 HTAP（顶会方法与 HTAP 基准；B 级前瞻接口）。
10. 本系列 index、第 1 篇 §二学术谱系。
11. storage/31–32、lsm-tree DIY（放大与 DIY 对照）。