在目前的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(分形树)简介

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

数据插入：


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

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

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

最后的结果：


总体来看:


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

没明白的：

插入复杂度为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)。


看到的另一种优化办法：


总结：

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

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

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