HBase概念学习开发一个类twitter系统之表设计
Posted cxchanpin
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HBase概念学习开发一个类twitter系统之表设计相关的知识,希望对你有一定的参考价值。
这边文章先将可能的需求分析一下,设计出HBase表,下一步再開始编写client代码。
TwiBase系统
1、背景
为了加深HBase基本概念的学习,參考HBase实战这本书实际动手做了这个样例。
2、需求
这是一个用户推特系统,用户登陆到系统。须要维护用户的基本信息。然后用户能够发帖和其它用户进行互动。用户之间能够相互关注。用户能够浏览关注用户的推文等等。
这是一个比較简单的推特系统。不考虑用户之间的私信,用户评论推特等功能。
3、概要设计
3.1表设计
首先须要设计三个表:用户表。推特表以及用户之间的关系表。
(1)用户表
用户表至少包括唯一的username,用户昵称,用户邮箱以及用户发帖数量。用一个列族存储。
创建用户表的语句是:
create‘users‘, ‘info‘
当中username用作rowkey。这样可以高速依据用户登陆ID查找到用户全部基本信息。
(2)推特表
推特表存储用户的发帖,至少包含username,发帖时间。以及发帖内容。用一个列族存储。
创建推特表的语句是:
create‘twits‘, ‘twits‘
为了可以高速查找到指定用户的全部推文(登陆个人推特时显示),须要将同一个用户的全部推文都存储在一块,所以考虑将用户ID作为行键的第一部分,另外希望每一个用户的推文依照时间有序,所以将时间戳作为行键的第二部分,可是这里有个问题。username是变长的,怎么知道行键中前面到哪儿是username呢,这个时候可以对username做MD5散列,将变长的username变为定长的散列值。
另外你希望用户显示自己的推文的时候依照时间顺序倒序排列。即读出来的推文时间新的排在前面。那么就须要利用一个小技巧,不存储真正的时间戳。而是存储倒序时间戳=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不支持事务操作。一旦多个client同一时候关注两个不同的用户,它们都须要取得计数器,然后插入新的一列,两个client非常可能读到同一个计数器值,这样一个client的写入就会被另一个给覆盖,所以必须去掉计数器,能够用以下方式解决:
这样设计表:
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)处理。
这样非常easy就能想到这样一个设计:
rowKey:用户A+分隔符+关注+分隔符+用户B#1:用户B昵称
rowKey:用户A+分隔符+关注+分隔符+用户C#1:用户C昵称
rowKey:用户A+分隔符+被关注+分隔符+用户D#1:用户D昵称
rowKey:用户A+分隔符+被关注+分隔符+用户H#1:用户H昵称
这样非常easy就能够回答上面三个问题,各自是用户A关注了谁?用户A关注了用户B?谁关注了用户A。只是要注意,当查找用户A的粉丝列表时。往往不想把用户A关注了谁这些集合也返回给client。这个时候能够通过为扫描设置起始和停止键来做到。
这里须要再次优化,即使用MD5对username进行处理,得到定长的散列值。这样做有几个优点:
1 能够抛弃掉分隔符,为扫描操作计算起始和停止键更加easy。
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关注了谁这些集合也返回给client,尽管能够通过为扫描设置起始和停止键来做到。可是在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操作,这时候查询数据更加easy和高速。
规范化为写操作进行了优化,在读取数据时付出了连接数据的开销。
反规范化为读操作进行了优化。在写入时付出写多个副本的开销。
所以,为了为每一个用户维护一个推特流。我们建立一张新表(不打算为users表添加一个列族。由于users表的行键不是为了这个目的而优化的)。
推特流表创建的命令是:
create‘twitsStream‘, ‘info‘
推特流表设计是这种:
rowKey:MD5(用户A)+倒序时间戳#1:用户B的昵称,2:推贴内容
rowKey:MD5(用户A)+倒序时间戳#1:用户D的昵称,2:推贴内容
rowKey:MD5(用户A)+倒序时间戳#1:用户H的昵称,2:推贴内容
(未完待续。。。
)
若有什么疑问和不吝赐教,欢迎交流。联系邮箱: [email protected] 季义钦
作为兴趣点,眼下本人正在研究HBase和Hadoop
以上是关于HBase概念学习开发一个类twitter系统之表设计的主要内容,如果未能解决你的问题,请参考以下文章