HBase查询机制--Region定位

时间:2019-03-12
本文章向大家介绍HBase查询机制--Region定位,主要包括HBase查询机制--Region定位使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

旧版本:

region是HBase架构的关键,大部分的工作都围绕着region展开。在0.96.0版本之前,region的查询通过三层架构来定位:

Region:就是所需要查询的数据具体所在的Region
.META. :元数据表,存储了所有region的简要信息。.META.表中的一行记录就是一个Region,该行记录了该Region的起始行,结束行,和该Region的连接信息,这样客户端就可以通过这个来判断需要的数据在哪个region上。
-ROOT- : 存储.META.表的表,存储了.META.表在什么region上的信息(.META.表也是一张普通的表,也在Region上),通过两层的扩展最多可以支持 2*34 个Region。(171 7986 9184 个)。


旧的寻址方式

1.用户通过查找zookeeper的/hbase/root-region-server节点来得知-root-表在哪个RegionServer上
2.访问-ROOT-表,查看所需要的数据在哪个.META.表上,这个.META.在哪个RegionService上
3.访问.META.表来看你要查询的行键在什么Region范围里面。
4.连接具体的数据所在的Region,用Scan来遍历row


旧版本的弊端:

通过三层架构虽然极大地扩展了可以容纳的Region数量,一直扩展到了171亿个Region,可是我们真的可以用到这么多吗?实际上不太可能。
虽然设计上是允许多个.META.表存在的,但是实际上在HBase的发展历史中,.META.表一直只有一个,所以-ROOT-中的记录一直都只有一行,-ROOT-表形同虚设。三层架构增加了代码的复杂度,容易产生BUG。

代码复杂度可不是小事,复杂度每增加一点产生BUG的概率都在上升,修改BUG的难度也在上升。可以说,增加代码的复杂度的效果等同于维护难度在以2次方的速度成倍增加。其实导致这个架构被改变的导火线也是某次关于三层查询的BUG。

新版本:

从0.96版本之后这个三层查询架构被改成了二层查询架构。-ROOT-表被去掉了,同时zk中的/hbase/root-region-server也被去掉了。这回直接把.META.表所在的RegionServer信息存储到了zk中的/hbase/meta-region-server去了。再后来引入了namespace,.META.表这样别扭的名字被修改成了hbase:meta。

(1)客户端先通过ZooKeeper的/hbase/meta-region-server节点查询到哪台RegionServer上有hbase:meta表。
(2)客户端连接含有hbase:meta表的RegionServer。hbase:meta表存储了所有Region的行键范围信息,通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面,以及这个Region又是属于哪个RegionServer。
(3)获取这些信息后,客户端就可以直连其中一台拥有你要存取的rowkey的RegionServer,并直接对其操作。
客户端会把meta信息缓存起来,下次操作就不需要进行以上加载hbase:meta的步骤了。