hbase寻址机制详解

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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-表了。

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

以上是关于hbase寻址机制详解的主要内容,如果未能解决你的问题,请参考以下文章

Hbase的region合并与拆分详解

大数据入门第十四天——Hbase详解hbase基本原理与MR操作Hbase

Hash寻址详解

[go]go addressable 详解

实模式与保护模式详解三:寻址方式

网络寻址过程详解