RocksDB 技术 FAQ 全解读：嵌入式持久化 KV 存储引擎的定位、性能与生态

RocksDB 技术 FAQ 全解读：嵌入式持久化 KV 存储引擎的定位、性能与生态

【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdb

导读：本文以 docs/_docs/faq.md 为主体，系统回答围绕 RocksDB 最常见的技术问题——它是什么、为什么诞生、适合什么场景、性能如何、被哪些系统采用、为何开源。文章在完整继承原 FAQ 全部内容的基础上，结合当前仓库中的 README.md、USERS.md、examples/simple_example.cc 与核心源码，补充底层机制与上手实践，帮助读者在动手使用前建立对 RocksDB 全面而准确的认知。

什么是 RocksDB

RocksDB 是一个可嵌入式（embeddable）的持久化键值存储库，专门面向快速存储（Flash / SSD 等）设计。与常见的客户端—服务器架构数据库不同，RocksDB 以库的形式链接进应用进程，数据以字节数组（byte array）形式的 Key 和 Value 存取，并按用户指定的比较器（Comparator）对 Key 排序。官方 FAQ 明确指出：RocksDB 也可以作为客户端—服务器数据库的基础，但当前的主要发力点是嵌入式工作负载（embedded workloads）。

RocksDB 构建在 LevelDB 之上，目标是扩展到多 CPU 核心的服务器、高效利用快速存储、同时支撑 IO-bound（IO 密集型）、纯内存（in-memory）与写一次（write-once）等多种工作负载，并保持架构上的灵活性以持续创新。这一点在仓库 README.md 中有更工程化的表述：RocksDB 采用Log-Structured-Merge（LSM）设计，在写放大因子（Write-Amplification-Factor, WAF）、读放大因子（Read-Amplification-Factor, RAF）与空间放大因子（Space-Amplification-Factor, SAF）之间提供灵活权衡，并通过**多线程压缩（multi-threaded compactions）**支撑单个数据库中存储数 TB 级别的数据。

关于项目脉络，README 同时指出：公共接口位于仓库的 include/ 目录，调用方不应包含或依赖该包中其他头文件的细节——内部 API 可能在无预警的情况下变更，这为"可嵌入式"的定位划清了稳定的对外边界。

为什么会有 RocksDB：与 LevelDB 的性能对比

FAQ 记录了一个关键历史事实：RocksDB 团队最初对 LevelDB 做了基准测试，发现它不适合服务器端工作负载。表面上看，LevelDB 的基准测试结果"非常漂亮"，但团队很快意识到：那些结果针对的是一个比测试机内存还小的数据库——整个数据库都能放进操作系统页缓存（page cache）。当团队在同一台机器上对体积至少是主内存 5 倍的数据库重新跑同样的基准时，性能结果变得非常糟糕。

相比之下，RocksDB 发布了自己面向服务器端、跑在 Flash 上的基准结果。在同样的服务器负载基准上，RocksDB 对 IO-bound 工作负载的表现稳定优于 LevelDB。FAQ 归纳了 LevelDB 的几个具体短板：

• 单线程压缩不足以驱动服务器工作负载：LevelDB 的压缩过程是单线程的，无法打满服务器上的写入吞吐；
• 频繁的写停顿（write-stall）：这导致 99 百分位延迟被拉得极大；
• mmap 文件到 OS 缓存带来读性能瓶颈：读路径上存在明显的性能问题；
• 无法吃满底层 Flash 存储能提供的全部 IO。

这些短板在当今仓库源码中都能找到对应的"解答"。以写停顿为例，db/write_controller.h 的注释直接点明：WriteController is controlling write stalls in our write code-path. Write stalls happen when compaction can't keep up with write rate.——即 RocksDB 将"压缩跟不上写入速度"时的写停顿纳入显式的控制器机制，通过 db/db_impl/db_impl.cc 等实现进行速率调节，而不是让停顿失控地放大尾延迟。

再看 mmap 读问题：FAQ 指出把文件 mmap 进 OS 缓存会给读路径引入瓶颈，这解释了为何 options/db_options.h 中存在allow_mmap_reads这一选项，且在 options/db_options.cc 中作为可解析的配置项暴露，默认关闭。用户可以按需在 DBOptions 中显式开启或关闭 mmap 读，而不是像 LevelDB 那样被 mmap 行为"绑定"。

RocksDB 适合什么场景

FAQ 明确：需要低延迟数据库访问的应用都可以考虑 RocksDB，并给出了五类典型场景：

• 面向用户的应用，存储网站用户的浏览历史与状态；
• 需要对大数据集快速访问的垃圾邮件检测应用；
• 需要实时扫描数据集的图搜索查询（graph-search query）；
• 缓存 Hadoop 数据，从而让应用可以实时查询 Hadoop 数据；
• 支持高插入、高删除量的消息队列。

这几类场景共同指向 RocksDB 的定位——作为底层存储引擎嵌入到具体业务系统里，而不是作为一个独立的数据库服务对外提供。从仓库结构看，utilities/ 目录（包含 137 个*.cc、112 个*.h文件）承载了事务、备份、列族管理等上层能力，进一步支撑"嵌入到各种应用形态"这一使用方式。

RocksDB 的采用规模

FAQ 记载了 RocksDB 早期在 Facebook 内部的落地情况：在 Facebook 信息流（newsfeed）后端，它取代了另一套内部存储引擎Centrifuge；ZippyDB（Facebook 产品所依赖的分布式键值存储服务）建立在 RocksDB 之上；Dragon（社交图谱基础设施中的分布式图查询引擎）也使用 RocksDB 存储数据。此外，Parse 自 2015 年初起就在生产环境运行基于 RocksDB 的 MongoDB。

当前仓库 USERS.md 记录了远比 FAQ 时代更广泛的采用清单，可以作为"采用规模"的最新仓库内证据。除 Facebook 的 MyRocks、MongoRocks、ZippyDB、Laser、Dragon、Stylus、LogDevice 之外，还包括：

• Bilibili / TikTok（字节跳动）：通过 Alluxio 元数据存储、Flink 状态存储、ByteGraph 分布式图数据库等路径使用 RocksDB；
• Microsoft Bing：将其用作 Web 数据平台的存储引擎；
• LinkedIn：Venice（ML 特征平台）、follow feed、Apache Samza；
• Yahoo：最大的分布式数据存储 Sherpa；
• Tencent：支撑微信的 PaxosStore；
• Baidu：Apache Doris 用其管理 tablet 元数据；
• CockroachDB、FoundationDB（进而 Apple、Snowflake）等数据库/系统也将其作为存储引擎。

USERS.md 的说明也印证了 FAQ 中"开放给行业"的初衷——如果你也在使用 RocksDB，可以通过 Pull Request 把自己加入该列表。

RocksDB 作为数据库存储引擎的表现

FAQ 记录了团队对 RocksDB 作为数据库存储引擎潜力的判断：已在生产环境与 MongoDB 验证（MongoRocks是基于 RocksDB 的 MongoDB 存储引擎），并催生了MyRocks——基于 RocksDB 的 MySQL 存储引擎。FAQ 给出了具体数据：在当时针对现有 MySQL 配置的基准中，RocksDB 实现了约 2 倍的压缩率提升和约 10 倍的写放大下降。

需要强调的是：这些数字是 FAQ 撰写时点（2015 年前后）团队自测基准的结果，属于历史事实而非当前承诺。从源码结构看，RocksDB 之所以能在存储引擎层面提供这种优势，与其 LSM 架构和压缩机制直接相关——仓库中 table/、db/compaction/、db/flush_job.cc 等模块共同实现了多线程压缩、压缩感知的写入调度与空间回收，从而同时压低写放大与存储开销。对于希望把 RocksDB 当作数据库底层引擎的读者，仓库 PLUGINS.md 也提供了插件机制的说明。

为什么开源

FAQ 给出了官方开源动机：Facebook 认为 RocksDB 的价值不止于自身——希望软件程序员和数据库开发者能使用、增强并针对各自用例定制 RocksDB，同时也希望与学术界就现代数据库算法的效率问题展开交流。

当前仓库对这一初衷的支撑随处可见：公共头文件集中在 include/rocksdb（124 个*.h），对外提供稳定 API；LICENSE.Apache 与 COPYING 显示项目采用 Apache 2.0 与 GPLv2 双许可（详见 README.md），使用者可按需二选一；文档站点源码与示例代码也一并随仓库开放。

上手验证：嵌入式 KV 的最小实践

FAQ 虽以问答为主，但其"嵌入式键值存储"的核心定义可以直接用仓库中的官方示例验证。仓库 examples/simple_example.cc 给出了完整的打开、写入、读取与原子批量更新流程，其关键路径如下：

#include "rocksdb/db.h" #include "rocksdb/options.h" std::unique_ptr<DB> db; Options options; // 优化：最简单地让 RocksDB 跑出好性能 options.IncreaseParallelism(); options.OptimizeLevelStyleCompaction(); // 数据库不存在时自动创建 options.create_if_missing = true; Status s = DB::Open(options, "/tmp/rocksdb_simple_example", &db); assert(s.ok()); // 写入与读取 s = db->Put(WriteOptions(), "key1", "value"); s = db->Get(ReadOptions(), "key1", &value); // 原子地应用一组更新 WriteBatch batch; batch.Delete("key1"); batch.Put("key2", value); s = db->Write(WriteOptions(), &batch);

该示例覆盖了 FAQ 中"键与值是任意字节数组、Key 按比较器有序"的定义，并通过WriteBatch展示了原子批量更新能力。示例的构建方式见 examples/CMakeLists.txt，simple_example会被编译并链接到 RocksDB 库。更多使用形态（列族、事务、多进程、备份恢复等）可查看 examples/ 目录下的其他示例，而DB::Open的完整重载族（含只读打开OpenForReadOnly、次级实例OpenAsSecondary等）见 include/rocksdb/db.h。

对于初次上手，docs/_docs/getting-started.md 还给出了数据库目录即文件系统目录、Status错误处理、关闭时直接delete db等基础约定；更全面的文档可参考 docs/_docs 目录与仓库 wiki 目录下的资料。

总结

从 FAQ 出发，可以把 RocksDB 的核心画像概括为四句话：

1. 定位：可嵌入、持久化的快速存储键值库，面向多核服务器与 Flash 存储，构建于 LevelDB 之上并大幅扩展；
2. 动机：LevelDB 在服务器负载（大数据库、IO-bound）下存在单线程压缩、写停顿、mmap 读瓶颈等不足，RocksDB 以多线程压缩与显式写停顿控制等机制解决；
3. 生态：从 Facebook 内部（ZippyDB、Dragon、MyRocks、MongoRocks）扩展到 Bing、CockroachDB、腾讯 PaxosStore 等大量外部系统，USERS.md 是持续更新的采用清单；
4. 开放：以 Apache 2.0 / GPLv2 双许可开源，公共接口集中于 include/rocksdb，欢迎开发者使用与定制。

FAQ 中关于性能对比、写放大等历史数据属于特定时点的基准结论，读者在规划自己的场景时，应基于当前仓库版本的配置与实测重新验证。

【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdb