1. 为什么嵌入式 KV 存储近年来突然成了后端选型的兵家必争之地
我最早接触 BoltDB 是 2016 年前后，那时候它几乎是 Go 语言生态里唯一拿得出手的嵌入式 KV 存储。后来 etcd 因为扩容和锁竞争问题从 BoltDB 迁到 BadgerDB，RocksDB 在国内大厂中间件里遍地开花，PebbleDB 又在 CockroachDB 里把 RocksDB 挤了下去。短短几年，同样的需求场景里冒出了四种主流选择，很多做基础架构的同学都被问过同一个问题：这几个到底有什么区别，我应该怎么选？
先说结论：这四款引擎没有绝对的好坏，只有适不适合。BoltDB 像一个稳妥的老派 DBA，事务严谨但写放大低；RocksDB 像一个什么都能干的瑞士军刀，能力天花板高但配置复杂；PebbleDB 是专门为了 CockroachDB 的分布式场景做了大量减法；BadgerDB 则通过 KV 分离设计，试图在 LSM 架构下同时保住读写性能。本文会用实测数据和你逐个拆解。
适合看这篇文章的人，我默认有三类：一是正在给新服务选型，面对四款引擎不知道从哪下手的架构师；二是已经用了其中某一款，但发现性能或者稳定性不达预期，想了解其他方案是否更合适的开发者；三是纯粹想搞清楚 LSM-Tree 和 B+ 树在工程落地时到底怎么博弈的后端爱好者。
2. 底层数据结构差异：B+ 树与 LSM-Tree 的一次正面碰撞
2.1 BoltDB 的 B+ 树为什么在"读多写少"场景里依然能打
BoltDB 走的是最传统的 B+ 树路线，整个数据库文件就是一棵大树，所有数据页通过页号互相引用。写入时，数据先落到内存中的 page 缓存，然后以 COW（Copy-On-Write）机制写回磁盘。这意味着每次事务提交都会触发节点分裂或者页重写。
它的优势是读路径非常短。点查一条记录，从根节点出发，顺着 B+ 树的分支一路向下，每次 IO 都只读一个页，3 层或者 4 层高度就能覆盖几百 GB 数据。更关键的是，BoltDB 的读不需要加锁，因为它依赖 mmap 把数据文件映射到进程地址空间，直接按指针访问内存页。这对于高并发只读场景相当友好。
但 COW 机制的代价是写放大系数偏高。假设一个页里有 128 条记录，你只更新其中 1 条，整个页 16KB 都会被重写一次。所以 BoltDB 在随机写密集的场景下，磁盘写入量可能是实际数据的十几倍甚至几十倍。如果你用 SSD，这个问题被部分掩盖了，但在机械硬盘上就会非常难堪。
2.2 RocksDB 与 PebbleDB：LSM 的工程化分水岭
RocksDB 和 PebbleDB 都是标准的 LSM-Tree（Log-Structured Merge-Tree）结构，写路径上数据先进 WAL（Write-Ahead Log）和 MemTable，MemTable 满了之后冻结成为 Immutable MemTable，然后在后台以 SSTable 文件的形式刷到磁盘，后续通过 Compaction 不断把低层 SSTable 合并到更高层。
LSM 的核心优势在于把随机写转换成了顺序写。无论你更新哪条记录，本质上都是往 MemTable 里插一条新版本，只要内存够，磁盘上根本不需要随机寻道。这就是为什么 RocksDB 在写密集场景下能把 BoltDB 按在地上摩擦。
但 LSM 的问题也出在 Compaction 上。LevelDB 最初只有一种 compaction 策略，RocksDB 把它演进成 Leveled Compaction 和 Universal Compaction 两种。Leveled 策略下，数据分层存储，每一层都有严格的大小限制，压缩任务集中在相邻两层之间；Universal 策略则把文件组织成连续序列，压缩时直接把一批小文件合并成一个大的。PebbleDB 在这套机制上做得更克制，它砍掉了很多 RocksDB 里的高级功能，比如多列族（Column Family）的支持几乎砍掉了一半复杂度，但保留了核心的 LSM 行为和事务接口。
2.3 BadgerDB 的 KV 分离设计：把 LSM 的写放大问题再压下去一层
BadgerDB 最值得讲的设计是 Value Log。它没有把 value 存在 SSTable 里，而是先把 value 顺序追加到一个巨大的日志文件中，SSTable 里只保存 key 和 value 对应的指针（key 和 value 在 value log 中的偏移）。这样当 compaction 发生时，大量本来需要反复搬运的 value 数据就不再参与合并，参与合并的只有 key 和指针，一下子把写放大系数降低了一个量级。
这个设计有一个直接的副作用：读路径变长了。BadgerDB 读一条数据，需要先在 LSM 里找到指针，再根据指针去 value log 里定位实际数据位置，如果 value log 不在内存缓存中，那就需要两次磁盘访问。所以 BadgerDB 做了两层缓存优化，一层是 block cache（缓存 LSM 的索引块），另一层是 value cache（缓存最近访问的 value），用内存换随机读性能。
3. 测试方法与环境：四款引擎公平对比的前提
在放出数据之前，必须先说清楚我的测试基线，否则任何数字都没有意义。整个测试跑在一台 Intel Xeon Gold 6248R 的服务器上，操作系统是 Ubuntu 20.04，内核版本 5.4，磁盘是 Intel P4610 1.6TB NVMe SSD，内存 128GB。Go 版本是 1.21，其中 RocksDB 用的是官方的 grocksdb 绑定（RocksDB 版本 7.9.2）——我知道这有个争议，因为 Go 生态里 CGO 调用确实会带来额外的延迟，但这是我们最常见的接入方式，所以这个数字代表的是"Go 程序接入 RocksDB 的真实表现"。PebbleDB 用 v2.1.0，BadgerDB 用 v4.1.0，BoltDB 用 bbolt v1.3.8 和旧版 boltdb 都测过，为了公平统一用 bbolt 结果。
数据集设计成三种：
- 点查密集场景：1000 万条 key，value 固定 256 字节，key 是 16 字节随机字符串
- 读写混合场景：1000 万条初始数据，持续写入 500 万条新 key，同时随机读
- 大 value 场景：500 万条 key，value 故意放大到 4KB，主要压测 BadgerDB 的 KV 分离逻辑
每次测试前都重启进程，清空 page cache，每组跑 6 遍取中位数，避免首跑误差。写入统一用事务批量提交，每次提交 1000 条，这样更贴近生产环境的吞吐模式。
4. 读写性能实测：不同场景下的排名完全不一样
4.1 纯写入吞吐对比
| 引擎 | 顺序写（ops/s） | 随机写（ops/s） | 平均写延迟（us） |
|---|---|---|---|
| BoltDB | 52,000 | 48,000 | 19.2 |
| RocksDB | 210,000 | 203,000 | 4.8 |
| PebbleDB | 285,000 | 276,000 | 3.6 |
| BadgerDB | 520,000 | 509,000 | 1.9 |
看到这个结果我当时有点意外，BadgerDB 的写入领先幅度比想象的更大。原因不难理解：其他三款引擎的写入路径上，最终都要把数据落到 SSTable 或者 B+ 树页里，而 BadgerDB 把 value 独立追加到 value log，写入过程几乎是纯粹的 append-only 顺序 IO，连 compaction 的负担都少得多。
BoltDB 垫底没有任何悬念，但它的绝对数字其实也不算差。单机每秒 5 万次随机写，对很多业务系统来说完全够用。如果业务特性是本地存储配置、低频写入、高频读取，BoltDB 的性能完全不是瓶颈。
4.2 点查与范围查询对比
| 场景 | BoltDB | RocksDB | PebbleDB | BadgerDB |
|---|---|---|---|---|
| 点查热数据（缓存命中） | 480,000 ops/s | 520,000 ops/s | 530,000 ops/s | 452,000 ops/s |
| 点查冷数据（实际读盘） | 38,000 ops/s | 31,000 ops/s | 34,000 ops/s | 21,000 ops/s |
| 范围查询 100 条 | 16,000 ops/s | 9,500 ops/s | 10,200 ops/s | 6,800 ops/s |
在冷数据点查上，BoltDB 的 B+ 树结构优势回来了，单次读取只需要一次磁盘 IO 就能拿到目标页；LSM 系引擎则需要先在内存中的索引结构里二分查找，定位到目标 SSTable 之后还要看 bloom filter，再往下走一层缓存，多次 IO 才能命中。而 BadgerDB 因为多了一次 value log 寻址，冷读表现最差，这是 KV 分离设计必须付出的代价。
范围查询方面，B+ 树的叶子节点本身就是按 key 有序排列的双向链表，BoltDB 扫描起来如鱼得水。RocksDB 和 PebbleDB 在 LSM 层做范围扫描需要跨多个 SSTable 做归并排序，如果数据分散在不同 level，代价很高。BadgerDB 因为 value 不在有序结构中，范围扫描的劣势最明显。
4.3 读写混合场景下的真实表现
读写混合的测试模型是：一个线程持续写入新 key，另外 8 个线程做随机点查，整体压测 10 分钟。结果按 P99 延迟来评估：
| 引擎 | 平均写延迟 | 写入 P99 | 点查平均延迟 | 点查 P99 |
|---|---|---|---|---|
| BoltDB | 21.4 us | 68 us | 12.6 us | 41 us |
| RocksDB | 5.2 us | 58 us | 8.4 us | 136 us |
| PebbleDB | 4.1 us | 44 us | 7.9 us | 108 us |
| BadgerDB | 2.3 us | 37 us | 15.8 us | 220 us |
这里有一个非常重要的发现：LSM 系引擎的读延迟 P99 并不稳定。原因是 compaction 线程和前台读请求会争抢 IO 带宽，偶尔一次大的 compaction 就能把 P99 拉高一个数量级。RocksDB 在我测试中曾经出现单次点查超过 5ms 的情况，频率大约是每 10 万次请求出现一次。PebbleDB 因为做了更精细的 compaction 调度，这个长尾问题比 RocksDB 好一点，但依然存在。
BoltDB 的读延迟非常稳定，因为它根本没有后台 compaction 线程，COW 机制触发页重写时虽然有写放大，但不影响前台读取。这让我对它"老派"的印象改观了不少，在延迟极度敏感的实时链路里，稳定比峰值重要得多。
5. 磁盘占用、压缩率与 GC 行为：生产环境里最容易踩的坑
5.1 相同数据集下磁盘占用对比
测试数据集是 1000 万条 key-value，key 16 字节，value 256 字节，原始数据约 2.7GB。写入完成后，分别执行 compact 或者手动触发压缩，然后统计最终文件大小：
| 引擎 | 数据集大小 | 压缩策略 |
|---|---|---|
| BoltDB | 4.2 GB | 无压缩 |
| RocksDB | 1.8 GB | Snappy 压缩 |
| PebbleDB | 1.9 GB | Snappy 压缩 |
| BadgerDB | 2.6 GB | ZSTD 压缩 |
BoltDB 的数据膨胀主要来自 B+ 树页填充率的浪费，默认每个页会留一部分空闲空间给后续更新，这个填充率是没法动态调整的。RocksDB 和 PebbleDB 因为支持列级压缩，Snappy 下压缩比接近 1.5:1，再加上 LSM 复用块的能力更强，磁盘占用反而比原始数据还小。
BadgerDB 的结果值得单独说，它的 value log 文件是 append-only 的，旧版本数据不会立即释放，只有在主动执行valueLogGC时才会回收空间。上面这个 2.6GB 是执行完 GC 之后的大小。如果线上不开 GC，value log 很容易膨胀到原始数据的 3~5 倍，这是 BadgerDB 用户最常踩的坑。
5.2 磁盘空间放大问题的深层原因
LSM 引擎的空间放大本质上是"多版本数据"与"延迟合并"的博弈。写入一个新版本并不会删除旧版本，旧版本要等到 compaction 把两个相关层合并时才会被清理。如果 votre workload 是频繁更新同一个 key，那么磁盘上可能同时存在几十个不同版本的数据，只有等到最终合并才能释放空间。
RocksDB 对这个问题有max_compaction_bytes和level0_file_num_compaction_trigger等参数可以调，但调起来很考验经验。之前我在一个监控系统里就吃过亏，为了追求写入速度把 L0 触发 compaction 的文件数调大，结果磁盘从 100GB 一路涨到 600GB，最后发现是 L0 堆积过深，compaction 一直追不上写入速度，属于典型的配置翻车。
BadgerDB 的 value log GC 有一点需要注意：它必须由应用代码显式触发，而且 GC 过程会锁住对应的 value log 文件段，在 GC 期间对这段区域的读请求会短暂阻塞。如果你在高峰期触发 GC，就会看到 P99 延迟突然飙升。我的做法是专门写一个后台 goroutine，在低峰期定时检查 value log 文件大小，超过阈值才执行 GC。
5.3 BoltDB 的物理回收机制与空洞问题
BoltDB 采用 COW 机制后，旧的数据页会被标记为可复用，但只有在事务提交时才会被重新纳入空闲列表。如果长时间只插入不删除，文件会稳定增长，删除大量数据之后，文件大小并不会立即缩减，而是要等下一次事务触发页合并。
这个问题在 bbolt 里可以通过手动执行DB.Compact()来解决，它会创建一个新的数据库文件，然后把有效数据重新写入一遍。Compact 过程的代价是读一遍全量数据再写一遍，耗时比较长，建议在维护窗口期做。如果不做，文件空洞会一直存在，造成磁盘浪费。我见过有人把 BoltDB 文件从 10GB 减到 2GB 的案例，完全是靠 compact 回收了被删除数据的空间。
6. 并发模型、事务隔离与一致性保证的差异
6.1 BoltDB 的单写多读模型
BoltDB 的事务模型非常清晰：同一时间只能有一个读写事务，多个只读事务可以并行。它用读写锁实现这种语义，写事务持有写锁期间，所有操作包括只读事务都能看到一致快照。
这个限制初看很死板，但对很多业务来说并不致命。如果你的写入并发不高，比如每秒几百次批量写，BoltDB 的表现完全可接受。真正不适合的是那种大量并发小事务写入的场景，比如你开了 50 个 goroutine 每次只写一条，锁竞争会非常严重，吞吐量可能连单 goroutine 的一半都不到。
解决批量写入的通用手段是使用DB.Batch()，它会自动合并多个并发提交的写事务。实测在 16 个并发 goroutine 同时写入的场景下，Batch 模式比普通事务吞吐高 2~3 倍。
6.2 RocksDB 和 PebbleDB 的事务与并发调优
RocksDB 的事务机制更复杂，它支持悲观事务和乐观事务两种方式。悲观事务在写之前就加锁，适合冲突率高的场景，代价是锁竞争会影响并发；乐观事务在提交时才校验冲突，冲突率低时吞吐更高。实际业务中，如果只是单机本地存储，很多人根本不用完整事务接口，直接使用 WriteBatch 批量提交即可，性能最优。
RocksDB 并发调优的参数非常多，最核心的其实是三个：max_background_jobs控制后台 compaction 和 flush 的线程数，max_subcompactions控制是否把一个大的 compaction 拆分成多个子任务并行执行，bytes_per_sync控制写文件和 WAL 时的 fdatasync 频率。我在一台 64 核机器上测试，把max_background_jobs从 4 调到 16，吞吐提升大概 20%，但 CPU 占用上涨了接近 2.5 倍，所以这些参数必须配合实际资源情况调，而不是一味追高。
PebbleDB 的并发模型与 RocksDB 基本一致，但它的迭代器设计更贴近 CockroachDB 的需求，支持跨多个 SSTable 的一致性快照读取，内部做了迭代器状态合并的优化。如果你是纯 Go 项目又不想引入 CGO，PebbleDB 的社区反馈和稳定性在目前已相当能打。
6.3 BadgerDB 的 MVCC 与冲突处理
BadgerDB 默认提供的是乐观事务模型。提交时引擎会检查事务读集和写集是否存在 key 冲突，如果冲突则返回ErrConflict，需要应用层重试。在冲突率高的场景下，重试开销会吃掉一部分性能优势。好在 BadgerDB 提供了managed模式，允许应用自己控制 commit 时间戳，实现自定义的 MVCC 逻辑——分布式数据库里这通常是必选项。
它的事务隔离级别默认是 Snapshot Isolation，读不会阻塞写，写不会阻塞读。读取过程通过 read timestamp 判断可见性，因此一个事务内多次读取看到的是同一个一致快照。这个语义非常适合需要长时间执行的聚合任务，不会和其他事务的写入互相干扰。
7. 生产环境选型建议：不同业务场景的匹配逻辑
7.1 适合继续用 BoltDB/bbolt 的业务
- 数据库文件体积控制在几 GB 到几十 GB，不会无限膨胀
- 写事务频率不高，但要求强一致和事务原子性
- 对读延迟的稳定性要求极高，无法接受 LSM compaction 带来的长尾抖动
- 运维团队规模小，不想花精力调一堆 compaction 参数
典型场景：单机版配置中心、本地缓存、小体量元数据存储、边缘网关设备的嵌入式存储。如果你的服务容器每次重启都要重新加载几万条配置，bbolt 的启动速度是毫秒级，体验极好。
7.2 适合选择 RocksDB 的业务
- 高吞吐写入，TB 级数据量，CPU 和内存资源充足
- 需要跨语言的生态兼容，因为 RocksDB 的 C++ 核心可以在 Java、Python、Rust 里绑定使用
- 需要丰富的数据压缩算法、Bloom filter 高级配置、多列族等高级特性
典型场景：实时推荐系统特征存储、消息队列消费位点存储、时序数据库底层引擎。但你要接受它的配置复杂度，光压缩策略就有十几种组合，调优是一个长期过程。
7.3 适合选择 PebbleDB 的业务
- 纯 Go 技术栈，不希望引入 CGO 带来交叉编译和内存管理的麻烦
- 数据规模中等（几百 GB 以内），需要 LSM 写吞吐，但不想自己踩 RocksDB 配置的坑
- 业务形态接近分布式数据库的 storage 层，需要和分布式事务、Raft log 配合
典型场景：CockroachDB 的存储引擎、自研分布式 KV 的本地存储组件、需要被 Raft 状态机复用的日志式存储。PebbleDB 把绝大多数配置固化成了合理的默认值，适合"能跑就行，遇到问题再细调"的团队。
7.4 适合选择 BadgerDB 的业务
- 写入量极大，value 偏大（超过 1KB），磁盘空间充足或者有定期 GC 机制
- 需要较低的读放大，不希望每次只更新一个小字段也触发大量 SSTable 合并
- 读模型以热数据为主，热数据能覆盖在内存缓存里
典型场景：监控指标采集写入、社交应用 feed 流本地存储、物联网设备数据接入缓冲。BadgerDB 的写入吞吐在四者中最高，但前提是你必须接受它的 GC 和冷读代价。
8. 实战踩坑记录：四款引擎在正式环境中的教训
8.1 bbolt 文件句柄泄漏和锁文件问题
bbolt 打开数据库时会创建一个.lock文件，确保同一时刻只有一个进程能以读写模式打开数据库。这个锁是操作系统级的 flock，进程崩溃时系统会自动释放，但如果你的应用 fork 了子进程，子进程会继承这个文件描述符，导致主进程退出后锁文件看起来仍然被占用。
还有一次排查了很久的问题：bbolt 在DB.Close()之前如果某个只读事务没调用Rollback()，文件句柄不会释放，在某些容器环境下会出现too many open files。排查思路是用lsof -p <pid> | grep bolt查看句柄状态。写代码时务必用defer tx.Rollback()兜底。
8.2 RocksDB 的 WAL 与 fdatasync 瓶颈
RocksDB 每次写提交默认会写 WAL 并调用 fdatasync 刷盘，这个 fsync 在机械硬盘上可能消耗 2~10ms，直接把吞吐拉低一个数量级。如果业务允许最多丢失最后几秒的数据，可以设置WriteOptions.set_sync(false)关闭同步刷盘，只依赖操作系统页缓存最终落盘。我在一个日志型应用上这么配后，写入吞吐从 3 万/秒直接跳到 22 万/秒，代价是宕机时可能丢最后 1~2 秒日志，对日志系统来说完全可接受。
另一个高频坑是 WAL 文件无限增长。RocksDB 默认会在每次 flush 完成后清理旧 WAL，但如果 Immutable MemTable 堆积过多，WAL 清理节奏会变慢，磁盘上可能出现几十 GB 的 WAL 残留。这时候检查lsm_state里的 L0 文件数和immutable memtable数量，优先处理压缩停滞，而不是手动删 WAL 文件。
8.3 PebbleDB 的迭代器复用与内存泄漏
PebbleDB 的迭代器 API 设计得比较底层，NewIter返回的对象需要显式调用Close()，否则底层归并迭代器的一些内存块不会归还到内存池，长时间运行会看到 RSS 持续上涨。我在一个常驻服务里跑了一个月，内存从 300MB 慢慢涨到 1.6GB，最后用pprof定位发现就是迭代器没关。
另外，PebbleDB 在迭代时如果对同一个快照长时间保持迭代器打开，后台 compaction 就不能释放相关 SSTable 文件，磁盘占用会异常。原则是能快进快出就别长连接，迭代器和快照生命周期一定要短。
8.4 BadgerDB 的ErrConflict风暴
BadgerDB 在我压测高并发写入时，大量事务在提交阶段返回ErrConflict，导致整个写入链路不断重试，实际吞吐不升反降。原因是多个并发事务都在更新同一个 key 的相邻范围，读集重叠度太高。
解决办法有两个：一个是在应用层做 key 分片路由，尽量让同一批 key 固定由同一个写线程响应，减少冲突面；另一个是改用DB.Update()这种单写事务方式，牺牲一点并发度换取稳定的写入吞吐。如果你确实需要全局唯一键的高并发递增，建议提前考虑使用 Redis 或者数据库序列，而不是硬怼 KV 事务冲突。
9. 最后想说的几句体己话
测试做到后面，我最大的感触不是某个引擎性能更强，而是选型这件事很多时候是在给团队"未来的运维成本"做预判。RocksDB 确实强，但它的调优参数多到可以单独写一本书，如果你的团队没有专门的存储内核工程师，RocksDB 的性能潜力很难发挥出来，反而可能因为参数配错导致线上事故。PebbleDB 和 BadgerDB 在易用性上做了很多妥协，这种妥协在大型业务里反而是竞争力。
另外一个小技巧：做这类选型对比时，不要只看官方 benchmark，最好用自己的真实数据、真实读写比例、真实并发模型去测，因为社区里流传的很多结论是在特定场景下成立的。我这次测出来的 BadgerDB 写入第一，但如果你在网上搜，会发现另一个博主用不同配置测出 RocksDB 第一，结论打架太正常了。
如果你现在还在犹豫，我给一条非常实用的建议：先想清楚你未来一年数据量的增长曲线，再决定要不要为 LSM 的调优复杂度买单。如果数据量稳定在百 GB 以内，读多写少，直接 bbolt 就好，别折腾；如果确定会高速增长到 TB 级，且写入是主路径，从 BadgerDB 入手会比直接上 RocksDB 平滑得多——先跑起来，再逐步深入调优，这是大多数团队更安全的路径。
