hbase尋址機(jī)制的示例分析

小編給大家分享一下hbase尋址機(jī)制的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

hbase尋址機(jī)制詳解

系統(tǒng)如何找到某個(gè)row key(或者某個(gè)row key range（范圍）)所在的region big table 使用三層類(lèi)似B+樹(shù)的結(jié)構(gòu)來(lái)保存region 位置
第一層是保存zookeeper 里面的文件，它持有root region 的位置。
第二層root region 是.META.表的第一個(gè)region 其中 保存了.META.z表 其它region 的位置。通過(guò)root region，我們就可以訪(fǎng)問(wèn).META.表的數(shù)據(jù)。
.META.是第三層，它是一個(gè)特殊的表，保存了hbase 中所有數(shù)據(jù)表的region 位置信息。
//見(jiàn)圖

說(shuō)明：
1 root region 永遠(yuǎn)不會(huì)被split，保證了最需要三次跳轉(zhuǎn)，就能定位到任意region 。
2.META.表每行保存一個(gè)region 的位置信息，row key 采用表名+表的最后一樣編碼而成。
3 為了加快訪(fǎng)問(wèn)，.META.表的全部region 都保存在內(nèi)存中。
假設(shè)，.META.表的一行在內(nèi)存中大約占用1KB。并且每個(gè)region 限制為128MB。
那么上面的三層結(jié)構(gòu)可以保存的region 數(shù)目為：
(128MB/1KB) * (128MB/1KB) = = 2(34)個(gè)region
4 client 會(huì)將查詢(xún)過(guò)的位置信息保存緩存起來(lái)，緩存不會(huì)主動(dòng)失效，因此如果client 上的緩存全部失效，則需要進(jìn)行6 次網(wǎng)絡(luò)來(lái)回，才能定位到正確的region(其中三次用來(lái)發(fā)現(xiàn)緩存失效，另外三次用來(lái)獲取位置信息)。

從上面的路徑我們可以看出，用戶(hù)需要 3 次請(qǐng)求才能直到用戶(hù) Table 真正的位置，這在一定 程序帶來(lái)了性能的下降。在 0.96 之前使用 3 層設(shè)計(jì)的主要原因是考慮到元數(shù)據(jù)可能需要很 大。但是真正集群運(yùn)行，元數(shù)據(jù)的大小其實(shí)很容易計(jì)算出來(lái)。在 BigTable 的論文中，每行 METADATA 數(shù)據(jù)存儲(chǔ)大小為 1KB 左右，如果按照一個(gè) Region 為 128M 的計(jì)算，3 層設(shè)計(jì)可以支持的 Region 個(gè)數(shù)為 2^34 個(gè)，采用 2 層設(shè)計(jì)可以支持 2^17（131072）。那么 2 層設(shè)計(jì)的情 況下一個(gè)集群可以存儲(chǔ) 4P 的數(shù)據(jù)。這僅僅是一個(gè) Region 只有 128M 的情況下。如果是 10G 呢? 因此，通過(guò)計(jì)算，其實(shí) 2 層設(shè)計(jì)就可以滿(mǎn)足集群的需求。因此在 0.96 版本以后就去掉 了-ROOT-表了。

提示：更具版本的不同，分為老的尋址地址方式，和新的尋址方式

以上是“hbase尋址機(jī)制的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！