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 位置信息。
//见图

hbase寻址机制的示例分析  hbase 第1张

说明:
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寻址机制的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注蜗牛博客行业资讯频道!

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:niceseo99@gmail.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

评论

有免费节点资源,我们会通知你!加入纸飞机订阅群

×
天气预报查看日历分享网页手机扫码留言评论电报频道链接