Go语言实现LSM树存储：BadgerDB嵌入式数据库指南

BadgerDB 是一款纯 Go 编写的嵌入式 KV 数据库，虽基于 LSM 树核心思想，却通过独创的 value 分离存储设计（key 与指针进入 LSM 结构，value 独立写入只追加的 log 文件）显著降低读放大，尤其适合高吞吐写入和大 Value 场景（如 JSON、Protobuf）；但这也带来了 GC 复杂、value 不可原地修改、以及索引与实际数据可能短暂不一致的风险——比如 Get 返回键不存在而 Iterator 却能遍历到，正是 value log 被回收但索引未及时清理的典型表现；它不是 LevelDB/RocksDB 的简单移植，而是在强 ACID 事务、内存稳定性与写性能间做出差异化取舍的新一代 LSM 实现。

BadgerDB 是 LSM 树吗？它和 LevelDB/RocksDB 有什么实质区别

是，BadgerDB 是纯 Go 实现的、基于 LSM 树结构的嵌入式 KV 数据库。但它不是 LevelDB 或 RocksDB 的 Go 移植版，而是从头设计的——关键差异在 value 分离存储：Badger 把 value 单独写入 value log 文件，key 和 value pointer 才进 LSM memtable/sstables。这带来两个直接后果：读放大更低（尤其大 value 场景），但 GC 更复杂，且 value log 不支持随机删改。

常见错误现象：Get 返回 ErrKeyNotFound，但用 Iterator 能扫到 key —— 很可能 value log 被 GC 掉了而索引没及时更新（尤其低频写+手动调 RunValueLogGC 不足时）。

• 适用场景：高吞吐写入、value 大小不均（如存 JSON blob、protobuf）、需要强 ACID 单机事务
• 不适用场景：要求原地更新 value、依赖 RocksDB 的 compaction 策略调优、或需要 ColumnFamily
• 性能影响：value 超过 ~1KB 时，Badger 比 RocksDB 内存占用更稳；但小 value（

初始化 BadgerDB 时必须注意的 3 个配置项

Options 里最关键的不是 Dir 或 ValueDir，而是 SyncWrites、NumVersionsToKeep 和 MaxTableSize。它们直接决定数据可见性、磁盘膨胀速度和查询延迟。

• SyncWrites = false 是默认值，但生产环境写入量大时容易丢数据——WAL 不落盘，进程崩溃就丢最近一批未 flush 的 memtable。设为 true 会降写入吞吐约 15–30%，但保证 crash-safe
• NumVersionsToKeep = 1（默认）够用，但如果业务依赖多版本读（比如做简易 MVCC 快照），要提前设高；设太高会导致旧 SST 文件长期不被清理，磁盘涨得快
• MaxTableSize 默认 64MB，对 SSD 友好；但机械盘上建议提到 128–256MB，减少 compaction 频次和小文件数量

示例：

opt := badger.DefaultOptions("/tmp/badger").WithSyncWrites(true).WithNumVersionsToKeep(1)

事务中 Get/Set 后忘记 Commit 或 Discard 就会卡住后续操作

Badger 的事务不是“自动提交”的，txn.Commit() 或 txn.Discard() 必须显式调用。漏掉会导致：内存泄漏（memtable 不释放） + 后续 Update 事务阻塞在 pendingWrites 队列，表现为你发了新写请求但一直没返回。

• 最安全写法：用 defer txn.Discard() 开头，再 if err == nil { txn.Commit() } 结尾
• 不要在事务里调用外部 HTTP 请求或长耗时逻辑——Badger 事务持有锁，会拖慢整个 DB 的写入吞吐
• 读事务（db.NewTransaction(false)）不用 Commit，但也要 Discard，否则 iterator 句柄不释放，SST 文件引用计数不下，GC 无法清理

Value log GC 不触发？别只盯着 RunValueLogGC

RunValueLogGC 不是定时器，它是一次性尝试回收 value log 中被覆盖/删除的 value 空间。失败很常见，原因通常是：当前 value log 文件太“热”（还有活跃 key 指向它），或者 DropRatio 设太高（默认 0.5，意思是至少 50% space 可回收才动手）。

• 先检查 ValueLogSize 和 ValueLogSizeAtLastGC（通过 db.Stats()），确认确实在涨
• 降低 DropRatio 到 0.3～0.4，再调 RunValueLogGC，成功率明显上升
• GC 过程中会阻塞写入，所以最好选低峰期做；频繁 GC（比如每分钟一次）说明 value 更新太猛，考虑把大 value 改成外存路径存，只在 Badger 存 URL

真正容易被忽略的是：Badger 的 GC 不清理 SST 文件里的 stale key，那是靠后台 compaction 自动做的——如果你关了 CompactL0OnClose 或 KeepL0InMemory，L0 层堆积太多小文件，查询会变慢，且 GC 效果打折。

理论要掌握，实操不能落！以上关于《Go语言实现LSM树存储：BadgerDB嵌入式数据库指南》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！