原文：https://colobu.com/2017/10/11/badger-a-performant-k-v-store/
github地址：https://github.com/dgraph-io/badger
badger
大家好，给大家介绍一下， 新晋的高性能的 K/V数据库: badger。
这是 dgraph.io开发的一款基于 log structured merge (LSM) tree 的 key-value 本地数据库， 使用 Go 开发。
事实上，市面上已经有一些知名的基于LSM tree的k/v数据库， 比如 leveldb、goleveldb、rocksdb、boltdb, 可是为什么还要创造新的轮子呢。我们不妨从LSM说起。
优势：对于随机读，Badger至少要比RocksDB快3.5倍，对于值的大小从128B到16KB，数据加载Badger比LevelDB快0.86 - 14倍
Badger分离的key和value,只有key存在LSM tree中， value存在WAL中，叫做value log。通常情况下，key比较小，所以LSM tree比较小，当获取value值的时候，再从SSD存储中读取。现在的SSD， 比如Samsung 960 Pro，对于4KB的数据块，可以提供44万的读操作/秒，这相当快了。
LSM tree最主要的性能消耗在于 compaction 过程。 在compaction的时候，多个文件需要读进内存，排序，然后再写回。每个文件都固定大小，如果文件中包含value, 文件大小会显著的增加，compaction会更频繁地发生。Badger不存储value，而是存储value的指针， 如果每个键是16， 每个value的指针是16 byte的话，一个64MB的文件就可以存储200万个键值对。
因为Badger不存储value，而是存储value的指针,compaction的时候只移动key和value指针，对于 1KB大小的value和16 byte的key， 写放大为(10*16 + 1024)/(16 + 1024) ~ 1.14。
因为Badger的LSM tree比较小，所以它的层级相对于普通的LSM tree要少，这也意味着查找会更少。例如1KB大小的value, 22byte的key, 7500万条数据的原始大小是 72GB,但是对于Badger的LSM tree来说，只需要1.7G,完全可以放在内存中，这也是Badger的随机读比RocksDB快3.5的原因。
容错
LSM tree将所有的更新写入到内存中的memtable，一旦填满， memtable回替换为immutable memtable，最终回写入到磁盘中的level0中。
如果机器宕机，内存表中的数据就会丢失。k/v数据库一般使用write-ahead log (WAL)来处理这个问题，Badger也一样。Badger会记录memtable的最后一个值的指针，当恢复的时候，它可以replay和重建LSM tree。
文件大小
Badger还使用技术对value值进行压缩，以便是log文件更小。
对于1KB的value,16 byte的key, 7500万条数据，RocksDB的 LSM tree 是 50GB， Badger的 value log文件是74GB(未压缩)， LSM tree 是 1.7GB。
使用
Badger使用起来超级简单， 配置参数页不多，而且提供了默认的配置参数。
下面的代码是读写查和便利的代码，所有的操作都是在事务中完成的， Badger的事物是基于MVCC实现的。