MONGODB 到底支持不支持lsm? 与 成本控制DUMP ROCKSDB

最近遇到两个问题,wriedtiger引擎到底支持不支持LSM tree , 2 为什么percona的mongodb Dump 了ROCKSDB 的数据库引擎.

首先 BTREE 和 LSM TREE 之间的区别需要讲清

1 BTREE 的优点,数据有序存储,读取范围性的数据速度快,基于传统磁盘原理,通过索引快速定位数据

2 LSM TREE 的优点,更大容量的数据存储,采用合并机制,对于SSD 磁盘有更改的适应性,通过BLOOM 过滤的方式查找数据,速度也不慢

大致LSM TREE 工作的原理

在内存中对进入到mongodb wiretiger lsm tree 中的内存树达到阈值大小，随即创建一个新的内存树，将旧树同步到磁盘,在写入磁盘后，树是只读的，在磁盘上对LSM树合并.

WiredTiger在合并时创建一个Bloom过滤器,这是一个附加的文件，每个密钥包含一个可配置的位数(默认为8),密钥按可配置的次数(默认为4)进行散列，并设置相应的位,Bloom过滤器用于避免在密钥不存在时从块中读取。

以上的信息其实是从wiredtiger的数据库引擎的help 页面中找到的.

https://github.com/wiredtiger/wiredtiger/wiki/Btree-vs-LSM

在wiredtiger的github 上有相关的的对比

文字中,最终总结了几点

1 Btree 的数据存储结构方式在大部分情况中是可以满足,写入和查询的需求的, LSM TREE 会根据数据的插入,定期的进行后台的维护,(与原理有关).

2 如果有大量的写操作的需求,则LSM TREE 是一种替换BTREE 更好的选择

3 测试中仅仅是针对简单的数据模式

4 如果数据库中的collections 的需求比较复杂,则可以在一个DATABASE中选择适合的 lsm 和 btree 混合的模式.

但实际上在操作中发现即使按照wiredtiger提供的方式来还是写入到了btree的,到底是因为什么,下面的图给了,截止目前为止虽然wiredtiger 可以早创建collecion的时候,选择数据结构是LSM 但仅仅是一种配置方面的测试接口,并不是说通过此种方式生成的,collection就是LSM数据存储结构.但还是秉着疑问的状态对此进行了测试

下面生成了一个lsm tree 结构的collection 并且建立一个 lsm tree的索引

通过截图可以观察到,我们建立的相关的collection 和 index 都在尾缀上

有相关标识.

实际上我们在通过2000个连接每个连接插入200000数据的方式,看1分钟那种方式插入的数据比较多,作为一个衡量的标准. 多次测试,最终结果都是使用了lsm tree config 的collection 比 btree的collection 要插入数据的性能要好,但相关的优势稍有不稳定.

另外一个问题,为什么percona Mongodb 从3.6开始,直接dump了 rocksdb数据库引起(facebook 的 lsm tree 的数据库结构存储引起)

percona 给出的答案

1 在服务客户中,大部分客户没有必须使用lsm tree 的必须的需求,大部分客户都是使用wiredtiger 数据库引擎.

2 从MONGODB 的发展看,3.6中的新功能都是围绕wiredtiger数据库引擎研发的,并且4.0 将去掉MMAPV1 数据库引擎,未来众多的新功能大部分都会围绕wiredtiger数据库引擎,所以rocksdb数据库引擎如果想在MONGODB上达到同样的多文档事务,以及其他的新功能,代码的改动将是巨大的, 所以这就与相关的付出的成本有关了.

1 ROCKSDB 的数据库引擎在MONGODB 上不是主流,并且使用的客户也未在使用中提出上面的大面积写入特殊的要求.

2 MONGODB 公司在新版本以及现有版本中对wiredtiger数据库引擎的倾斜,如同MYSQL 之前有众多的数据库引擎可以选择,但最终提到MYSQL 和提到 INNODB 是一个意思, 提到MONGODB 和提到wiredtiger 数据库引擎也是一个意思.