HBase表设计实践(类twitter系统)
HBase表设计实践(类twitter系统)
莫问viva 发表于1年前
HBase表设计实践(类twitter系统)
  • 发表于 1年前
  • 阅读 66
  • 收藏 6
  • 点赞 1
  • 评论 0

这边文章先将可能的需求分析一下,设计出HBase表,下一步再开始编写客户端代码。

 

TwiBase系统

 

1、背景

为了加深HBase基本概念的学习,参考HBase实战这本书实际动手做了这个例子。

 

2、需求

这是一个用户推特系统,用户登陆到系统,需要维护用户的基本信息,然后用户可以发帖和其他用户进行互动。用户之间可以相互关注,用户可以浏览关注用户的推文等等。

这是一个比较简单的推特系统,不考虑用户之间的私信,用户评论推特等功能。

 

3、概要设计

3.1表设计

首先需要设计三个表:用户表,推特表以及用户之间的关系表。

(1)用户表

用户表至少包含唯一的用户名,用户昵称,用户邮箱以及用户发帖数量,用一个列族存储。

创建用户表的语句是:

create'users', 'info'

 

其中用户名用作rowkey,这样能够快速根据用户登陆ID查找到用户所有基本信息。

 

(2)推特表

推特表存储用户的发帖,至少包括用户名,发帖时间,以及发帖内容,用一个列族存储。

创建推特表的语句是:

create'twits', 'twits'

 

为了能够快速查找到指定用户的所有推文(登陆个人推特时显示),需要将同一个用户的所有推文都存储在一块,所以考虑将用户ID作为行键的第一部分,另外希望每个用户的推文按照时间有序,所以将时间戳作为行键的第二部分,但是这里有个问题,用户名是变长的,怎么知道行键中前面到哪儿是用户名呢,这个时候可以对用户名做MD5散列,将变长的用户名变为定长的散列值。

 

另外你希望用户显示自己的推文的时候按照时间顺序倒序排列,即读出来的推文时间新的排在前面,那么就需要利用一个小技巧,不存储真正的时间戳,而是存储倒序时间戳=Long.MAXVALUE -时间戳。所以表设计是这样的:

rowKey:MD5(用户A)+倒序时间戳#time:发帖时间,content:内容

 

(3)关系表

现在只有用户和推文功能,这明显不够,我们希望能够阅读其他人的推文,这就希望用户能够关注一些其他的用户。

具体我们需要存储哪些关系呢?

1用户A登陆,需要查看自己关注了谁,以及显示其关注的用户的推文,所以要存储用户A关注了谁?

2用户A登陆,想要查看自己的粉丝,所以需要存储谁关注了用户A?

3用户A登陆,访问用户B的推特,那么需要知道用户A有没有关注用户B?

 

一开始你可能会想这样设计表:

rowKey:用户A#1:用户B,2:用户C,3:用户D

rowKey:用户B#1:用户H,2:用户C

这样可以很轻松回答问题1和问题3.

但是问题2似乎很难回答,除非扫描整个表,以及每一行的所有列,否则找不出所有关注某个用户的人。

 

这个表设计还有一个大问题,就是当用户A关注用户B的时候,需要在用户A这一行加一列,但是我不知道现在加到哪一列了,即put数据的时候无法指定qualifier,你可能想到在每一行增加一列计数器来解决这个问题,即counter:x,但是不幸的是,HBase不支持事务操作,一旦多个客户端同时关注两个不同的用户,它们都需要取得计数器,然后插入新的一列,两个客户端很可能读到同一个计数器值,这样一个客户端的写入就会被另一个给覆盖,所以必须去掉计数器,可以用下面方式解决:

这样设计表:

rowKey:用户A#用户B:1,用户C:2,用户D:3

rowKey:用户B#用户H:1,用户C:2

 

到目前为止的设计还是没有高效的办法回答问题2.

上面两种设计都是“宽表”的形式,现在可以考虑使用“高表”的形式。

rowKey:用户A+分隔符+用户B#1:用户B昵称

即行键存储用户A关注用户B,我们将用户B的昵称放入qualifier可以节省再去用户表找用户B的昵称的时间,这是一种反规范化(de-nomalize)处理。

 

这样很容易就能想到这样一个设计:

rowKey:用户A+分隔符+关注+分隔符+用户B#1:用户B昵称

rowKey:用户A+分隔符+关注+分隔符+用户C#1:用户C昵称

rowKey:用户A+分隔符+被关注+分隔符+用户D#1:用户D昵称

rowKey:用户A+分隔符+被关注+分隔符+用户H#1:用户H昵称

这样很容易就可以回答上面三个问题,分别是用户A关注了谁?用户A关注了用户B?谁关注了用户A。不过要注意,当查找用户A的粉丝列表时,往往不想把用户A关注了谁这些集合也返回给客户端,这个时候可以通过为扫描设置起始和停止键来做到。

 

这里需要再次优化,即使用MD5对用户名进行处理,得到定长的散列值,这样做有几个好处:

1 可以抛弃掉分隔符,为扫描操作计算起始和停止键更加容易。

2 行键长度统一,可以帮助你很好地预测读写性能。

3  MD5有助于数据更加均匀地分布在region上。

所以关系表设计再次修改为这样:

rowKey:MD5(用户A)+关注+MD5(用户B)#1:用户B的昵称

rowKey:MD5(用户A)+关注+MD5(用户C)#1:用户C的昵称

rowKey:MD5(用户A)+被关注+MD5(用户D)#1:用户D的昵称

rowKey:MD5(用户A)+被关注+MD5(用户H)#1:用户H的昵称

 

但是这样还不是最优的,之前已经说过了,当查找用户A的粉丝列表时,往往不想把用户A关注了谁这些集合也返回给客户端,虽然可以通过为扫描设置起始和停止键来做到,但是在region server上面仍然要将这些不关心的数据从硬盘上读出来,才会经过扫描过滤。

所以考虑将被关注和关注两种类型分开,分别建立一个表,这下最终的表设计就这样了:

关注表:

 

rowKey:MD5(用户A)+MD5(用户B)#1:用户B的昵称

rowKey:MD5(用户A)+MD5(用户C)#1:用户C的昵称

 

被关注表:

rowKey:MD5(用户A)+MD5(用户D)#1:用户D的昵称

rowKey:MD5(用户A)+MD5(用户H)#1:用户H的昵称

 

 

创建关系表的命令是:

create'follows', 'f'

create'followedBy', 'f'

 

(4)推贴流表

进一步优化 ---反规范化处理!

设计HBase表的一个关键概念叫做反规范化。

 

截止目前为止,我们已经维护了单个用户的关注用户列表,当用户登陆账户的时候,希望看到他关注的所有人的推特,你的应用会提取关注用户列表,然后到推特表中获取每一个被关注用户的推特,然后集合这些推特按照时间排序显示出来。

 

随着系统用户数量增长,用户关注的用户的数量增长,这个过程会花费很长的时间。

此外,如果一个用户被许多人关注,那么当他的所有粉丝登陆的时候,他的推特都会被访问,他的推特都是物理上存放在一起的,所以托管这个受欢迎的人的推特的region将会不断回应请求,这样就制造了一个读热点。

 

解决这个问题的办法就是为每一个用户维护一个推特流,一旦某一个人写了推特,就将这个内容写入到关注他的人的推特流里面。这就是反规范化。

 

概念介绍:规范化和反规范化

规范化是关系型数据库里面的概念,每种重复信息都会放进一个自己的表,这样有两个好处:当发生更新和删除的时候,不用担心更新指定的数据的所有副本;通过保存单一副本,而不是多个副本,减少了占用的存储空间。需要查询时,使用SQL语句里面的join子句就可以轻易连接这些数据。

反规范化是一个相反的概念,数据是重复的,存储在多个地方,因为你不需要开销很大的join操作,这时候查询数据更加容易和快速。

规范化为写操作进行了优化,在读取数据时付出了连接数据的开销。

反规范化为读操作进行了优化,在写入时付出写多个副本的开销。

 

所以,为了为每个用户维护一个推特流,我们建立一张新表(不打算为users表增加一个列族,因为users表的行键不是为了这个目的而优化的)。

推特流表创建的命令是:

create'twitsStream', 'info'

 

推特流表设计是这样的:

rowKey:MD5(用户A)+倒序时间戳#1:用户B的昵称,2:推贴内容

rowKey:MD5(用户A)+倒序时间戳#1:用户D的昵称,2:推贴内容

rowKey:MD5(用户A)+倒序时间戳#1:用户H的昵称,2:推贴内容

共有 人打赏支持
粉丝 39
博文 129
码字总数 106697
×
莫问viva
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: