在目前的Mysql數據庫中，使用最廣泛的是innodb存儲引擎。innodb確實是個很不錯的存儲引擎，就連高性能Mysql里都說了，如果不是有什么很特別的要求，innodb就是最好的選擇。當然，這偏文章講的是TokuDB，不是innodb，相比innodb，TokuDB有著自己的特點。

轉自：http://www.kryptosx.info/archives/931.html

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。

因此，它適用于存檔，大量隨機插入的場景。

原文：http://www.cnblogs.com/bonelee/p/6245167.html

總結

以上是生活随笔為你收集整理的tokudb 分形树_分形树Fractal tree介绍——具体如何结合TokuDB还没有太懂，先记住其和LSM都是一样的适合写密集...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。