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.使用二级索引

4.如何实现倒序(新的数据排在前面,如:order by orderTime desc):

  使用反向scan:scan.setReverse(true)

  #反向scan的性能比正常scan要差,如果倒序的场景占大头可以设计上就把数据倒序:

  [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] => [userId][orderid][random(100)]

4. rowkey可以再短点吗?

短的rowkey可以减少数据量 ,提高查询写入性能

最佳设计实践:

1. 使用long或int型代替String

  如: '2015122410' => Long(2015122410)

2. 使用编码代替名称

  如:’淘宝‘ => tb

5. 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]

一张订单索引表,rowkey为:

[order number]

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

东境物语

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值