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上
３.访问.META.表来看你要查询的行键在什么Region范围里面。
４.连接具体的数据所在的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的步骤了。

---