新聞中心
這篇文章主要講解了“Hbase的LSM Tree有什么用”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“Hbase的LSM Tree有什么用”吧!
專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)佛坪免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動了成百上千企業(yè)的穩(wěn)健成長,幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
LSM樹是HBase里使用的非常有創(chuàng)意的一種數(shù)據(jù)結(jié)構(gòu)。在有代表性的關(guān)系型數(shù)據(jù)庫如MySQL、SQL Server、Oracle中,數(shù)據(jù)存儲與索引的基本結(jié)構(gòu)就是我們耳熟能詳?shù)腂樹和B+樹。而在一些主流的NoSql數(shù)據(jù)庫如HBase、Cassandra、LevelDB、RocksDB中,則是使用日志結(jié)構(gòu)合并樹(Log-structured Merge Tree,LSM Tree)來組織數(shù)據(jù)。
首先,我們從B+樹講起
為什么在RDBMS中我們需要B+樹(或者廣義地說,索引)?一句話:減少尋道時間。在存儲系統(tǒng)中廣泛使用的HDD是磁性介質(zhì)+機(jī)械旋轉(zhuǎn)的,這就使得其順序訪問較快而隨機(jī)訪問較慢。使用B+樹組織數(shù)據(jù)可以較好地利用HDD的這種特點,其本質(zhì)是多路平衡查找樹。一個典型的B+樹如下圖所示:
B+樹的磁盤讀寫代價更低:B+樹的內(nèi)部節(jié)點并沒有指向關(guān)鍵字具體信息的指針,因此其內(nèi)部節(jié)點相對B樹更小,如果把所有同一內(nèi)部節(jié)點的關(guān)鍵字存放在同一盤塊中,那么盤塊所能容納的關(guān)鍵字?jǐn)?shù)量也越多,一次性讀入內(nèi)存的需要查找的關(guān)鍵字也就越多,相對IO讀寫次數(shù)就降低了。
B+樹的查詢效率更加穩(wěn)定:由于非終結(jié)點并不是最終指向文件內(nèi)容的結(jié)點,而只是葉子結(jié)點中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點到葉子結(jié)點的路。所有關(guān)鍵字查詢的路徑長度相同,導(dǎo)致每一個數(shù)據(jù)的查詢效率相當(dāng)。
由于B+樹的數(shù)據(jù)都存儲在葉子結(jié)點中,分支結(jié)點均為索引,方便掃庫,只需要掃一遍葉子結(jié)點即可,但是B樹因為其分支結(jié)點同樣存儲著數(shù)據(jù),我們要找到具體的數(shù)據(jù),需要進(jìn)行一次中序遍歷按序來掃,所以B+樹更加適合在區(qū)間查詢的情況,所以通常B+樹用于數(shù)據(jù)庫索引。
如果你對B+樹不夠熟悉,可以參考這里:https://blog.csdn.net/b_x_p/article/details/86434387
那么,B+樹有什么缺點呢?
B+樹最大的性能問題是會產(chǎn)生大量的隨機(jī)IO,隨著新數(shù)據(jù)的插入,葉子節(jié)點會慢慢分裂,邏輯上連續(xù)的葉子節(jié)點在物理上往往不連續(xù),甚至分離的很遠(yuǎn),但做范圍查詢時,會產(chǎn)生大量讀隨機(jī)IO。
LSM Tree
為了克服B+樹的弱點,HBase引入了LSM樹的概念,即Log-Structured Merge-Trees。
LSM Tree(Log-structured merge-tree)起源于1996年的一篇論文:The log-structured merge-tree (LSM-tree)。當(dāng)時的背景是:為一張數(shù)據(jù)增長很快的歷史數(shù)據(jù)表設(shè)計一種存儲結(jié)構(gòu),使得它能夠解決:在內(nèi)存不足,磁盤隨機(jī)IO太慢下的嚴(yán)重寫入性能問題。
LSM Tree(Log-structured merge-tree)廣泛應(yīng)用在HBase,TiDB等諸多數(shù)據(jù)庫和存儲引擎上:
我們來看看大佬設(shè)計這個數(shù)據(jù)結(jié)構(gòu):
Ck tree是一個有序的樹狀結(jié)構(gòu),數(shù)據(jù)的寫入流轉(zhuǎn)從C0 tree 內(nèi)存開始,不斷被合并到磁盤上的更大容量的Ck tree上。由于內(nèi)存的讀寫速率都比外存要快非常多,因此數(shù)據(jù)寫入的效率很高。并且數(shù)據(jù)從內(nèi)存刷入磁盤時是預(yù)排序的,也就是說,LSM樹將原本的隨機(jī)寫操作轉(zhuǎn)化成了順序?qū)懖僮鳎瑢懶阅艽蠓嵘2贿^它犧牲了一部分讀性能,因為讀取時需要將內(nèi)存中的數(shù)據(jù)和磁盤中的數(shù)據(jù)合并。
回到Hbase來,我們在之前的文章中《Hbase性能優(yōu)化手冊》中提到過Hbase的讀寫流程:
MemStore是HBase中C0的實現(xiàn),向HBase中寫數(shù)據(jù)的時候,首先會寫到內(nèi)存中的MemStore,當(dāng)達(dá)到一定閥值之后,flush(順序?qū)?到磁盤,形成新的StoreFile(HFile),最后多個StoreFile(HFile)又會進(jìn)行Compact。
memstore內(nèi)部維護(hù)了一個數(shù)據(jù)結(jié)構(gòu):ConcurrentSkipListMap,數(shù)據(jù)存儲是按照RowKey排好序的跳躍列表。跳躍列表的算法有同平衡樹一樣的漸進(jìn)的預(yù)期時間邊界,并且更簡單、更快速和使用更少的空間。
HBase為了提升LSM結(jié)構(gòu)下的隨機(jī)讀性能,還引入了布隆過濾器(建表語句中可以指定),對應(yīng)HFile中的Bloom index block,其結(jié)構(gòu)圖如下所示。
通過布隆過濾器,HBase就能以少量的空間代價,換來在讀取數(shù)據(jù)時非常快速地確定是否存在某條數(shù)據(jù),效率進(jìn)一步提升。
感謝各位的閱讀,以上就是“Hbase的LSM Tree有什么用”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對Hbase的LSM Tree有什么用這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關(guān)知識點的文章,歡迎關(guān)注!
當(dāng)前文章:Hbase的LSMTree有什么用
標(biāo)題URL:http://ef60e0e.cn/article/gsjjog.html