Hbase 表设计

 一. 写一个查询人的通话记录

首先要写一个表

•  写表第一步就是定RowKey 但是一定要注意他是字典序
• 你这边查的是某个人的某一时间段的通话记录，那rowkey肯定是电话号+时间戳的结合
• 其次是 你拿到的信息，最近通话肯定在最上面，所以要么给时间戳 取反 要么用一个long.max - 时间戳
• 除此之外，为了实现负载均衡，要么对电话号进行取哈希，使他会散列在不同的regionserver，要么对电话号取反，因为大家的电话号都是1开头的，这就势必会导致很多人的电话号集中在一个regionserver，而手机号最后一位没有规律，就会散列存放

二. 创建表

1. 人员角色 多对多表

 如果是创一张表存储这两个信息

那就是pid_rid作为rowkey

如果是两张表存储这个信息

人员表和角色表 hbase是非关系型数据库，你不用想着两张表之间有什么关联，直接一个列族放自己属性，另一个列族放对应关系就行，如果一张表的东西发生改变，在两张表一起删除即可

如果是三张表

那就是人员表 角色表 人员角色表 但是这样复杂性更高 

由于hbase是非关系型 KV键值对方式存储，能在k找到就直接搞 不用想着什么把两张表联系在一起

两张表的存储就是最佳的

2. 部门子部门 一对多表

 一对多的结构就是一张表就行

rowkey是部门标号，为了查询方便可以设置前缀，比如一级部门前缀是0- 二级是1-

列族就是子部门列表 里面的每一个列名分别是子部门标号

另一个列族是部门的详细信息 除此之外，部门信息里面应该有pid这个父部门信息

为的就是 如果删除某个部门的话， 可以直接找到其父部门在父部门的子部门列表里面也删除

3. 综合 微博表设计

1. 关注表和粉丝表设计

直接每个人都有pid 列族是关注列表和粉丝列表综合 列名是别人的pid即可

2.写微博 微博表

为了后续查看某个用户所有微博方便 rowkey就是 pid_long.max-时间戳 这样就能最近时间呈现 列族是信息 列名是具体内容

3. 查看首页所有关注好友发的微博

rowkey是你的pid  列族是关注人发的微博集合且已经排序 列名就是微博 value就是具体哪一篇微博（wid） 列族可以是不同的微博号 或者都是一样的 但是以version区分排序

逻辑如下：

当一个人发微博时候，先自己生成微博加入微博表，然后从这个人的粉丝表里找粉丝pid，从微博收取表里加入刚刚的微博，每次加入的微博大家用一个列族即可，因为hbase有version，即使大家列族一样，也会按照加入的顺序以version号排列开。

Rowkey设计原则

总结一下： 好像设计表直接就是 rowkey就是具体信息 ，列族是你的一个属性集合类（比如你的孩子们，你的部门信息集合），列名是你下属的信息，可以是一对多的多，或者是自己属性

预分区：

 这边的region预分区，是针对一个regionServer的，就是说我创一个表，这个表可以存在于一个regionServer的多个region分区，也可以存在于多个regionServer的多个region分区。

逻辑上讲 我只有一个表

物理存储上讲 我这个表存在于各种地方

region就是表的概念， 你创建的表 他就会给你划分分区，你后面的rowkey也都存在于这些分区，并不是说 你只利用rowkey去搜寻整个Hbase

列族设计原则

 

 

后面大量内容很重要 看git