RowKey
RowKey是HBase中的重中之重,核心中的核心
HBase本质上是一个键值对列存储,也就说HBase是通过RowKey来完成检索的
总体原则
唯一性
这个不赘述了,RowKey必须保证全局唯一
长度
RowKey的长度越短越好.一个比较建议的阈值是10-100字节
因为键值对列存储的特性,RowKey会有大量的重复存储.也就说RowKey的长度会被极大的放大
以100字节RowKey为例,1000万列数据光RowKey就占用1000W*100字节,差不多1G
散列化
数据将按照RowKey进入某个Region,所以尽可能将RowKey头保持均匀分布.例如时间或UserId之类的可能分段分布的字段不要成为RowKey头,避免涌入同一个Region的数据热点问题
一些常见的散列化方式如下
- 加盐
这里的加盐是指给RowKey添加随机前缀(或者是自增前缀)来保证均匀分布,劣势是查询时很难还原完整RowKey - 哈希
哈希的优势是可以完整还原RowKey,所以在单条查询非常快.但劣势是有大量hash冲突时解决不了热点 - 反转 反转一般是尾缀时间或者手机号之类,通过反转来均匀分布.好处是即可以完整还原也能很好的解决热点,劣势是使用反转对RowKey本身分布有要求(必须是尾缀时间或手机号之类的通过反转能大致均匀分布的)
应用场景
应用场景
应用场景中不一定有时间维度,但一般自带唯一键标识
可以考虑 两位或四位(看数据量而定)哈希标识+唯一标识
统计场景
统计场景的特征一般是
- 统计数据一般都有时间维度
- 统计数据,特别是原始数据一般数据量都偏大
- 统计数据,基本都有多次重复写入的场景
所以统计数据RowKey设计可以考虑
按天分表
- 减少单表数据量
- 减少RowKey关于时间维度的存储(年月日都可以不存了)
- 自带一个按天查询条件
RowKey设计
反转(时分(四位)+毫秒(四位)),共计8位
条件查询
RowKey可以视做RDBMS的聚集索引,即数据基本按照RowKey字典序存储.因此,接近的RowKey其数据存储位置也很可能相近
条件查询是将多个期望参与查询的字段复合到一起,有点类似复合索引的感觉,经过一定的RowKey设计,实现对范围内Scan的StartRow和EndRow
比如,ExecuteId+JobId+…..+
ExecuteId本身是Guid满足均匀分布
这种方式的优势是
- 查询速度块,且相关数据靠的很近
- 可还原RowKey,对单条查询支持也非常好
劣势
- 一个表只能有一个且以后不能变更,所以一定要仔细分析用在最需要的地方
- 因为多列夹杂和补位等,带条件查询的RowKey一般都偏长,这里也需要仔细分析找出可以去掉的部分