RocksDB 还提供了一个 Column Family 的功能，设计上就和 MySQL 的分表差不多，就是人为地将数据分散到多个 Column Families 中（例如按 key 的首字节或 hash 来分库），使多个 Column Families 可以并发读写。相对于手动分到多个 db 而言，利用 Column Family 可以原子性地操作多个 Column Families 中的数据，并且能保持它们在一个事务中的一致性。

RocksDB 就讲到这里，接下来看看其他的选项。

LMDB

我最先看中的是 LMDB，因为很多评测都说它比 RocksDB 更快，性能波动更小。它的原理是用 MMAP 将数据文件映射到内存中，也就避免了写入时的系统调用（实际上 RocksDB 将数据合并后一次性的顺序写也没有多少开销），但是一页（4 KB）只能存放 2 条数据，而且不会进行块压缩，所以比较费空间；数据结构选的是 B+ 树，因此读性能是很好的。
直觉上我觉得 B+ 树的随机写入会很慢，实际测试确实如此，并且随着数据量的增大，写入速度基本是指数级下降的，于是果断放弃了。

BadgerDB

接着就找到了 BadgerDB，它的原理和 LevelDB 差不多，但是又做了个重要的优化：将 key 和 value 分开存放。因为 key 的空间占用会小很多，所以更容易放入内存中，能加快查询速度。而在合并时，合并 key 的开销很小（只是修改 value 的索引地址），合并 value 也只是删掉老的 value 即可，甚至不需要和 key 的合并同步进行，定期清理下就行了。而且因为 key 单独存放，所以遍历 key 和测试 key 是否存在也会快很多。不过如果 value 长度很小，那么分开存放反而增加了一次随机读，这是要结合实际项目来考虑的。
我测试发现随机读确实挺快，大概是 RocksDB 的 100 倍；但随机写没有太大优势，和 universal 的 RocksDB 差不多，而后者可以关闭 WAL 以大幅提高写入速度。

虽然空间占用比 RocksDB 要高一些（大概 10%），但是打开数据库的速度却要快几倍，也许是只需要加载 key 的原因。
而在内存占用方面，BadgerDB 比 RocksDB 更吃内存些，并且随着数据量的增长，占用的内存也越来越多，如果物理内存不够的话，就会使用 SWAP，并导致写入速度变慢。

在我的 SSD 上测试时发现 LoadToRAM 和 MemoryMap 相对于 FileIO 没有太大的优势，但是内存占用会多很多，所以我将默认的配置各降了一级：

opts.TableLoadingMode = options.MemoryMap
opts.ValueLogLoadingMode = options.FileIO

对于内存足够的场景而言，BadgerDB 确实是一个很好的 RocksDB 替代品，因为大部分情况下是读多写少的。而它的缺点也很明显，只有 Go 语言的版本，没有其他语言的 binding。

TerarkDB

最后一个吸引我眼球的是 TerarkDB。它在 RocksDB 的基础上进行了改进，将所有 key 进行了可检索压缩，这个压缩算法能在不解压的情况下进行搜索，而 value 则进行了可定点访问的压缩，可以直接定位并解压需要的部分。这种实现使得缓存能更高效地使用，也能利用上 SSD 的随机读较快的优点，相当于把很多需要读磁盘的操作在内存中搞定了。另外，全局压缩比 RocksDB 使用的块压缩的压缩率更高，所以需要写入的数据会减少，也会改善写入速度。而在合并时，它选择采用 universal 的风格以减少写入放大。
它最大的缺点就是核心代码没有开源，压缩算法也是专利，需要购买商业版来使用，所以我就不测试了。

总结

综上，对于几十 GB ~ 几百 GB 的 key / value 数据而言，如果只使用 Go 来开发的话，BadgerDB 在很多情况下是很好的选择，否则也只剩 RocksDB 了。