hbase寻址机制的示例分析

小编给大家分享一下hbase寻址机制的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！

创新互联公司，为您提供网站建设公司、成都网站制作、网站营销推广、网站开发设计，对服务成都混凝土搅拌站等多个行业拥有丰富的网站建设及推广经验。创新互联公司网站建设公司成立于2013年,提供专业网站制作报价服务,我们深知市场的竞争激烈，认真对待每位客户，为客户提供赏心悦目的作品。 与客户共同发展进步，是我们永远的责任！

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