【RocksDB 内核机制】选型与存储栈阅读地图
内容提要
本文总结了RocksDB的内核机制，探讨了存储引擎的选择决策树，包括OLTP、OLAP和湖仓等场景。RocksDB适合写密集型负载，适用于Flink、TiKV等嵌入式应用。文章对比了RocksDB与InnoDB、列存和湖仓的特点，指出各自的适用场景和优化方向，并提供了存储栈和数据平台的阅读地图，以帮助读者理解不同存储引擎的关系与应用。
关键要点
-
RocksDB适合写密集型负载，主要用于嵌入式应用，如Flink和TiKV。
-
存储引擎的选择决策树包括OLTP、OLAP和湖仓等场景。
-
RocksDB与InnoDB、列存和湖仓的特点对比，指出各自的适用场景和优化方向。
-
文章提供了存储栈和数据平台的阅读地图，帮助读者理解不同存储引擎的关系与应用。
-
RocksDB的写路径为WAL → MemTable → Flush → SST，读路径为SuperVersion → MergeIterator → Block Cache / Bloom。
-
Compaction驱动写stall与三种放大，RocksDB的Checkpoint和增量快照服务备份与bulk load。
延伸解读
RocksDB的适用场景
RocksDB特别适合写密集型负载的嵌入式应用，如Flink和TiKV。对于需要高吞吐量和顺序写入的场景，RocksDB能够提供优越的性能。然而，在需要复杂SQL查询和跨行事务的情况下，选择传统的行存数据库如PostgreSQL或InnoDB会更为合适。
存储引擎的选择决策
在选择存储引擎时，需考虑具体的应用场景。OLTP场景适合使用行存引擎，而OLAP和批处理则更倾向于列存或湖仓。RocksDB作为写优化的LSM引擎，适合嵌入式KV存储，但在数据已存储于对象存储（如S3/HDFS）时，使用湖仓格式可能更为高效。
RocksDB与其他引擎的比较
RocksDB与InnoDB、列存和湖仓在性能和适用场景上各有特点。RocksDB在写入性能上表现突出，但在读性能和事务支持上不如InnoDB。列存引擎则在大规模数据分析时更具优势，而湖仓则适合处理开放格式和批量数据。选择合适的引擎需根据具体需求进行权衡。
延伸问答
RocksDB适合什么样的负载场景？
RocksDB适合写密集型负载，主要用于嵌入式应用，如Flink和TiKV。
如何选择合适的存储引擎？
选择存储引擎时，可以根据需求是否需要SQL和ACID事务、主要访问模式（点查或范围查）以及负载特性（写密集或分析扫描）来决定。
RocksDB与InnoDB的主要区别是什么？
RocksDB是写优化的LSM存储引擎，适合高吞吐量的写操作，而InnoDB是基于B-Tree的行存引擎，适合OLTP事务和随机读写。
RocksDB的写路径是怎样的？
RocksDB的写路径为WAL → MemTable → Flush → SST。
在什么情况下不推荐使用RocksDB？
不推荐使用RocksDB的情况包括需要标准SQL、跨行事务、外键约束，或以宽表聚合扫描为主的场景。
RocksDB的Compaction是如何影响性能的？
Compaction会导致写stall，并且会引起写放大和读放大，影响整体性能。
