一.hbase架构设计之元数据管理之root表和meta表说明
- 0.98版本之前
- 各个表的作用
- root表记录meta表的region信息
- meta表记录用户表的region信息
- 工作流程
-
示意图
-
zk中存储着root的region信息(root表仅一份)
-
root中存储着meta的region信息
-
meta中存储着用户的region信息
-
用户访问数据的流程
- 从zk获取root的region,然后获取meta的region,最后获取到用户的region
-
- 各个表的作用
- 0.98版本之后
- 由于之前链接的太长,效率低下,所以0.98之后就将root表去掉了
- meta.表有且仅有一个region来存储,其不可再split分割成更多的region块。
- 通过调大.meta.表的region文件大小,即可解决海量数据的region元数据管理问题。
二.hbase之rowkey设计技巧
- rowkey设计的必要性之热点问题
- 热点发生在大量的client直接访问集群的一个或极少数个节点(访问可能是读,写或者其他操作)。
- 大量访问会使热点region所在的单个机器超出自身承受能力,引起性能下降甚至region不可用,这也会影响同一个RegionServer上的其他region,可能导致主机无法服务其他region的请求。
- 多数是由于rowkey设计不合理导致的。
- rowkey设计的原则
- 精短
- 一般设计成定长(10-100byte)
- 太长会影响Hfile的存储效率
- MemStore会缓存部分数据库到内存,太长会降低内存的使用效率,系统也就不能缓存更多的数据,从而也降低了检索的效率
- 散列
- rowkey是hbase的数据排序,划分region的主要依据,如果设计过于稠密,会导致单个RegionServer负载太高
- 造成热点问题,降低查询效率
- 实现方法
- 不要将时间戳放在key的前面
- 可以将时间戳倒序,但是key会失去可读性
- 高位随机生成,地位放时间戳,可实现散列存储
- 唯一
- rowkey是一行数据的唯一标识
- 在设计rowkey的时候,要充分利用这个排序的特点,将经常读取的数据存储到一块,即将最近可能会被访问的数据放到一块, 这样更方便利用数据块集中加载、数据缓存加速等提升查询效率。
- 精短