hbase尋址機制的示例分析

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

hbase尋址機制詳解

系統如何找到某個row key(或者某個row key range（范圍）)所在的region big table 使用三層類似B+樹的結構來保存region 位置
第一層是保存zookeeper 里面的文件，它持有root region 的位置。
第二層root region 是.META.表的第一個region 其中 保存了.META.z表 其它region 的位置。通過root region，我們就可以訪問.META.表的數據。
.META.是第三層，它是一個特殊的表，保存了hbase 中所有數據表的region 位置信息。
//見圖

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

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

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

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