hbase寻址机制详解

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-表了。

提示：更具版本的不同，分为老的寻址地址方式，和新的寻址方式 ，详细的见此链接介绍，
我记录的是新的寻址过程记录。