尧图网站建设 
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 全面而准确的认知。什么是 RocksDBRocksDB 是一个可嵌入式embeddable的持久化键值存储库专门面向快速存储Flash / SSD 等设计。与常见的客户端—服务器架构数据库不同RocksDB 以库的形式链接进应用进程数据以字节数组byte array形式的 Key 和 Value 存取并按用户指定的比较器Comparator对 Key 排序。官方 FAQ 明确指出RocksDB 也可以作为客户端—服务器数据库的基础但当前的主要发力点是嵌入式工作负载embedded workloads。RocksDB 构建在 LevelDB 之上目标是扩展到多 CPU 核心的服务器、高效利用快速存储、同时支撑 IO-boundIO 密集型、纯内存in-memory与写一次write-once等多种工作负载并保持架构上的灵活性以持续创新。这一点在仓库 README.md 中有更工程化的表述RocksDB 采用Log-Structured-MergeLSM设计在写放大因子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 cant 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后端它取代了另一套内部存储引擎CentrifugeZippyDBFacebook 产品所依赖的分布式键值存储服务建立在 RocksDB 之上Dragon社交图谱基础设施中的分布式图查询引擎也使用 RocksDB 存储数据。此外Parse 自 2015 年初起就在生产环境运行基于 RocksDB 的 MongoDB。当前仓库 USERS.md 记录了远比 FAQ 时代更广泛的采用清单可以作为采用规模的最新仓库内证据。除 Facebook 的 MyRocks、MongoRocks、ZippyDB、Laser、Dragon、Stylus、LogDevice 之外还包括Bilibili / TikTok字节跳动通过 Alluxio 元数据存储、Flink 状态存储、ByteGraph 分布式图数据库等路径使用 RocksDBMicrosoft Bing将其用作 Web 数据平台的存储引擎LinkedInVeniceML 特征平台、follow feed、Apache SamzaYahoo最大的分布式数据存储 SherpaTencent支撑微信的 PaxosStoreBaiduApache 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/rocksdb124 个*.h对外提供稳定 APILICENSE.Apache 与 COPYING 显示项目采用 Apache 2.0 与 GPLv2 双许可详见 README.md使用者可按需二选一文档站点源码与示例代码也一并随仓库开放。上手验证嵌入式 KV 的最小实践FAQ 虽以问答为主但其嵌入式键值存储的核心定义可以直接用仓库中的官方示例验证。仓库 examples/simple_example.cc 给出了完整的打开、写入、读取与原子批量更新流程其关键路径如下#include rocksdb/db.h #include rocksdb/options.h std::unique_ptrDB 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.txtsimple_example会被编译并链接到 RocksDB 库。更多使用形态列族、事务、多进程、备份恢复等可查看 examples/ 目录下的其他示例而DB::Open的完整重载族含只读打开OpenForReadOnly、次级实例OpenAsSecondary等见 include/rocksdb/db.h。对于初次上手docs/_docs/getting-started.md 还给出了数据库目录即文件系统目录、Status错误处理、关闭时直接delete db等基础约定更全面的文档可参考 docs/_docs 目录与仓库 wiki 目录下的资料。总结从 FAQ 出发可以把 RocksDB 的核心画像概括为四句话定位可嵌入、持久化的快速存储键值库面向多核服务器与 Flash 存储构建于 LevelDB 之上并大幅扩展动机LevelDB 在服务器负载大数据库、IO-bound下存在单线程压缩、写停顿、mmap 读瓶颈等不足RocksDB 以多线程压缩与显式写停顿控制等机制解决生态从 Facebook 内部ZippyDB、Dragon、MyRocks、MongoRocks扩展到 Bing、CockroachDB、腾讯 PaxosStore 等大量外部系统USERS.md 是持续更新的采用清单开放以 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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 全面而准确的认知。什么是 RocksDBRocksDB 是一个可嵌入式embeddable的持久化键值存储库专门面向快速存储Flash / SSD 等设计。与常见的客户端—服务器架构数据库不同RocksDB 以库的形式链接进应用进程数据以字节数组byte array形式的 Key 和 Value 存取并按用户指定的比较器Comparator对 Key 排序。官方 FAQ 明确指出RocksDB 也可以作为客户端—服务器数据库的基础但当前的主要发力点是嵌入式工作负载embedded workloads。RocksDB 构建在 LevelDB 之上目标是扩展到多 CPU 核心的服务器、高效利用快速存储、同时支撑 IO-boundIO 密集型、纯内存in-memory与写一次write-once等多种工作负载并保持架构上的灵活性以持续创新。这一点在仓库 README.md 中有更工程化的表述RocksDB 采用Log-Structured-MergeLSM设计在写放大因子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 cant 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后端它取代了另一套内部存储引擎CentrifugeZippyDBFacebook 产品所依赖的分布式键值存储服务建立在 RocksDB 之上Dragon社交图谱基础设施中的分布式图查询引擎也使用 RocksDB 存储数据。此外Parse 自 2015 年初起就在生产环境运行基于 RocksDB 的 MongoDB。当前仓库 USERS.md 记录了远比 FAQ 时代更广泛的采用清单可以作为采用规模的最新仓库内证据。除 Facebook 的 MyRocks、MongoRocks、ZippyDB、Laser、Dragon、Stylus、LogDevice 之外还包括Bilibili / TikTok字节跳动通过 Alluxio 元数据存储、Flink 状态存储、ByteGraph 分布式图数据库等路径使用 RocksDBMicrosoft Bing将其用作 Web 数据平台的存储引擎LinkedInVeniceML 特征平台、follow feed、Apache SamzaYahoo最大的分布式数据存储 SherpaTencent支撑微信的 PaxosStoreBaiduApache 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/rocksdb124 个*.h对外提供稳定 APILICENSE.Apache 与 COPYING 显示项目采用 Apache 2.0 与 GPLv2 双许可详见 README.md使用者可按需二选一文档站点源码与示例代码也一并随仓库开放。上手验证嵌入式 KV 的最小实践FAQ 虽以问答为主但其嵌入式键值存储的核心定义可以直接用仓库中的官方示例验证。仓库 examples/simple_example.cc 给出了完整的打开、写入、读取与原子批量更新流程其关键路径如下#include rocksdb/db.h #include rocksdb/options.h std::unique_ptrDB 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.txtsimple_example会被编译并链接到 RocksDB 库。更多使用形态列族、事务、多进程、备份恢复等可查看 examples/ 目录下的其他示例而DB::Open的完整重载族含只读打开OpenForReadOnly、次级实例OpenAsSecondary等见 include/rocksdb/db.h。对于初次上手docs/_docs/getting-started.md 还给出了数据库目录即文件系统目录、Status错误处理、关闭时直接delete db等基础约定更全面的文档可参考 docs/_docs 目录与仓库 wiki 目录下的资料。总结从 FAQ 出发可以把 RocksDB 的核心画像概括为四句话定位可嵌入、持久化的快速存储键值库面向多核服务器与 Flash 存储构建于 LevelDB 之上并大幅扩展动机LevelDB 在服务器负载大数据库、IO-bound下存在单线程压缩、写停顿、mmap 读瓶颈等不足RocksDB 以多线程压缩与显式写停顿控制等机制解决生态从 Facebook 内部ZippyDB、Dragon、MyRocks、MongoRocks扩展到 Bing、CockroachDB、腾讯 PaxosStore 等大量外部系统USERS.md 是持续更新的采用清单开放以 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考