1.版本0.96.0之前Region的查找
1.1 基本架构
早期Region的设计被称为三层查询架构。即
image.png
<1> Region：就是你需要查找的数据所在的Region。
<2> .META.：是一张元数据表，它存储了所有Region的简要信息。.META.表中的一行记录就是一个Region，该行记录了该Region的起始行、结束行和该Region的连接信息，那客户端就能通过这个判断查找的数据在哪个Region上。
<3> -ROOT-：是一张存储.META.表的表，.META.表可以有很多张，而-ROOT-就是存储了.META.表在什么RegionServer上的信息（.MEAT.是很普通的关系表，存储在某个RegionServer上）
1.2 具体流程
用户是如何读取-ROOT-表？
查询Zookeeper来获取-ROOT-表所在的RegionServer（对应zk的路径就是/hbase/root-region-server）。
流程：
<1> 用户通过zk的/hbase/root-region-server节点知道-ROOT-表在什么RegionServer上
<2> 访问-ROOT-表，看需要的数据在哪个.META.上，该.META.表在哪个RegionServer上
<3> 访问.META.表来看你要查询的行键在什么Region范围内
<4> 连接具体的数据所在的RegionServer，用Scan来遍历
image.png
当然，客户端在获取到Region信息后，会把.META.表的部分信息保存到客户端的缓存里面。当下次查询不到数据的时候才会再次获取Region信息，否则直接用缓存的信息。
1.3 该方案存在的弊端
image.png
2.版本0.96.0之后Region的查找
2.1 架构调整
由原来的三层架构转成二层查询架构，-ROOT-表被去掉了，同时zk中/hbase/root-region-server被去掉了。而是直接将.META.表所在的RegionServer信息存储到zk中的/hbase/meta-region-server，在之后引入namespace，.MEAT.被修改成hbase:meta。
2.2 具体流程
<1> 客户端通过zk的/hbase/meta-region-server节点查询到哪台regionServer上有hbase:meta表
<2> 客户端连接含有hbase:meta表的RegionServer，hbase:meta表存储了所有Region的行键范围信息，通过这个表就可以查询你要存取的rowkey属于哪个Region的范围里面，以及这个Regino属于哪一个RegionServer
<3> 获取这些信息后，客户端就可以直连其中一台拥有你要存取的rowkey的RegionServer，并直接对其操作。
<4> 客户端会把meta信息缓存起来，下次操作不需要进行以上加载hbase:meta的步骤了。
image.png
3.hbase:meta的表结构
image.png
image.png
发现比上述表格中还多1列为info:seqnumDuringOpen
Key：
Region key of the format ([table表名],[region start key起始键],[region id])
Values：
序列化的regioninfo实例
info:regioninfo (serialized HRegionInfo instance for this region)
包含此region的regionserver
info:server (server:port of the RegionServer containing this region)
包含此region的regionserver的进程开始时间
info:serverstartcode (start-time of the RegionServer process containing this region)
网友评论