如何通过BadgerDB在Go语言中高效构建LSM树型存储结构？

本文共计1021个文字，预计阅读时间需要5分钟。

BadgerDB 是一个纯 Go 语言实现的、基于 LSM 树结构的嵌入式 KV 数据库。与 LevelDB 或 RocksDB 的 Go 移植版不同，BadgerDB 是从头设计的——它通过将 value 的差异存储在单独的文件中来分离 key 和 value：

常见错误现象：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)

立即学习“go语言免费学习笔记（深入）”；

事务中 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 效果打折。