2019/2/20 星期三
hbase尋址機制詳解
//參考鏈接爲 ： https://www.cnblogs.com/qingyunzong/p/8692430.html
系統如何找到某個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-表了。
提示：更具版本的不同，分爲老的尋址地址方式，和新的尋址方式 ，詳細的見此鏈接介紹，
我記錄的是新的尋址過程記錄。