Hbase中寫為什么比讀快

這篇文章主要介紹“Hbase中寫為什么比讀快”，在日常操作中，相信很多人在Hbase中寫為什么比讀快問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Hbase中寫為什么比讀快”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

首先，需要明確的是，Hbase寫入速度比讀取速度要快，根本原因LSM存儲引擎

從存儲引擎的角度分析

• Hbase底層的存儲引擎為LSM-Tree(Log-Structured Merge-Tree)。

• LSM核心思想的核心就是放棄部分讀能力，換取寫入的最大化能力。LSM Tree ，這個(gè)概念就是結(jié)構(gòu)化合并樹的意思，它的核心思路其實(shí)非常簡單，就是假定內(nèi)存足夠大，因此不需要每次有數(shù)據(jù)更新就必須將數(shù)據(jù)寫入到磁盤中，而可以先將最新的數(shù)據(jù)駐留在內(nèi)存中，等到積累到最后多之后，再使用歸并排序的方式將內(nèi)存內(nèi)的數(shù)據(jù)合并追加到磁盤隊(duì)尾(因?yàn)樗写判虻臉涠际怯行虻?，可以通過合并排序的方式快速合并到一起)。

• LSM樹的設(shè)計(jì)思想非常樸素：將對數(shù)據(jù)的修改增量保持在內(nèi)存中，達(dá)到指定的大小限制后將這些修改操作批量寫入磁盤，不過讀取的時(shí)候稍微麻煩，需要合并磁盤中歷史數(shù)據(jù)和內(nèi)存中最近修改操作，所以寫入性能大大提升，讀取時(shí)可能需要先看是否命中內(nèi)存，否則需要訪問較多的磁盤文件。極端的說，基于LSM樹實(shí)現(xiàn)的HBase的寫性能比MySQL高了一個(gè)數(shù)量級，讀性能低了一個(gè)數(shù)量級。

• LSM樹原理把一棵大樹拆分成N棵小樹，它首先寫入內(nèi)存中，隨著小樹越來越大，內(nèi)存中的小樹會(huì)flush到磁盤中，磁盤中的樹定期可以做merge操作，合并成一棵大樹，以優(yōu)化讀性能。

參考博客：性能測試

Hbase為什么讀取速度快

• HBase能提供實(shí)時(shí)計(jì)算服務(wù)主要原因是由其架構(gòu)和底層的數(shù)據(jù)結(jié)構(gòu)決定的，即由LSM-Tree(Log-Structured Merge-Tree) + HTable(region分區(qū)) + Cache決定——客戶端可以直接定位到要查數(shù)據(jù)所在的HRegion server服務(wù)器，然后直接在服務(wù)器的一個(gè)region上查找要匹配的數(shù)據(jù)，并且這些數(shù)據(jù)部分是經(jīng)過cache緩存的。

• 前面說過HBase會(huì)將數(shù)據(jù)保存到內(nèi)存中，在內(nèi)存中的數(shù)據(jù)是有序的，如果內(nèi)存空間滿了，會(huì)刷寫到HFile中，而在HFile中保存的內(nèi)容也是有序的。當(dāng)數(shù)據(jù)寫入HFile后，內(nèi)存中的數(shù)據(jù)會(huì)被丟棄。

• HFile文件為磁盤順序讀取做了優(yōu)化，按頁存儲。下圖展示了在內(nèi)存中多個(gè)塊存儲并歸并到磁盤的過程，合并寫入會(huì)產(chǎn)生新的結(jié)果塊，最終多個(gè)塊被合并為更大塊。

   

  hbase讀取速度快

• 多次刷寫后會(huì)產(chǎn)生很多小文件，后臺線程會(huì)合并小文件組成大文件，這樣磁盤查找會(huì)限制在少數(shù)幾個(gè)數(shù)據(jù)存儲文件中。HBase的寫入速度快是因?yàn)樗鋵?shí)并不是真的立即寫入文件中，而是先寫入內(nèi)存，隨后異步刷入HFile。所以在客戶端看來，寫入速度很快。另外，寫入時(shí)候?qū)㈦S機(jī)寫入轉(zhuǎn)換成順序?qū)?，?shù)據(jù)寫入速度也很穩(wěn)定。

• 而讀取速度快是因?yàn)樗褂昧薒SM樹型結(jié)構(gòu)，而不是B或B+樹。磁盤的順序讀取速度很快，但是相比而言，尋找磁道的速度就要慢很多。HBase的存儲結(jié)構(gòu)導(dǎo)致它需要磁盤尋道時(shí)間在可預(yù)測范圍內(nèi)，并且讀取與所要查詢的rowkey連續(xù)的任意數(shù)量的記錄都不會(huì)引發(fā)額外的尋道開銷。比如有5個(gè)存儲文件，那么最多需要5次磁盤尋道就可以。而關(guān)系型數(shù)據(jù)庫，即使有索引，也無法確定磁盤尋道次數(shù)。而且，HBase讀取首先會(huì)在緩存（BlockCache）中查找，它采用了LRU（最近最少使用算法），如果緩存中沒找到，會(huì)從內(nèi)存中的MemStore中查找，只有這兩個(gè)地方都找不到時(shí)，才會(huì)加載HFile中的內(nèi)容，而上文也提到了讀取HFile速度也會(huì)很快，因?yàn)楣?jié)省了尋道開銷。

舉例：
A：如果快速查詢（從磁盤讀數(shù)據(jù)），hbase是根據(jù)rowkey查詢的，只要能快速的定位rowkey, 就能實(shí)現(xiàn)快速的查詢，主要是以下因素：
1、hbase是可劃分成多個(gè)region，你可以簡單的理解為關(guān)系型數(shù)據(jù)庫的多個(gè)分區(qū)。
2、鍵是排好序了的
3、按列存儲的

• 首先，能快速找到行所在的region(分區(qū))，假設(shè)表有10億條記錄，占空間1TB, 分列成了500個(gè)region, 1個(gè)region占2個(gè)G. 最多讀取2G的記錄，就能找到對應(yīng)記錄；

• 其次，是按列存儲的，其實(shí)是列族，假設(shè)分為3個(gè)列族，每個(gè)列族就是666M， 如果要查詢的東西在其中1個(gè)列族上，1個(gè)列族包含1個(gè)或者多個(gè)HStoreFile，假設(shè)一個(gè)HStoreFile是128M， 該列族包含5個(gè)HStoreFile在磁盤上. 剩下的在內(nèi)存中。

• 再次，是排好序了的，你要的記錄有可能在最前面，也有可能在最后面，假設(shè)在中間，我們只需遍歷2.5個(gè)HStoreFile共300M

• 最后，每個(gè)HStoreFile(HFile的封裝)，是以鍵值對（key-value）方式存儲，只要遍歷一個(gè)個(gè)數(shù)據(jù)塊中的key的位置，并判斷符合條件可以了。 一般key是有限的長度，假設(shè)跟value是1:19（忽略HFile上其它塊），最終只需要15M就可獲取的對應(yīng)的記錄，按照磁盤的訪問100M/S，只需0.15秒。 加上塊緩存機(jī)制（LRU原則），會(huì)取得更高的效率。

B：實(shí)時(shí)查詢

• 實(shí)時(shí)查詢，可以認(rèn)為是從內(nèi)存中查詢，一般響應(yīng)時(shí)間在1秒內(nèi)。HBase的機(jī)制是數(shù)據(jù)先寫入到內(nèi)存中，當(dāng)數(shù)據(jù)量達(dá)到一定的量（如128M），再寫入磁盤中， 在內(nèi)存中，是不進(jìn)行數(shù)據(jù)的更新或合并操作的，只增加數(shù)據(jù)，這使得用戶的寫操作只要進(jìn)入內(nèi)存中就可以立即返回，保證了HBase I/O的高性能。

• 實(shí)時(shí)查詢，即反應(yīng)根據(jù)當(dāng)前時(shí)間的數(shù)據(jù)，可以認(rèn)為這些數(shù)據(jù)始終是在內(nèi)存的，保證了數(shù)據(jù)的實(shí)時(shí)響應(yīng)

到此，關(guān)于“Hbase中寫為什么比讀快”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！