LSM存儲模型

LSM存儲模型

 

數據庫有3種基本的存儲引擎：

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

 

LSM的本質是將隨機寫轉化爲順序寫，具體實現方式以下：

1. 當有寫操做（或update操做）時，寫入位於內存的buffer，內存中經過某種數據結構（如skiplist）保持key有序；
2. 爲了防止進程忽然掛掉致使內存的數據丟失，通常會將數據追加寫到磁盤Log文件後才寫入buffer，以備必要時能從log恢復數據；
3. 內存中的數據定時或按固定大小地刷到磁盤，更新操做只不斷地寫到內存，並不更新磁盤上已有文件；
4. 隨着愈來愈多寫操做，磁盤上積累的文件也愈來愈多，這些文件不可寫且有序；
5. 定時對文件進行合併操做（compaction），消除冗餘數據，減小文件數量；

 

LSM-Tree 的設計思想很是樸素：將對數據的修改增量保持在內存中，達到指定的大小限制後將這些修改操做批量寫入磁盤，不過讀取的時候稍微麻煩，須要合併磁盤中歷史數據和內存中最近修改操做，因此寫入性能大大提高，讀取時可能須要先看是否命中內存，不然須要訪問較多的磁盤文件。所以，LSM-Tree比較適合的應用場景是：insert數據量大，讀數據量和update數據量不高且讀通常針對最新數據。

 

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

數據首先會插入到內存中的樹。當內存中的樹中的數據超過必定閾值時，會進行合併操做。合併操做會從左至右遍歷內存中的樹的葉子節點與磁盤中的樹的葉子節點進行合併，當被合併的數據量達到磁盤的存儲頁的大小時，會將合併後的數據持久化到磁盤，同時更新父親節點對葉子節點的指針。

 

 

以前存在於磁盤的葉子節點被合併後，舊的數據並不會被刪除，這些數據會拷貝一份和內存中的數據一塊兒順序寫到磁盤。這會操做一些空間的浪費，可是，LSM-tree提供了一些機制來回收這些空間。
磁盤中的樹的非葉子節點數據也被緩存在內存中。
數據查找會首先查找內存中樹，若是沒有查到結果，會轉而查找磁盤中的樹。

有一個很顯然的問題是，若是數據量過於龐大，磁盤中的樹相應地也會很大，致使的後果是合併的速度會變慢。一個解決方法是創建各個層次的樹，低層次的樹都比上一層次的樹數據集大。假設內存中的樹爲c0, 磁盤中的樹按照層次一次爲c1, c2, c3, ... ck-1, ck。合併的順序是(c0, c1), (c1, c2)...(ck-1, ck)。

爲何LSM-tree的插入很快：

• 插入操做首先會做用於內存，而且內存中的樹不會很大，這會很快；
• 合併操做會順序寫入一個或多個磁盤頁，這比隨機寫快得多；

 

 

總結：

LSM存儲框架實現的思路較簡單，其先在內存中保存數據，再定時刷到磁盤，實現順序IO操做，經過按期合併文件減小數據冗餘；文件有序，保證讀取操做相對快速。

咱們須要結合實際的業務場景選擇合適的存儲實現，不存在萬金油式的通用存儲框架。LSM適用於寫多、讀相對少（或較多讀取最新寫入的數據，該部分數據存在內存中，不須要磁盤IO操做）的業務場景。

 

 

參考文檔：

http://www.2cto.com/database/201411/350877.html