在目前的Mysql數(shù)據(jù)庫(kù)中，使用最廣泛的是innodb存儲(chǔ)引擎。innodb確實(shí)是個(gè)很不錯(cuò)的存儲(chǔ)引擎，就連高性能Mysql里都說(shuō)了，如果不是有什么很特別的要求，innodb就是最好的選擇。當(dāng)然，這偏文章講的是TokuDB，不是innodb，相比innodb，TokuDB有著自己的特點(diǎn)。

轉(zhuǎn)自：http://www.kryptosx.info/archives/931.html

BTree和Fractal tree的比較：

目前無(wú)論是SQL Server，還是MySQL的innodb，都是用的B+Tree(SQL Server用的是標(biāo)準(zhǔn)的B-Tree)的索引結(jié)構(gòu)。從理論上來(lái)說(shuō)，這個(gè)結(jié)構(gòu)在查詢過(guò)程中應(yīng)該是不會(huì)慢的，此類基于比較的數(shù)據(jù)結(jié)構(gòu)查詢復(fù)平均雜度都是logn。B類樹(shù)就是對(duì)于這個(gè)進(jìn)行了優(yōu)化，讓它更適應(yīng)磁盤，降低樹(shù)的深度。

隨機(jī)IO幾乎是令所有DBA談虎色變的一個(gè)問(wèn)題，當(dāng)數(shù)據(jù)量小的時(shí)候，所有數(shù)據(jù)都能到內(nèi)存中那就沒(méi)有這個(gè)問(wèn)題(其實(shí)這個(gè)時(shí)候也就沒(méi)有必要用B-Tree的這種塊結(jié)構(gòu)了)，但是一旦數(shù)據(jù)量大于內(nèi)存的話這個(gè)問(wèn)題就出現(xiàn)了。其實(shí)從本質(zhì)來(lái)說(shuō)，k-v存儲(chǔ)要解決的問(wèn)題就是這么一個(gè)：盡可能快得寫入，以及盡可能快的讀取。

這也是設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)時(shí)考慮最多的問(wèn)題，在分析解決方法之前，我們討論幾個(gè)極端。走一個(gè)極端的話，如果我每次寫數(shù)據(jù)都順序?qū)?#xff0c;那么對(duì)Insert來(lái)說(shuō)的話是最快的，但是每次Query就需要Scan一遍整個(gè)表。那么如果我想獲取最佳的讀性能，那么方法就是像B-Tree那樣全部排個(gè)序唄。但是因?yàn)锽-Tree有那樣的隨機(jī)IO，這樣我們有沒(méi)有辦法得到順序?qū)懙膶懶阅?#xff0c;

所以，TokuDB中使用了一個(gè)稱之為Fractal tree(分形樹(shù))的索引結(jié)構(gòu)來(lái)解決隨機(jī)IO的問(wèn)題。它主要是能讓隨機(jī)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(分形樹(shù))簡(jiǎn)介

我們假設(shè)有這樣一種集合的結(jié)構(gòu)，相鄰行空間加倍。每一行要么全滿要么全空，全滿行的數(shù)據(jù)都是排好序的。

數(shù)據(jù)插入：

以上圖的數(shù)據(jù)存儲(chǔ)狀態(tài)為例，如果再寫一個(gè)值的時(shí)候，會(huì)寫在第一行，比如寫了3，這個(gè)時(shí)候第一行是空的，所以就放到第一行。

再寫一個(gè)值11的時(shí)候，因?yàn)榈谝恍幸呀?jīng)寫滿了，所以將3取出來(lái)，和11做排序，嘗試寫第二行。

又因?yàn)榈诙幸矟M了，所以將第二行的5和10也取出，對(duì)3,11,5,10進(jìn)行排序。寫入第三行。

最后的結(jié)果：

總體來(lái)看:

可以看出，這個(gè)數(shù)據(jù)結(jié)構(gòu)能保證數(shù)據(jù)塊都是滿的。如果前面都滿了，就會(huì)一層層合并下去，直到找到可以寫入的塊。

沒(méi)明白的：

插入復(fù)雜度為O(log(N)/B)，B是一個(gè)塊存儲(chǔ)的數(shù)據(jù)行數(shù)，N是數(shù)據(jù)量。但是我只想到O(N/B)的復(fù)雜度。據(jù)說(shuō)是進(jìn)行了優(yōu)化得到的，不過(guò)沒(méi)看懂。

提一下：BTree的復(fù)雜度為O(log(N)/log(B))，這是樹(shù)的深度。B其實(shí)就是樹(shù)的度，樹(shù)的度越大，深度越低，成對(duì)數(shù)關(guān)系。

總結(jié)下Fractal Tree結(jié)構(gòu)特點(diǎn)

由多個(gè)有序的數(shù)組構(gòu)成，大小呈指數(shù)級(jí)增長(zhǎng)

數(shù)組要么全空，要么全滿

數(shù)據(jù)插入到最小的數(shù)組，如果空間不夠就將數(shù)據(jù)進(jìn)行Merge

查詢性能：

如果不進(jìn)行優(yōu)化，查詢性能并不好。我們需要掃描每一層，最壞情況下IO次數(shù)達(dá)?log2N。

為了提高查找的性能，TokuDB在每個(gè)數(shù)據(jù)上加了一個(gè)forwardpointer，指向下一行中第一個(gè)比它大的數(shù)據(jù)的位置(這個(gè)叫做Fractional Cascading)。平均地看，上一級(jí)的每個(gè)數(shù)都把下一級(jí)搜索范圍限制到了常數(shù)個(gè)，所以磁盤IO的次數(shù)最差應(yīng)該為O(logN)。

看到的另一種優(yōu)化辦法：

總結(jié)：

TokuDB主要的優(yōu)點(diǎn)在于把隨機(jī)的IO轉(zhuǎn)換成順序的IO寫入。因此獲得很好的寫入速度，也因?yàn)檫@個(gè)，有很好的數(shù)據(jù)壓縮效果。但如果是順序?qū)懭?#xff0c;性能不如BTree。

因此，它適用于存檔，大量隨機(jī)插入的場(chǎng)景。

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。