facebook/rocksdb

RocksDB 是一个成熟的嵌入式存储引擎，而不是数据库服务器：采用它意味着用 C++ 接口写代码，并自己承担 compaction 和参数调优的运维责任。当你需要在闪存上本地持久化多 TB 数据、并愿意围绕 LSM 的权衡做设计时，它才值得投入。

解决什么问题

应用需要在本机保存一份很大、会不断变更的键值数据——大过内存可能轻松容纳的范围，读写都有——并且重启后不能丢。自己动手就得管理文件、索引、预写日志、崩溃恢复和空间回收。RocksDB 把这些工作收进一个库：调用方打开数据库、读写键，引擎负责持久化和后台 compaction。最终得到的是进程内的持久存储，而不是另外部署一台服务器来运维。

有什么不同

RocksDB 源自 LevelDB（上游 LevelDB），保留 LSM 设计：写先进入内存表，刷成有序文件，再由后台 compaction 合并。项目把设计重点放在写放大、读放大和空间放大三者之间的显式取舍上，并用多线程 compaction 让单实例承载多 TB 数据成为可能（README）。实际差别就在这种显式取舍：你是在读写与空间的曲线上选一个点，而不是接受固定行为。

代价是这些旋钮归你管。compaction 方式、写缓冲、过滤器和内存上限都要匹配实际负载，而且问题往往在持续写压力下才暴露，快速测试看不出来。include/ 里的公开接口很小，但 README 明确提醒其他内部头文件可能随时变更、不应依赖（项目说明），所以集成应停留在文档承诺的接口之后。示例目录和 wiki是官方给出的起点，wiki 里还列了 相对 LevelDB 多出的功能，迁移时有用。2022 年有一位 HN 评论者称，他们把大型数据库程序从线程改为协程，在重 IO、高并发场景下性能大约翻倍（评论）；另一位回复质疑了基准测试被限制核心数的做法（回复），所以这只是单条未经验证的报告，不能当作性能承诺。

谁值得试

合适的对象是构建数据库、索引、消息存储或元数据层的系统团队：需要内嵌的大规模持久化，也愿意调优 LSM 引擎。2016 年 HN 讨论中有人提到 CockroachDB 重度使用它，还有人指出 TiKV 用 RocksDB 存共识状态（讨论），这反映了它常见的基础设施角色。不合适的是只需要一个小型本地存储、或想要现成键值服务器的应用：README 里 RocksDB 只是库，没有服务器程序，你仍然要围绕它自建服务、协议和运维工具。想要 SQL 数据库或托管服务的团队也不在目标范围内。

使用条件与边界

需要 C++ 集成并从源码构建；README 指向示例和外部讨论渠道，而不是打包好的安装器（项目说明）。引擎跑在你的进程里，内存和 compaction 线程会和业务争抢资源，因此写缓冲和后台工作量要有意规划。持久化还要小心选项变更和版本升级；README 没有给出迁移指引，依赖某个磁盘格式之前，先到 wiki 核对兼容性。

许可是 GPLv2 或 Apache 2.0 双许可，可任选其一（README）。对不少商业用户来说 Apache 选项很关键，但仍要确认它符合你的分发方式和法务要求。长期要做的是随着数据量和写入速率增长持续调优、监控 compaction 行为，而不是一次性配置。

HotRepo 点评

项目已有 5080 天历史；截至 2026-10-28 单日榜单观察，星数为 32,232（当天 +6）。记录的历史不足以判断趋势是否持续。HN 上有讨论（2016 年帖子），但数量只说明讨论量，不代表共识。采用前先读 wiki 关于选项和 compaction 的文档，并用自己的数据形态跑一次写压力基准，因为读写与空间的取舍正是 RocksDB 要你亲自负责的部分。