我們先拋出一個(gè)問(wèn)題：

LSM樹是HBase里使用的非常有創(chuàng)意的一種數(shù)據(jù)結(jié)構(gòu)。在有代表性的關(guān)系型數(shù)據(jù)庫(kù)如MySQL、SQL Server、Oracle中，數(shù)據(jù)存儲(chǔ)與索引的基本結(jié)構(gòu)就是我們耳熟能詳?shù)腂樹和B+樹。而在一些主流的NoSQL數(shù)據(jù)庫(kù)如HBase、Cassandra、LevelDB、RocksDB中，則是使用日志結(jié)構(gòu)合并樹（Log-structured Merge Tree，LSM Tree）來(lái)組織數(shù)據(jù)。

首先，我們從B+樹講起

為什么在RDBMS中我們需要B+樹（或者廣義地說(shuō)，索引）？一句話：減少尋道時(shí)間。在存儲(chǔ)系統(tǒng)中廣泛使用的HDD是磁性介質(zhì)+機(jī)械旋轉(zhuǎn)的，這就使得其順序訪問(wèn)較快而隨機(jī)訪問(wèn)較慢。使用B+樹組織數(shù)據(jù)可以較好地利用HDD的這種特點(diǎn)，其本質(zhì)是多路平衡查找樹。一個(gè)典型的B+樹如下圖所示：

• B+樹的磁盤讀寫代價(jià)更低：B+樹的內(nèi)部節(jié)點(diǎn)并沒(méi)有指向關(guān)鍵字具體信息的指針，因此其內(nèi)部節(jié)點(diǎn)相對(duì)B樹更小，如果把所有同一內(nèi)部節(jié)點(diǎn)的關(guān)鍵字存放在同一盤塊中，那么盤塊所能容納的關(guān)鍵字?jǐn)?shù)量也越多，一次性讀入內(nèi)存的需要查找的關(guān)鍵字也就越多，相對(duì)IO讀寫次數(shù)就降低了。

• B+樹的查詢效率更加穩(wěn)定：由于非終結(jié)點(diǎn)并不是最終指向文件內(nèi)容的結(jié)點(diǎn)，而只是葉子結(jié)點(diǎn)中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點(diǎn)到葉子結(jié)點(diǎn)的路。所有關(guān)鍵字查詢的路徑長(zhǎng)度相同，導(dǎo)致每一個(gè)數(shù)據(jù)的查詢效率相當(dāng)。

• 由于B+樹的數(shù)據(jù)都存儲(chǔ)在葉子結(jié)點(diǎn)中，分支結(jié)點(diǎn)均為索引，方便掃庫(kù)，只需要掃一遍葉子結(jié)點(diǎn)即可，但是B樹因?yàn)槠浞种ЫY(jié)點(diǎn)同樣存儲(chǔ)著數(shù)據(jù)，我們要找到具體的數(shù)據(jù)，需要進(jìn)行一次中序遍歷按序來(lái)掃，所以B+樹更加適合在區(qū)間查詢的情況，所以通常B+樹用于數(shù)據(jù)庫(kù)索引。

如果你對(duì)B+樹不夠熟悉，可以參考這里：https://blog.csdn.net/b_x_p/article/details/86434387

那么，B+樹有什么缺點(diǎn)呢？

B+樹最大的性能問(wèn)題是會(huì)產(chǎn)生大量的隨機(jī)IO，隨著新數(shù)據(jù)的插入，葉子節(jié)點(diǎn)會(huì)慢慢分裂，邏輯上連續(xù)的葉子節(jié)點(diǎn)在物理上往往不連續(xù)，甚至分離的很遠(yuǎn)，但做范圍查詢時(shí)，會(huì)產(chǎn)生大量讀隨機(jī)IO。

LSM Tree

為了克服B+樹的弱點(diǎn)，HBase引入了LSM樹的概念，即Log-Structured Merge-Trees。

LSM Tree（Log-structured merge-tree）起源于1996年的一篇論文：The log-structured merge-tree (LSM-tree)。當(dāng)時(shí)的背景是：為一張數(shù)據(jù)增長(zhǎng)很快的歷史數(shù)據(jù)表設(shè)計(jì)一種存儲(chǔ)結(jié)構(gòu)，使得它能夠解決：在內(nèi)存不足，磁盤隨機(jī)IO太慢下的嚴(yán)重寫入性能問(wèn)題。

LSM Tree（Log-structured merge-tree）廣泛應(yīng)用在HBase，TiDB等諸多數(shù)據(jù)庫(kù)和存儲(chǔ)引擎上：

我們來(lái)看看大佬設(shè)計(jì)這個(gè)數(shù)據(jù)結(jié)構(gòu)：

Ck tree是一個(gè)有序的樹狀結(jié)構(gòu)，數(shù)據(jù)的寫入流轉(zhuǎn)從C0 tree 內(nèi)存開始，不斷被合并到磁盤上的更大容量的Ck tree上。由于內(nèi)存的讀寫速率都比外存要快非常多，因此數(shù)據(jù)寫入的效率很高。并且數(shù)據(jù)從內(nèi)存刷入磁盤時(shí)是預(yù)排序的，也就是說(shuō)，LSM樹將原本的隨機(jī)寫操作轉(zhuǎn)化成了順序?qū)懖僮?，寫性能大幅提升。不過(guò)它犧牲了一部分讀性能，因?yàn)樽x取時(shí)需要將內(nèi)存中的數(shù)據(jù)和磁盤中的數(shù)據(jù)合并。

回到Hbase來(lái)，我們?cè)谥暗奈恼轮小禜base性能優(yōu)化手冊(cè)》中提到過(guò)Hbase的讀寫流程：

MemStore是HBase中C0的實(shí)現(xiàn)，向HBase中寫數(shù)據(jù)的時(shí)候，首先會(huì)寫到內(nèi)存中的MemStore,當(dāng)達(dá)到一定閥值之后，flush(順序?qū)?到磁盤，形成新的StoreFile（HFile），最后多個(gè)StoreFile（HFile）又會(huì)進(jìn)行Compact。

memstore內(nèi)部維護(hù)了一個(gè)數(shù)據(jù)結(jié)構(gòu)：ConcurrentSkipListMap，數(shù)據(jù)存儲(chǔ)是按照RowKey排好序的跳躍列表。跳躍列表的算法有同平衡樹一樣的漸進(jìn)的預(yù)期時(shí)間邊界，并且更簡(jiǎn)單、更快速和使用更少的空間。

HBase為了提升LSM結(jié)構(gòu)下的隨機(jī)讀性能，還引入了布隆過(guò)濾器（建表語(yǔ)句中可以指定），對(duì)應(yīng)HFile中的Bloom index block，其結(jié)構(gòu)圖如下所示。

通過(guò)布隆過(guò)濾器，HBase就能以少量的空間代價(jià)，換來(lái)在讀取數(shù)據(jù)時(shí)非常快速地確定是否存在某條數(shù)據(jù)，效率進(jìn)一步提升。