Mysql存储引擎之TokuDB以及它的数据结构Fractal tree(分形树)

在目前的Mysql数据库中,使用最广泛的是innodb存储引擎。innodb确实是个很不错的存储引擎,就连高性能Mysql里都说了,如果不是有什么很特别的要求,innodb就是最好的选择。当然,这偏文章讲的是TokuDB,不是innodb,相比innodb,TokuDB有着自己的特点。

BTree和Fractal tree的比较:

目前无论是SQL Server,还是MySQL的innodb,都是用的B+Tree(SQL Server用的是标准的B-Tree)的索引结构。从理论上来说,这个结构在查询过程中应该是不会慢的,此类基于比较的数据结构查询复平均杂度都是logn。B类树就是对于这个进行了优化,让它更适应磁盘,降低树的深度。

随机IO几乎是令所有DBA谈虎色变的一个问题,当数据量小的时候,所有数据都能到内存中那就没有这个问题(其实这个时候也就没有必要用B-Tree的这种块结构了),但是一旦数据量大于内存的话这个问题就出现了。其实从本质来说,k-v存储要解决的问题就是这么一个:尽可能快得写入,以及尽可能快的读取。

这也是设计数据结构时考虑最多的问题,在分析解决方法之前,我们讨论几个极端。走一个极端的话,如果我每次写数据都顺序写,那么对Insert来说的话是最快的,但是每次Query就需要Scan一遍整个表。那么如果我想获取最佳的读性能,那么方法就是像B-Tree那样全部排个序呗。但是因为B-Tree有那样的随机IO,这样我们有没有办法得到顺序写的写性能,

所以,TokuDB中使用了一个称之为Fractal tree(分形树)的索引结构来解决随机IO的问题。它主要是能让随机IO变成顺序IO。

Structure Inserts Point Queries Range Queries
B-Tree Horrible Good Good (young)
Append Wonderful Horrible Horrible
Fractal Tree Good Good Good

Fractal tree(分形树)简介

我们假设有这样一种集合的结构,相邻行空间加倍。每一行要么全满要么全空,全满行的数据都是排好序的。

数据插入:

tokudb1

以上图的数据存储状态为例,如果再写一个值的时候,会写在第一行,比如写了3,这个时候第一行是空的,所以就放到第一行。

再写一个值11的时候,因为第一行已经写满了,所以将3取出来,和11做排序,尝试写第二行。

又因为第二行也满了,所以将第二行的5和10也取出,对3,11,5,10进行排序。写入第三行。

最后的结果:

tokudb2

总体来看:

tokudb3

可以看出,这个数据结构能保证数据块都是满的。如果前面都满了,就会一层层合并下去,直到找到可以写入的块。

没明白的:

插入复杂度为O(log(N)/B),B是一个块存储的数据行数,N是数据量。但是我只想到O(N/B)的复杂度。据说是进行了优化得到的,不过没看懂。

提一下:BTree的复杂度为O(log(N)/log(B)),这是树的深度。B其实就是树的度,树的度越大,深度越低,成对数关系。

总结下Fractal Tree结构特点

  • 由多个有序的数组构成,大小呈指数级增长
  • 数组要么全空,要么全满
  • 数据插入到最小的数组,如果空间不够就将数据进行Merge

查询性能:

如果不进行优化,查询性能并不好。我们需要扫描每一层,最坏情况下IO次数达 log2N。

为了提高查找的性能,TokuDB在每个数据上加了一个forwardpointer,指向下一行中第一个比它大的数据的位置(这个叫做Fractional Cascading)。平均地看,上一级的每个数都把下一级搜索范围限制到了常数个,所以磁盘IO的次数最差应该为O(logN)。

tokudb5

 

 

看到的另一种优化办法:

tokudb4

总结:

TokuDB主要的优点在于把随机的IO转换成顺序的IO写入。因此获得很好的写入速度,也因为这个,有很好的数据压缩效果。但如果是顺序写入,性能不如BTree。

因此,它适用于存档,大量随机插入的场景。

整个分形树设计感觉有点像二进制优化的逆向处理。是个挺有意思的数据结构。

参考资料:

How TokuDB Fractal Tree Databases Work Presentation

转载请注明:旅途@KryptosX » Mysql存储引擎之TokuDB以及它的数据结构Fractal tree(分形树)

posted @ 2016-08-09 17:01  ThinkDiff  阅读(1132)  评论(0编辑  收藏  举报