什么是RocksDB？嵌入式键值存储详解

RocksDB 是什么？嵌入式键值存储

RocksDB 是使用最广泛的存储系统之一，然而几乎没有人直接配置它。它位于 Kafka、通过 MyRocks 使用的 MySQL、TiDB、YugabyteDB、Ceph 以及绝大多数 Solana 验证器的账本之下。

对于这样一个承载重任的系统，其相关介绍却出奇地少。

官方文档是优秀的参考材料，但作为初次入门却不理想，而其他大多数解释都假设读者已经具备先验知识，比如了解什么是 LSM 树。

这是探索 RocksDB 内部工作原理系列文章的第一篇，我们从最显而易见的问题开始。

RocksDB 是什么？

RocksDB 是一个可嵌入的、持久的键值存储，专为快速存储优化。它以任意字节数组作为键和值，保持有序，并持久地存储在磁盘上。

首先需要理解的最重要的一点是：RocksDB 是一个库，而不是一个服务器。没有需要连接的进程，没有需要打开的端口，也没有需要学习的查询语言。

RocksDB 与应用程序集成，并在该进程内运行，读取和写入本地磁盘上的文件。这正是 RocksDB 快速的原因——应用程序代码与其操作的数据之间没有网络跳转。它非常精简，因为它故意将复制、分片和查询留给上层构建的组件。

简单来说，RocksDB 是一个存储引擎——TiDB 和 YugabyteDB 等数据库正是围绕它构建的。

RocksDB 和 LevelDB 是一样的吗？

不，但它们源自同一代码库。RocksDB 始于 2012 年，是 Google 的 Jeff Dean 和 Sanjay Ghemawat 编写的轻量级键值存储 LevelDB 的一个分支。

LevelDB 是为中等环境（例如，浏览器的 IndexedDB 后端或单个嵌入式设备）构建的，并为此做出了各种设计决策，包括单线程压缩、保守的内存使用以及几乎不提供调优选项。

Facebook（现 Meta）的工程师以该基础为起点，为服务器工作负载进行了重构。其目标是：在持续写入压力下，处理远超内存大小的数据集的同时，充分利用现代硬件。

RocksDB 于 2013 年开源，并与 LevelDB 有了显著差异。它引入了多线程压缩、列族、事务、备份、合并操作符、可插拔压缩风格以及众所周知的一长串调优选项。

LevelDB 和 RocksDB 有家族相似性，但将它们视为可互换的做法在十年前就已经不再合理了。

RocksDB 是如何工作的？

RocksDB 基于 日志结构合并树（LSM tree） 构建，这是一种用读取简单性换取写入吞吐量的数据结构。

本质上，传入的写入会被写入一个称为 memtable 的内存缓冲区。同时，这些写入也会追加到磁盘上的预写日志中以实现持久性。

当 memtable 满了之后，它会被冻结并作为不可变的、有序的文件刷新到磁盘，这个文件称为 有序字符串表（Sorted String Table，SST）。SST 文件会累积成层级结构，一个称为 压缩（compaction） 的后台进程会持续合并它们，丢弃被覆盖的值和已删除的键，从而保持一个整洁、有序、持久的结构。

读取操作首先检查 memtable，然后向下遍历不同层级的 SST 文件。布隆过滤器让 RocksDB 能够跳过那些不可能包含该键的文件，而块缓存则将热数据保存在内存中，因此大多数读取操作最多只触及一两个文件。

LSM 树和 B 树有什么区别？

B 树是大多数传统数据库使用的结构，它原地更新数据，这意味着随机写入会分散在磁盘上。LSM 树则是追加和批量处理，意味着大的顺序写入，这正是 SSD 和高写入量工作负载所需要的。这里的权衡是：一个键的当前值可能分布在多个文件中，因此需要压缩、布隆过滤器和缓存来限制这种权衡。

LSM 树中的每一个设计决策最终都是在三种压力之间进行协商：

• 写入放大
• 读取放大
• 空间放大

改善其中任意两项往往会恶化第三项。

这个三角关系是理解 RocksDB 调优的最重要的思维模型。

RocksDB 有什么用途？

无论应用程序在何处需要在本地磁盘上进行快速、持久、有序的键值存储，而又不希望承担运行独立数据库服务器的开销，RocksDB 都能派上用场。具体的示例比分类更能清晰地说明这种模式。

Kafka Streams 将每个处理任务的状态（正在进行的聚合、连接、窗口计算）保存在一个本地的 RocksDB 存储中，这样状态就可以超出内存大小，并在重启后存活，而无需在每次查找时增加网络往返。

Meta 的 ZippyDB 将 RocksDB 封装在复制层、分片管理和配置服务中，以提供完全托管的分布式键值存储。分工明确：RocksDB 提供存储，所有服务器形态的功能都围绕它构建。

TiDB 的存储层在每个节点上运行 RocksDB，作为分布式 SQL 数据库的引擎，它将表结构编码为键前缀，以便扫描一张表就变成了对有序键的一次连续读取。

每个基于 Agave 的 Solana 验证器都将账本写入 RocksDB，以 slot 为键，这样连续的账本数据在磁盘上相邻存放。

最后两个示例很有趣，因为键是按有序顺序存储的——默认按字节顺序，或按自定义比较器——这使得范围扫描和前缀查找非常高效。

在基于 RocksDB 的系统中，大量真实的模式设计都归结为利用这种排序。

谁在使用 RocksDB？

除了上述系统之外，RocksDB 是任何需要嵌入式、久经考验、写优化的存储引擎的系统的基石，团队选择它是因为他们继承了 Meta 十年的生产环境打磨成果，而不是从头编写一个。

值得注意的是：

• Kafka Streams 将其用作状态存储的默认引擎
• Apache Flink 提供了一个 RocksDB 状态后端，用于处理大到无法放入内存的检查点状态
• MyRocks 将其嵌入为 MySQL 存储引擎，由 Meta 开发，用于削减现有最大 MySQL 集群之一的存储占用
• TiDB 的存储层 TiKV 使用 RocksDB，并为 Raft 日志和键值数据分别使用独立实例
• YugabyteDB 的文档存储 DocDB 使用 RocksDB
• Ceph 的 BlueStore 使用 RocksDB 存储对象存储元数据
• ArangoDB 自 3.4 版本起已将 RocksDB 作为默认存储引擎，自 3.7 版本起作为唯一引擎

RocksDB 主要用于 SSD 上的写密集、超内存工作负载，我们将在本文后面再次讨论这一点。

Solana 如何使用 RocksDB？

Solana 是一个高性能、低延迟的权益证明区块链，以其对速度、效率和消费者应用的关注而闻名。Solana 的账本存储在 RocksDB 中。Agave 验证器客户端将账本存储在 Blockstore 中，该组件包含一个 RocksDB 数据库，跨越多个独立的、可调优的键空间。

独立的列族保存了分片数据（shred data）和分片纠删码（即账本数据的原始单元，如同它们从网络到达时一样）、交易状态、地址到签名的索引以及各种元数据。

与大多数数据库工作负载相比，验证器的写入模式极为极端。也就是说，验证器必须持续不断地以网络线速摄取分片，这些分片以几乎单调递增的 slot 编号为键，并且永远持续下去。未修剪的账本存档远超数百 TB，并且每年至少增长数十 TB。

在层级压缩下，分位列族产生了足够多的后台压缩工作，以至于验证器开始遭遇写入停顿，这是 RocksDB 内置的机制，用于在压缩跟不上时减慢摄取速度。

大约在 2021 年，分位列族切换到了 FIFO 压缩，这是一种极简的风格，当达到大小上限时直接删除最旧的文件。FIFO 通常对于一般工作负载来说是不安全的。然而，由于分片键以近乎单调的 slot 顺序到达，验证器可以删除最旧的文件，因为它包含最旧的 slot。这种压缩风格与工作负载形状几乎完美匹配。

随后对层级压缩的优化将其 I/O 放大降低到了 FIFO 不再具有优势的程度，因此 FIFO 路径于 2024 年 6 月被弃用，并于同年 11 月被移除。

Firedancer 是 Jump Crypto 用 C 语言编写的 Solana 验证器客户端，它完全弃用了 RocksDB，转而使用专门构建的内部存储层。

注：

混合型 Frankendancer 客户端仍然运行 Agave RocksDB Blockstore，并且账本目录格式保持与 RocksDB 兼容，因此操作员可以在客户端之间切换而无需重新同步。

从头编写的存储引擎能否超越 RocksDB 十年的打磨和调优，这在验证器工程中是一个有趣的开放性问题。

什么时候 RocksDB 是错误的选择？

RocksDB 在更多情况下是错误的选择，而非其普遍程度所暗示的那样。其调优面极其庞大，有数百个选项，它们之间的交互并不显而易见，因此错误调优是常态而非例外。

更糟的是，RocksDB 的默认值是合理的，而非最优的，因此开发者需要理解上述的放大权衡，才能获得真正的性能提升。持续的高写入量可能超过后台压缩的进度，从而触发写入停顿，而这往往发生在系统最繁忙的时候。

此外，RocksDB 是一个库，而不是一个服务器。典型数据库服务器会提供的所有功能（例如复制、分片、备份、访问控制、查询层、运维工具）都必须自行构建。

工作负载形状也至关重要。

RocksDB 是一个面向行的、点查找和范围扫描引擎。分析型工作负载需要扫描大范围数据并按列聚合，这类任务更适合像 ClickHouse 这样的列式存储。

这些都不是避开 RocksDB 的理由。相反，它们是刻意选择它的理由。我们 Helius 在重新设计归档层并最终选择 RocksDB 时，直接评估了这些风险，因为我们的工作负载恰好是 RocksDB 所设计的形状：在大型追加型数据集上进行点查找和紧凑的范围扫描。

结论

RocksDB 是一个可嵌入的、持久的、有序的键值存储，它用操作上的便利性换取了本地磁盘上的原始性能。它源自 LevelDB，在 Meta 针对 SSD 和多核机器进行了加固，现在嵌入在世界各地的各种系统中，从流处理器和分布式 SQL 数据库到存储集群和 Solana 的账本。

如果在大规模高性能 RocksDB 环境上工作听起来令人兴奋，请与我们一起来构建。

Solana 正努力成为全球金融的结算层，其底层基础设施正运行在本系列文章所描述的机制之上。在你能买到的最好的硬件上，以行星级规模解决困难的系统问题。

我们正在招聘整个工程团队的成员。请查看我们在 helius.dev/careers 的所有开放职位。

• 原文链接： helius.dev/blog/what-is-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～