一直以来对rowkey的设计都比较迷茫,《hbase权威指南》倒是给出了个还算靠谱的例子。
下面这个例子有点儿像帖子表结构,它的rowkey设计是这样的,可以简单的理解为,什么人在什么时间发了什么信息,信息包括什么附件,它是用户为主线的一个设计。
<userId>-<date>-<messageId>-<attachmentId>
如果我们想查某个用户发的信息,我们可以设置scan的start rowkey 为该userId,end rowkey为userId+1即可。
当我们要查某个用户某天发了什么信息,我们可以使用<userId>-<date>来搜索该用户所有的帖子。
当我们要查某个具体的帖子的内容,rowkey过滤<userId>-<date>-<messageId>即可。
所以rowkey的设计是要看具体的应用的。
上面这个例子没有考虑热点的问题,实际上每个用户的帖子被访问的热度是不一样的,有些帖子被大量访问,有的无人问津。
那怎么办呢?有的书上写,在前面加0-n的随机数,random % 机器数 。但是这样子的话,以后你想取某个用户的userId的时候只能开多线程去访问了,因为你不能逆推出来它的rowkey。在和支付宝的工程狮聊了一下,他们是这样处理的取md5(userId)的前4位+reverse(userId)这个样子来处理userId,这样子的话,能解决热点的问题,也可以逆推出来rowkey。