海量存储系列之九
終于來(lái)到了COLA樹(shù)系，這套東西目前來(lái)看呢，確實(shí)不如LSM火，不過(guò)作為可選方案，也是個(gè)值得了解的嘗試，不過(guò)這塊因?yàn)橹挥幸唤MMIT的人搞了個(gè)東西出來(lái)，所以其實(shí)真正的方案也語(yǔ)焉不詳?shù)摹男阅軄?lái)說(shuō)，tokuDB的寫(xiě)入性能很高，但更新似乎不是很給力，查詢(xún)較好，占用較少的內(nèi)存。
http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/
這里有一些性能上的指標(biāo)和分析性文字。確實(shí)看起來(lái)很心動(dòng)，不過(guò)這東西只適合磁盤(pán)結(jié)構(gòu)，到了SSD似乎就掛了。原因不詳，因?yàn)闆](méi)有實(shí)際的看過(guò)他們的代碼，所以一切都是推測(cè)，如果有問(wèn)題，請(qǐng)告知我。
先說(shuō)原理，上ppt?http://tokutek.com/presentations/bender-Scalperf-9-09.pdf，簡(jiǎn)單來(lái)說(shuō)，就是一幫MIT的小子們，分析了一下為什么磁盤(pán)寫(xiě)性能這么慢，讀的性能也這么慢，然后一拍腦袋，說(shuō)：“哎呀，我知道了，對(duì)于兩級(jí)的存儲(chǔ)（比如磁盤(pán)對(duì)應(yīng)內(nèi)存，或內(nèi)存對(duì)于緩存，有兩個(gè)屬性是會(huì)對(duì)整個(gè)查詢(xún)和寫(xiě)入造成影響的，一個(gè)是容量空間小但速度更快的存儲(chǔ)的size，另外一個(gè)則是一次傳輸?shù)腷lock的size.而我們要做的事情，就是盡可能讓每次的操作傳輸盡可能少的數(shù)據(jù)塊。
傳輸?shù)脑缴?#xff0c;那么查詢(xún)的性能就越好。
進(jìn)而，有人提出了更多種的解決方案。
?B-tree [Bayer, McCreight 72]
? cache-oblivious B-tree [Bender, Demaine, Farach-Colton 00]
? buffer tree [Arge 95]
? buffered-repositorytree[Buchsbaum,Goldwasser,Venkatasubramanian,Westbrook 00]
? Bε
tree[Brodal, Fagerberg 03]
? log-structured merge tree [O’Neil, Cheng, Gawlick, O’Neil 96]
? string B-tree [Ferragina, Grossi 99]
這些結(jié)構(gòu)都是用于解決這樣一個(gè)問(wèn)題，在磁盤(pán)上能夠創(chuàng)建動(dòng)態(tài)的有序查詢(xún)結(jié)構(gòu)。
在今天，主要想介紹的就是COLA，所謂cache-oblivious 就是說(shuō)，他不需要知道具體的內(nèi)存大小和一個(gè)塊的大小，或者說(shuō)，無(wú)論內(nèi)存多大，塊有多大，都可以使用同一套邏輯進(jìn)行處理，這無(wú)疑是具有優(yōu)勢(shì)的，因?yàn)閮?nèi)存大小雖然可以知道，但內(nèi)存是隨時(shí)可能被臨時(shí)的占用去做其他事情的，這時(shí)候，CO就非常有用了。
其他我就不多說(shuō)了，看一下細(xì)節(jié)吧~再說(shuō)這個(gè)我自己都快繞進(jìn)去了。
眾所周知的，磁盤(pán)需要的是順序?qū)懭?#xff0c;下一個(gè)問(wèn)題就是，怎么能夠保證數(shù)據(jù)的順序?qū)憽?/span>
我們假定有這樣一個(gè)空的數(shù)據(jù)集合
可以認(rèn)為樹(shù)的高度是log2N。
每行要么就是空的，要么就是滿的，每行數(shù)據(jù)都是排序后的數(shù)據(jù)。
如果再寫(xiě)一個(gè)值的時(shí)候，會(huì)寫(xiě)在第一行，比如寫(xiě)了3。
再寫(xiě)一個(gè)值11的時(shí)候，因?yàn)榈谝恍幸呀?jīng)寫(xiě)滿了，所以將3取出來(lái)，和11做排序，嘗試寫(xiě)第二行。又因?yàn)榈诙幸矟M了，所以將第二行的5和10也取出，對(duì)3,11,5,10 進(jìn)行排序。寫(xiě)入第四行
這就是COLA的寫(xiě)入過(guò)程。
可以很清楚的看出，COLA的核心其實(shí)和LSM類(lèi)似，每次“將數(shù)據(jù)從上一層取出，與外部數(shù)據(jù)進(jìn)行歸并排序后寫(xiě)入新的array”的這個(gè)操作，對(duì)sas磁盤(pán)非常友好。因此，寫(xiě)入性能就會(huì)有非常大的提升。
并且因?yàn)閿?shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，沒(méi)有維持太多額外的指針，所以相對(duì)的比較節(jié)省空間。
但這樣查詢(xún)會(huì)需要針對(duì)每個(gè)array都進(jìn)行一次二分查找。
性能似乎還不是很高，所以，他們想到了下面這種方式，把它的命名為fractal tree,分形樹(shù)。
用更簡(jiǎn)單的方法來(lái)說(shuō)的話呢，就是在merge的時(shí)候，上層持有下層數(shù)據(jù)的一個(gè)額外的指針。
來(lái)協(xié)助進(jìn)行二分查找。
這樣，利用空間換時(shí)間，他的查詢(xún)速度就又回到了log2N這個(gè)級(jí)別了。
到此，又一個(gè)有序結(jié)構(gòu)被我囫圇吞棗了。
嘿嘿
http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/
這里有一些性能上的指標(biāo)和分析性文字。確實(shí)看起來(lái)很心動(dòng)，不過(guò)這東西只適合磁盤(pán)結(jié)構(gòu)，到了SSD似乎就掛了。原因不詳，因?yàn)闆](méi)有實(shí)際的看過(guò)他們的代碼，所以一切都是推測(cè)，如果有問(wèn)題，請(qǐng)告知我。
先說(shuō)原理，上ppt?http://tokutek.com/presentations/bender-Scalperf-9-09.pdf，簡(jiǎn)單來(lái)說(shuō)，就是一幫MIT的小子們，分析了一下為什么磁盤(pán)寫(xiě)性能這么慢，讀的性能也這么慢，然后一拍腦袋，說(shuō)：“哎呀，我知道了，對(duì)于兩級(jí)的存儲(chǔ)（比如磁盤(pán)對(duì)應(yīng)內(nèi)存，或內(nèi)存對(duì)于緩存，有兩個(gè)屬性是會(huì)對(duì)整個(gè)查詢(xún)和寫(xiě)入造成影響的，一個(gè)是容量空間小但速度更快的存儲(chǔ)的size，另外一個(gè)則是一次傳輸?shù)腷lock的size.而我們要做的事情，就是盡可能讓每次的操作傳輸盡可能少的數(shù)據(jù)塊。
傳輸?shù)脑缴?#xff0c;那么查詢(xún)的性能就越好。
進(jìn)而，有人提出了更多種的解決方案。
?B-tree [Bayer, McCreight 72]
? cache-oblivious B-tree [Bender, Demaine, Farach-Colton 00]
? buffer tree [Arge 95]
? buffered-repositorytree[Buchsbaum,Goldwasser,Venkatasubramanian,Westbrook 00]
? Bε
tree[Brodal, Fagerberg 03]
? log-structured merge tree [O’Neil, Cheng, Gawlick, O’Neil 96]
? string B-tree [Ferragina, Grossi 99]
這些結(jié)構(gòu)都是用于解決這樣一個(gè)問(wèn)題，在磁盤(pán)上能夠創(chuàng)建動(dòng)態(tài)的有序查詢(xún)結(jié)構(gòu)。
在今天，主要想介紹的就是COLA，所謂cache-oblivious 就是說(shuō)，他不需要知道具體的內(nèi)存大小和一個(gè)塊的大小，或者說(shuō)，無(wú)論內(nèi)存多大，塊有多大，都可以使用同一套邏輯進(jìn)行處理，這無(wú)疑是具有優(yōu)勢(shì)的，因?yàn)閮?nèi)存大小雖然可以知道，但內(nèi)存是隨時(shí)可能被臨時(shí)的占用去做其他事情的，這時(shí)候，CO就非常有用了。
其他我就不多說(shuō)了，看一下細(xì)節(jié)吧~再說(shuō)這個(gè)我自己都快繞進(jìn)去了。
眾所周知的，磁盤(pán)需要的是順序?qū)懭?#xff0c;下一個(gè)問(wèn)題就是，怎么能夠保證數(shù)據(jù)的順序?qū)憽?/span>
我們假定有這樣一個(gè)空的數(shù)據(jù)集合
可以認(rèn)為樹(shù)的高度是log2N。
每行要么就是空的，要么就是滿的，每行數(shù)據(jù)都是排序后的數(shù)據(jù)。
如果再寫(xiě)一個(gè)值的時(shí)候，會(huì)寫(xiě)在第一行，比如寫(xiě)了3。
再寫(xiě)一個(gè)值11的時(shí)候，因?yàn)榈谝恍幸呀?jīng)寫(xiě)滿了，所以將3取出來(lái)，和11做排序，嘗試寫(xiě)第二行。又因?yàn)榈诙幸矟M了，所以將第二行的5和10也取出，對(duì)3,11,5,10 進(jìn)行排序。寫(xiě)入第四行
這就是COLA的寫(xiě)入過(guò)程。
可以很清楚的看出，COLA的核心其實(shí)和LSM類(lèi)似，每次“將數(shù)據(jù)從上一層取出，與外部數(shù)據(jù)進(jìn)行歸并排序后寫(xiě)入新的array”的這個(gè)操作，對(duì)sas磁盤(pán)非常友好。因此，寫(xiě)入性能就會(huì)有非常大的提升。
并且因?yàn)閿?shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，沒(méi)有維持太多額外的指針，所以相對(duì)的比較節(jié)省空間。
但這樣查詢(xún)會(huì)需要針對(duì)每個(gè)array都進(jìn)行一次二分查找。
性能似乎還不是很高，所以，他們想到了下面這種方式，把它的命名為fractal tree,分形樹(shù)。
用更簡(jiǎn)單的方法來(lái)說(shuō)的話呢，就是在merge的時(shí)候，上層持有下層數(shù)據(jù)的一個(gè)額外的指針。
來(lái)協(xié)助進(jìn)行二分查找。
這樣，利用空間換時(shí)間，他的查詢(xún)速度就又回到了log2N這個(gè)級(jí)別了。
到此，又一個(gè)有序結(jié)構(gòu)被我囫圇吞棗了。
嘿嘿
在下一篇，我們將進(jìn)入大家期待的分布式k-V場(chǎng)景，也就是noSQL的范疇了，讓我們撥開(kāi)nosql的神秘面紗，看看這東西到底意味著什么。
本文來(lái)源于"阿里中間件團(tuán)隊(duì)播客",原文發(fā)表時(shí)間"2012-01-06"
總結(jié)
- 上一篇： CSS 布局实例系列（三）如何实现一个左
- 下一篇： Junit之Test测试