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]

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • hbase的rowkey设计决定了数据的分区和查询的方式,是使用hbase前一定要想清楚的,以下简单列举了设计hb...
    程序猿小哥阅读 3,401评论 0 2
  • rowkey长度原则 rowkey是一个二进制码流,可以是任意字符串,最大长度 64kb ,实际应用中一般为10-...
    blotstorm阅读 341评论 0 4
  • Hbase RowKey 设计 使用Spark或通过REST/API 方式存取Hbase,性能影响最大的因素在于H...
    阿海与蜗牛阅读 5,704评论 0 10
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,837评论 18 139
  • 如今的生活,比小时候丰富多彩了三倍之多,开心、快乐没有随着时间的推移与日俱增!因此,在闲暇的时光里我们不由得又怀念...
    夏目心叶阅读 1,078评论 1 11