hbase:rowkey的设计

hbase的rowkey设计决定了数据的分区和查询的方式，是使用hbase前一定要想清楚的，以下简单列举了设计hbase rowkey时需要考虑的问题

1. rowkey是唯一的吗？
   rowkey相同的记录在hbase里被认为是同一条数据的多个版本，查询时默认返回最新版本的数据，所以通常rowkey都需要保证唯一，除非用到多版本特性
   最佳设计实践：
   rowkey就好比数据库的里的主键，他唯一确定了一条记录，它可以是一个字段也可以是多个字段拼接起来:
   每个用户只有一条记录： [userid]
   每个用户有多条交易记录：[userid][orderid]

2. 满足查询场景吗？
   rowkey的设计限制了数据的查询方式，hbase只有两种查询方式：
   1). 根据完整的rowkey查询（get):
   类似传统DB的sql: select * from table where rowkey = ‘abcde’
   这种查询方式需要知道完整的rowkey，即组成rowkey的所有字段的值都是确定的
   2). 根据rowkey的范围查询（scan):
   类似传统DB的sql: select * from table where ‘abc’ < rowkey <’abcx’
   这种查询方式需要知道数据rowkey左边的值，就好像一本英文字典，你可以查询pre开头的所有单词，也可以查询prefi开头的所有单词，但是没办法查询中间是efi或结尾是ix的所有单词，除非翻阅整个字典

最佳设计实践：
在有限的查询方式下如何实现复杂查询：
1.再建另外一张表作为索引表，应用端双写
2.使用filter，在服务端过滤掉不需要的数据
3.如何实现倒序（新的数据排在前面，如：order by orderTime desc）：
使用反向scan：scan.setReverse(true) #反向scan的性能比正常scan要差,而且这个特性在0.98.6后才有，0.94没这个api
如果倒序的场景占大头可以设计上就把数据倒序： [hostname][log-event][timestamp] => [hostname][log-event][Long.MAX_VALUE – timestamp]

3. 数据足够分散，会产生热点吗？
   散列的目的是数据可以分散到不同的分区，不至于产生热点，把某一台服务器累死，其他服务器闲置，充分发挥分布式和并发的优势
   最佳设计实践:
   1.md5 [userId][orderid] => [md5(userid).subStr(0,4)][userId][orderid]
   2.反转 [userId][orderid] => [reverse(userid)][orderid]
   3.取模 [timestamp][hostname][log-event] => [bucket][timestamp][hostname][log-event] long bucket = timestamp % numBuckets;
   4.增加随机数 [userId][orderid] => [item][orderid][random(100)]

4. rowkey可以再短点吗?
   短的rowkey可以减少数据量 ，提高查询写入性能
   最佳设计实践：

5. 使用long或int型代替String 如： '2015122410' => Long(2015122410)

6. 使用编码代替名称, 比如"taobao" => 'tb'

7. scan时会不会查询出不需要的数据？

假设有以下场景：
table1的rowkey是: colume1+ colume2+ colume3
现在需要查询colume1= host1 的所有数据：

scan 'table1',{startkey=> 'host1',endkey=> 'host2'}
此时如果有一条记录colume1=host12，这条记录也会被查询出来：因为:
'host1' < 'host12' < 'host2'
但显然这条记录不是我们想要的
最佳设计实践：

1. 字段定长 [colume1][colume2] => [rpad(colume1,'x',20)][colume2]
2. 添加分隔符 [colume1][colume2] => [colume1][_][colume2]

常见设计实例：

日志类、时间序列数据
查询场景：
1.查询某台机器某个指标某段时间内的数据
[hostname][log-event][timestamp]

2.查询某台机器某个指标最新的几条数据
timestamp = Long.MAX_VALUE – timestamp
[hostname][log-event][timestamp]

3.数据只有时间一个维度或某一个维度数据量特别大
long bucket = timestamp % numBuckets;
[bucket][timestamp][hostname][log-event]

交易类数据
查询场景：
1.查询某个卖家某段时间内的交易记录
[seller id][timestmap][order number]

2.查询某个买家某段时间内的交易记录
[buyer id][timestmap][order number]

3.根据订单号查询
[order number]

4.同时满足1，2，3
三张表：
一张买家维度表，rowkey为：
[buyer id][timestmap][order number]
一张卖家维度表，rowkey为：
[seller id][timestmap][order number]