LSM-Tree 大數據索引技術

1、LSM-Tree概述

        核心思想就是放棄部分讀能力，換取寫入能力的最大化。LSM-Tree ，這個概念就是結構化合並樹（Log-Structured Merge Tree）的意思，它的核心思路其實很是簡單，就是假定內存足夠大，所以不須要每次有數據更新（插入、刪除）就必須將數據寫入到磁盤中，而能夠先將最新的數據駐留在內存中，等到積累到必定限制大小以後，再使用歸併排序的方式將內存中的數據合併追加到磁盤隊尾(由於全部待合併的樹都是有序的，能夠經過合併排序的方式快速合併到一塊兒)。
        磁盤的技術特性:對磁盤來講，可以最大化的發揮磁盤技術特性的使用方式是:一次性的讀取或寫入固定大小的一塊數據，並儘量的減小隨機尋道這個操做的次數。
        日誌結構的合併樹（LSM-tree）是一種基於硬盤的數據結構，與B+ tree相比，能顯著地減小硬盤磁盤尋道開銷，並能在較長的時間提供對文件的高速插入（刪除）。然而LSM-tree在某些狀況下，特別是在查詢須要快速響應時性能不佳。一般LSM-tree適用於索引插入比檢索更頻繁的應用系統。

2、LSM-Tree VS B+ Tree

B+Tree

        RDBMS通常採用B+樹做爲索引的數據結構。RDBMS中的B+樹通常是3層n路的平衡樹。B+樹的節點對應於磁盤數據塊。所以對於RDBMS，數據更新操做須要5次磁盤操做（從B+樹3次找到記錄所在數據塊，再加上一次讀和一次寫）。在RDBMS中，數據隨機無序寫在磁盤塊中，若是沒有B+樹，讀性能會很低。B+樹對於數據讀操做能很好地提升性能，但對於數據寫，效率不高。對於大型分佈式數據系統，B+樹還沒法與LSM樹相抗衡。

        

        B+樹最大的性能題問是會發生大批的隨機IO，隨着新數據的插入，葉子點節會漸漸裂分，邏輯上連續的葉子點節在物理上每每不連續，甚至分離的很遠，但作圍範查詢時，會發生大批讀隨機IO。
        對於大批的隨機寫也同樣，舉一個插入key跨度很大的例子，如7->1000->3->2000 … 新插入的數據存儲在磁盤上相隔很遠，會發生大批的隨機寫IO。

LSM-Tree

        LSM樹原理把一棵大樹拆分紅N棵小樹，它首先寫入內存中，隨着小樹愈來愈大，內存中的小樹會flush到磁盤中，磁盤中的樹按期能夠作merge操做，合併成一棵大樹，以優化讀性能。No-SQL數據庫通常採用LSM樹做爲數據結構，HBase也不例外。

        

        LSM和Btree差別就要在讀性能和寫性能進行取捨。在犧牲的同時，尋找其餘方案來彌補。
        一、LSM具備批量特性，存儲延遲。當寫讀比例很大的時候（寫比讀多），LSM樹相比於B樹有更好的性能。由於隨着insert操做，爲了維護B樹結構，節點分裂。讀磁盤的隨機讀寫機率會變大，性能會逐漸減弱。 屢次單頁隨機寫，變成一次多頁隨機寫,複用了磁盤尋道時間，極大提高效率。
        二、B樹的寫入過程:對B樹的寫入過程是一次原位寫入的過程，主要分爲兩個部分，首先是查找到對應的塊的位置，而後將新數據寫入到剛纔查找到的數據塊中，而後再查找到塊所對應的磁盤物理位置，將數據寫入去。固然，在內存比較充足的時候，由於B樹的一部分能夠被緩存在內存中，因此查找塊的過程有必定機率能夠在內存內完成，不過爲了表述清晰，咱們就假定內存很小，只夠存一個B樹塊大小的數據吧。能夠看到，在上面的模式中，須要兩次隨機尋道（一次查找，一次原位寫），纔可以完成一次數據的寫入，代價仍是很高的。
        三、LSM Tree放棄磁盤讀性能來換取寫的順序性，彷佛會認爲讀應該是大部分系統最應該保證的特性，因此用讀換寫彷佛不是個好買賣。內存的速度遠超磁盤，1000倍以上。而讀取的性能提高，主要仍是依靠內存命中率而非磁盤讀的次數。
LSM數據更新只在內存中操做，沒有磁盤訪問，所以比B+樹要快。對於數據讀來講，若是讀取的是最近訪問過的數據，LSM樹能減小磁盤訪問，提升性能。 LSM樹實質上就是在讀寫之間得取衡平，和B+樹比相，它牲犧了部份讀性能，用來大幅進步寫性能。

LSM Tree優化方式

        一、Bloom filter: 就是個帶隨即機率的bitmap,能夠快速的告訴你，某一個小的有序結構裏有沒有指定的那個數據的。因而就能夠不用二分查找，而只需簡單的計算幾回就能知道數據是否在某個小集合裏啦。效率獲得了提高，但付出的是空間代價。
        二、compact:小樹合併爲大樹:由於小樹他性能有問題，因此要有個進程不斷地將小樹合併到大樹上，這樣大部分的老數據查詢也能夠直接使用log2N的方式找到，不須要再進行(N/m)*log2n的查詢了

3、Hbase對LSM-Tree的使用方式

        hbase在實現中，是把整個內存在必定閾值後，flush到disk中，造成一個file，這個file的存儲也就是一個小的B+樹，由於hbase通常是部署在hdfs上，hdfs不支持對文件的update操做，因此hbase這麼總體內存flush，而不是和磁盤中的小樹merge update。內存flush到磁盤上的小樹，按期也會合併成一個大樹。總體上hbase就是用了lsm tree的思路。
        由於小樹先寫到內存中，爲了防止內存數據丟失，寫內存的同時須要暫時持久化到磁盤，對應了HBase的HLog(WAL)和MemStore
MemStore上的樹達到必定大小以後，須要flush到HRegion磁盤中（通常是Hadoop DataNode），這樣MemStore就變成了DataNode上的磁盤文件StoreFile，按期HRegionServer對DataNode的數據作merge操做，完全刪除無效空間，多棵小樹在這個時機合併成大樹，來加強讀性能。
        數據寫（插入，更新）：數據首先順序寫如hlog (WAL), 而後寫到MemStore, 在MemStore中，數據是一個2層B+樹(圖2中的C0樹）。MemStore滿了以後，數據會被刷到storefile (hFile)，在storefile中，數據是3層B+樹（圖2中的C1樹），並針對順序磁盤操做進行優化。

        

        數據讀：首先搜索BlockCache,再搜索MemStore,若是不在MemStore中，則到storefile中尋找。
        數據刪除：不會去刪除磁盤上的數據，而是爲數據添加一個刪除標記。在隨後的major compaction中，被刪除的數據和刪除標記纔會真的被刪除。