国产又大又黄,欧美日韩伊人,日韩欧美亚州小说图文视频,日韩日皮视频,xxxxx在线,翔田千里无码在线观看,美女被干视频网站,www.视频一区

點擊上方藍色字體，選擇“設為星標”

回復”資源“獲取更多驚喜

我們先拋出一個問題：

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

首先，我們從B+樹講起

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

B+樹的磁盤讀寫代價更低：B+樹的內(nèi)部節(jié)點并沒有指向關鍵字具體信息的指針，因此其內(nèi)部節(jié)點相對B樹更小，如果把所有同一內(nèi)部節(jié)點的關鍵字存放在同一盤塊中，那么盤塊所能容納的關鍵字數(shù)量也越多，一次性讀入內(nèi)存的需要查找的關鍵字也就越多，相對IO讀寫次數(shù)就降低了。
B+樹的查詢效率更加穩(wěn)定：由于非終結點并不是最終指向文件內(nèi)容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數(shù)據(jù)的查詢效率相當。
由于B+樹的數(shù)據(jù)都存儲在葉子結點中，分支結點均為索引，方便掃庫，只需要掃一遍葉子結點即可，但是B樹因為其分支結點同樣存儲著數(shù)據(jù)，我們要找到具體的數(shù)據(jù)，需要進行一次中序遍歷按序來掃，所以B+樹更加適合在區(qū)間查詢的情況，所以通常B+樹用于數(shù)據(jù)庫索引。

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

那么，B+樹有什么缺點呢？

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

LSM Tree

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

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

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

我們來看看大佬設計這個數(shù)據(jù)結構：

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

回到Hbase來，我們在之前的文章中《Hbase性能優(yōu)化百科全書》中提到過Hbase的讀寫流程：

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

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