Hbase---rowkey的设计

rowkey的设计

设计的三大原则

  1. Rowkey长度原则
    Rowkey是一个二进制码流,Rowkey的长度被很多开发者建议设计在10-100个字节,不过建议是越短越好,不要超过16个字节
    原因如下:
  • 数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,1000万列数据光Rowkey就要占用100*1000万=10亿个字节,将近1G数据,这会极大影响Hfile的存储效率;
  • MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率降低,系统将无法缓存更多的数据,这会降低检索效率,因此Rowkey的字节长度越短越好。
  • 目前操作系统一般都是64位系统,内存8字节对齐,空值在16个字节,8字节的整数倍利用操作系统的最佳特性。
  1. Rowkey散列原则
    如果Rowkey是按时间戳的方式递增,因为rowkey是按照字典顺序排序的,这样会出现大量的数据插入到一个reion中,而其他的region相对比较空闲从而造成热点问题,所以尽量不要将开头相同的内容作为rowkey造成热点问题,可以将时间戳反转后在作为rowkey。
  2. Rowkey唯一原则
    必须在设计Rowkey上保证其唯一性。否则前面插入的数据将会被覆盖。

常见的避免热点的方法以及它们的优缺点

加盐
这里所说的加盐不是密码学中的加盐,而是在rowkey的前面增加随机数,具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上,以避免热点。
哈希
哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群,但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey,可以使用get操作准确获取某一个行数据
反转
第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分(最没有意义的部分)放在前面。这样可以有效的随机rowkey,但是牺牲了rowkey的有序性。
比如手机号的反转,时间戳的反转,当一个连续递增的数字类型想要作为rowkey时,可以用一个很大的数去减这个rowkey,反转后再当成rowkey

你可能感兴趣的:(hbase,大数据,数据库)