海量存储系列之九
終于來到了COLA樹系，這套東西目前來看呢，確實不如LSM火，不過作為可選方案，也是個值得了解的嘗試，不過這塊因為只有一組MIT的人搞了個東西出來，所以其實真正的方案也語焉不詳的。從性能來說，tokuDB的寫入性能很高，但更新似乎不是很給力，查詢較好，占用較少的內存。
http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/
這里有一些性能上的指標和分析性文字。確實看起來很心動，不過這東西只適合磁盤結構，到了SSD似乎就掛了。原因不詳，因為沒有實際的看過他們的代碼，所以一切都是推測，如果有問題，請告知我。
先說原理，上ppt?http://tokutek.com/presentations/bender-Scalperf-9-09.pdf，簡單來說，就是一幫MIT的小子們，分析了一下為什么磁盤寫性能這么慢，讀的性能也這么慢，然后一拍腦袋，說：“哎呀，我知道了，對于兩級的存儲（比如磁盤對應內存，或內存對于緩存，有兩個屬性是會對整個查詢和寫入造成影響的，一個是容量空間小但速度更快的存儲的size，另外一個則是一次傳輸的block的size.而我們要做的事情，就是盡可能讓每次的操作傳輸盡可能少的數據塊。
傳輸的越少，那么查詢的性能就越好。
進而，有人提出了更多種的解決方案。
?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]
這些結構都是用于解決這樣一個問題，在磁盤上能夠創建動態的有序查詢結構。
在今天，主要想介紹的就是COLA，所謂cache-oblivious 就是說，他不需要知道具體的內存大小和一個塊的大小，或者說，無論內存多大，塊有多大，都可以使用同一套邏輯進行處理，這無疑是具有優勢的，因為內存大小雖然可以知道，但內存是隨時可能被臨時的占用去做其他事情的，這時候，CO就非常有用了。
其他我就不多說了，看一下細節吧~再說這個我自己都快繞進去了。
眾所周知的，磁盤需要的是順序寫入，下一個問題就是，怎么能夠保證數據的順序寫。
我們假定有這樣一個空的數據集合
可以認為樹的高度是log2N。
每行要么就是空的，要么就是滿的，每行數據都是排序后的數據。
如果再寫一個值的時候，會寫在第一行，比如寫了3。
再寫一個值11的時候，因為第一行已經寫滿了，所以將3取出來，和11做排序，嘗試寫第二行。又因為第二行也滿了，所以將第二行的5和10也取出，對3,11,5,10 進行排序。寫入第四行
這就是COLA的寫入過程。
可以很清楚的看出，COLA的核心其實和LSM類似，每次“將數據從上一層取出，與外部數據進行歸并排序后寫入新的array”的這個操作，對sas磁盤非常友好。因此，寫入性能就會有非常大的提升。
并且因為數據結構簡單，沒有維持太多額外的指針，所以相對的比較節省空間。
但這樣查詢會需要針對每個array都進行一次二分查找。
性能似乎還不是很高，所以，他們想到了下面這種方式，把它的命名為fractal tree,分形樹。
用更簡單的方法來說的話呢，就是在merge的時候，上層持有下層數據的一個額外的指針。
來協助進行二分查找。
這樣，利用空間換時間，他的查詢速度就又回到了log2N這個級別了。
到此，又一個有序結構被我囫圇吞棗了。
嘿嘿
http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/
這里有一些性能上的指標和分析性文字。確實看起來很心動，不過這東西只適合磁盤結構，到了SSD似乎就掛了。原因不詳，因為沒有實際的看過他們的代碼，所以一切都是推測，如果有問題，請告知我。
先說原理，上ppt?http://tokutek.com/presentations/bender-Scalperf-9-09.pdf，簡單來說，就是一幫MIT的小子們，分析了一下為什么磁盤寫性能這么慢，讀的性能也這么慢，然后一拍腦袋，說：“哎呀，我知道了，對于兩級的存儲（比如磁盤對應內存，或內存對于緩存，有兩個屬性是會對整個查詢和寫入造成影響的，一個是容量空間小但速度更快的存儲的size，另外一個則是一次傳輸的block的size.而我們要做的事情，就是盡可能讓每次的操作傳輸盡可能少的數據塊。
傳輸的越少，那么查詢的性能就越好。
進而，有人提出了更多種的解決方案。
?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]
這些結構都是用于解決這樣一個問題，在磁盤上能夠創建動態的有序查詢結構。
在今天，主要想介紹的就是COLA，所謂cache-oblivious 就是說，他不需要知道具體的內存大小和一個塊的大小，或者說，無論內存多大，塊有多大，都可以使用同一套邏輯進行處理，這無疑是具有優勢的，因為內存大小雖然可以知道，但內存是隨時可能被臨時的占用去做其他事情的，這時候，CO就非常有用了。
其他我就不多說了，看一下細節吧~再說這個我自己都快繞進去了。
眾所周知的，磁盤需要的是順序寫入，下一個問題就是，怎么能夠保證數據的順序寫。
我們假定有這樣一個空的數據集合
可以認為樹的高度是log2N。
每行要么就是空的，要么就是滿的，每行數據都是排序后的數據。
如果再寫一個值的時候，會寫在第一行，比如寫了3。
再寫一個值11的時候，因為第一行已經寫滿了，所以將3取出來，和11做排序，嘗試寫第二行。又因為第二行也滿了，所以將第二行的5和10也取出，對3,11,5,10 進行排序。寫入第四行
這就是COLA的寫入過程。
可以很清楚的看出，COLA的核心其實和LSM類似，每次“將數據從上一層取出，與外部數據進行歸并排序后寫入新的array”的這個操作，對sas磁盤非常友好。因此，寫入性能就會有非常大的提升。
并且因為數據結構簡單，沒有維持太多額外的指針，所以相對的比較節省空間。
但這樣查詢會需要針對每個array都進行一次二分查找。
性能似乎還不是很高，所以，他們想到了下面這種方式，把它的命名為fractal tree,分形樹。
用更簡單的方法來說的話呢，就是在merge的時候，上層持有下層數據的一個額外的指針。
來協助進行二分查找。
這樣，利用空間換時間，他的查詢速度就又回到了log2N這個級別了。
到此，又一個有序結構被我囫圇吞棗了。
嘿嘿
在下一篇，我們將進入大家期待的分布式k-V場景，也就是noSQL的范疇了，讓我們撥開nosql的神秘面紗，看看這東西到底意味著什么。
本文來源于"阿里中間件團隊播客",原文發表時間"2012-01-06"
總結
- 上一篇： CSS 布局实例系列（三）如何实现一个左
- 下一篇： Junit之Test测试