hbaserowkey设计,以三个事例讲解

hbaserowkey设计,以三个事例讲解
提到hbase⼀般⽆法避开rowkey的设计。

Rowkey设计的优劣直接影响读写性能。

下⾯⼩咔以三个实例来讲解
⼀。

事例⼀权限控制⼈员⾓⾊表
权限分配时，普遍关系型数据库，⼀般会设计三张表，⼀张⽤户表记录⽤户信息；⼀张⾓⾊表记录⾓⾊信息；还有张⽤户⾓⾊表，建⽴⽤户与⾓⾊的对应关系。

那么hbase如何设计表结构
要实现以下功能：
⼈员有多个⾓⾊⾓⾊优先级
⾓⾊有多个⼈员
⼈员删除添加⾓⾊
⾓⾊可以添加删除⼈员
⼈员⾓⾊删除添加
数据举例：
⼩明拥有劳动委员>体育委员
⼩红拥有学习委员>劳动委员>体育委员
解决思路：
设计2张表，⼀个记录个⼈信息，⼀个记录⾓⾊信息，他们之前的关系通过列族2进⾏记录
psn cf1(个⼈信息) cf2(拥有的⾓⾊)
rowkey(pid) cf1:name=…;cf2:age=… cf2:100/200/300=…
001 cf1:name=⼩明;cf2:age=… cf2:200=10；cf2: 100=9
002 cf1:name=⼩红;cf2:age=… cf2:300=10；cf2: 200=9；cf2: 100=8
role cf1(⾓⾊信息) cf2(拥有的⼈员)
rowkey(rid) cf1:name=… cf2:001/002/003=…
100 cf1:name=体育委员 cf2:001=⼩明；cf:002=⼩红
200 cf1:name=劳动委员 cf2:001=⼩明；cf:002=⼩红
300 cf1:name=学习委员 cf:002=⼩红
⼆。

事例⼆组织架构设计
公司都有组织架构
如上图ceo下⾯有开发部，测试部，财务部三个部门；开发部下⼜有3个部门。

hbase设计表，实现以下需求
查询顶级部门
查询每个部门的所有⼦部门
部门添加，删除⼦部门
部门添加删除
数据举例：
上图
解决思路:
⼀张表，⼀个列族记录部门信息，⼀个列族记录⼦部门信息
Dep
rowkey cf1(部门信息) cf2(⼦部门)
did cf1:name=…; cf2:002=..;cf2:003=…
001 cf1:name=CEO;cf1:up=0 cf2:002=开发部;cf2:003=测试;cf2:004=财务部002 cf1:name=开发部;cf1:up=1 cf2:005=开发1;cf2:006=开发2;cf2:007=⼤数据部005 cf1:name=开发1;cf1:up=1
006 cf1:name=开发2;cf1:up=1
007 cf1:name=⼤数据部;cf1:up=1
003 cf1:name=测试部;cf1:up=1 cf2:008=测试1
008 cf1:name=测试1 ;cf1:up=1
004 cf1:name=财务部;cf1:up=1
三。

事例三微博关注设计
微博⼤家都使⽤过，⼤多数⼈都关注的⾃⼰⼼中的他、她。

如下需求：
添加、查看关注
粉丝列表
写微博
查看⾸页，所有关注过的好友发布的最新微博
查看某个⽤户发布的所有微博
数据举例：
⼩明001 关注⼩红，⼩绿
⼩红002
⼩⿊003 关系⼩红
⼩绿 004
解决思路：
粉丝表，记录关注⼈与粉丝⼈。

列族1记录关注列表，列族2记录粉丝列表
微博表，记录所发的微博
微博收取表，按时间顺序记录发帖微博，⽤于查看最新微博
粉丝表
rowkey cf1(关注列表) cf2(粉丝列表)
pid cf1:001=… cf2:001=…
001 cf1:002=⼩红；cf1:004=⼩绿
002 cf2:001=⼩明;cf2:003=⼩⿊
003 cf1:002=⼩红
004
微博表
rowkey cf1
wid(pid_max-timestamp)
002_123456 cf1:name=⼤数据
002_745634 cf1:name=⼤数据
微博收取表
rowkey cf1
pid wid
002 002_745634
001 002_123456
hbase设计的表有个缺点，⼤量的数据冗余。

优点是单表查询数据快。

rowkey设计合理查询速度就快，设计不合理还不如关系型数据库。