LSM樹由來、設計思想以及應用到HBase的索引

dukewyh發表於2015-01-23

講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操作,合併成一棵大樹,以最佳化讀效能。


LSM樹由來、設計思想以及應用到HBase的索引

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

  • 因為小樹先寫到記憶體中,為了防止記憶體資料丟失,寫記憶體的同時需要暫時持久化到磁碟,對應了HBase的MemStore和HLog
  • MemStore上的樹達到一定大小之後,需要flush到HRegion磁碟中(一般是Hadoop DataNode),這樣MemStore就變成了DataNode上的磁碟檔案StoreFile,定期HRegionServer對DataNode的資料做merge操作,徹底刪除無效空間,多棵小樹在這個時機合併成大樹,來增強讀效能。

 

關於LSM Tree,對於最簡單的二層LSM Tree而言,記憶體中的資料和磁碟你中的資料merge操作,如下圖

圖來自

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的思路。


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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/15592508/viewspace-1411795/,如需轉載,請註明出處,否則將追究法律責任。

相關文章