LSM樹以及在hbase中的應用

轉自：http://www.cnblogs.com/yanghuahui/p/3483754.html

講LSM樹以前，須要提下三種基本的存儲引擎，這樣才能清楚LSM樹的由來：

• 哈希存儲引擎  是哈希表的持久化實現，支持增、刪、改以及隨機讀取操做，但不支持順序掃描，對應的存儲系統爲key-value存儲系統。對於key-value的插入以及查詢，哈希表的複雜度都是O(1)，明顯比樹的操做O(n)快,若是不須要有序的遍歷數據，哈希表就是your Mr.Right
• B樹存儲引擎是B樹（關於B樹的由來，數據結構以及應用場景能夠看以前一篇博文）的持久化實現，不只支持單條記錄的增、刪、讀、改操做，還支持順序掃描（B+樹的葉子節點之間的指針），對應的存儲系統就是關係數據庫（Mysql等）。
• LSM樹（Log-Structured Merge Tree）存儲引擎和B樹存儲引擎同樣，一樣支持增、刪、讀、改、順序掃描操做。並且經過批量存儲技術規避磁盤隨機寫入問題。固然凡事有利有弊，LSM樹和B+樹相比，LSM樹犧牲了部分讀性能，用來大幅提升寫性能。

經過以上的分析，應該知道LSM樹的由來了，LSM樹的設計思想很是樸素：將對數據的修改增量保持在內存中，達到指定的大小限制後將這些修改操做批量寫入磁盤，不過讀取的時候稍微麻煩，須要合併磁盤中歷史數據和內存中最近修改操做，因此寫入性能大大提高，讀取時可能須要先看是否命中內存，不然須要訪問較多的磁盤文件。極端的說，基於LSM樹實現的HBase的寫性能比Mysql高了一個數量級，讀性能低了一個數量級。

LSM樹原理把一棵大樹拆分紅N棵小樹，它首先寫入內存中，隨着小樹愈來愈大，內存中的小樹會flush到磁盤中，磁盤中的樹按期能夠作merge操做，合併成一棵大樹，以優化讀性能。

 

以上這些大概就是HBase存儲的設計主要思想，這裏分別對應說明下：

• 由於小樹先寫到內存中，爲了防止內存數據丟失，寫內存的同時須要暫時持久化到磁盤，對應了HBase的MemStore和HLog
• MemStore上的樹達到必定大小以後，須要flush到HRegion磁盤中（通常是Hadoop DataNode），這樣MemStore就變成了DataNode上的磁盤文件StoreFile，按期HRegionServer對DataNode的數據作merge操做，完全刪除無效空間，多棵小樹在這個時機合併成大樹，來加強讀性能。

 

關於LSM Tree，對於最簡單的二層LSM Tree而言，內存中的數據和磁盤你中的數據merge操做，以下圖

圖來自lsm論文

lsm tree，理論上，能夠是內存中樹的一部分和磁盤中第一層樹作merge，對於磁盤中的樹直接作update操做有可能會破壞物理block的連續性，可是實際應用中，通常lsm有多層，當磁盤中的小樹合併成一個大樹的時候，能夠從新排好順序，使得block連續，優化讀性能。

hbase在實現中，是把整個內存在必定閾值後，flush到disk中，造成一個file，這個file的存儲也就是一個小的B+樹，由於hbase通常是部署在hdfs上，hdfs不支持對文件的update操做，因此hbase這麼總體內存flush，而不是和磁盤中的小樹merge update，這個設計也就能講通了。內存flush到磁盤上的小樹，按期也會合併成一個大樹。總體上hbase就是用了lsm tree的思路。