HBase的rowkey设计

对于任何系统的数据设计，我们都是想提高性能达到资源最大化利用，对于Hbase我们产生两个疑问：

1，habaserowkey设计如何才能提高性能

2，habase如火热设计才能散列到不同的节点

我们知道 hbasetable的行只有三种访问方式就是通过rowkey访问，通过rowkey的range访问  和全表扫描

hbase的查询时间只提供了两种方式：

一个是指定rowkey获取唯一一条记录，get方法

一个就是指定条件获取一批记录  scan方法
在使用条件查询用scan方法时需要注意一下几点：
1，scan可以通过setCaching和setBatch方法提高速度，以空间换时间
2，可以通过setStartRow与setEndRow来限定范围。范围越小性能越高
3， 可以通过setFilter方法添加过滤器这也是分页，多条件查询的基础
HBase的rowkey设计
1设计原则：
a 长度原则 rowkey是一个二级制码流   rowkey的长度越短越好。
1数据的持久化文件hfile是按照keyvalue存储的，如果rowkey过长，那么数据中rowkey占据的存储就越大，加大影响hfile的存储效率
2Memstore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统就无法缓存更多的数据，降低检索效率
3，由于目前pc机器操作系统基本都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍有利于操作系统的最佳特性
b散列原则
如果rowkey是按照时间戳的方式递增，不要将时间放在二进制码的前面，高位作为散列字段建议由程序生成，时间戳放在低位，这样讲提高数据均衡分布在没个regionsever以实现负载均衡的几率，如果没有散列字段，首字段直接是时间信息的话将产生所有数据集中在一个region上，这样造成堆积热点，这样做数据检索的时候负载也会集中到这个region上，导致查询效率降低，不能发挥集群的整体性能
C rowkey要保证唯一性


基于rowkey上述3个原则，针对不同的场景也有不同的设计建议
1针对事务性数据的rowkey设计
事务性数据时带时间属性的，建议将时间信息存入rowkey，这有助于提升查询检索速度
针对事务数据建议按天为数据建表，按天分表后时间信息就可以去掉日期部分只保留小时分钟毫秒，这样4个字节就搞定，加上散列字段2个字节一共6个字节就可以组成唯一的rowkey 虽然这样设计从操作系统方面没有节省开销因为64为系统必须8字节对齐，但是对于持久化中的rowkey大概节省了25%而且保证了时间范围内数据的连续，有利于数据的检索查询
2，针对统计数据的rowkey
统计数据也是带时间属性的，统计数据最小单位只会到分，到秒没有任何意义。同时对于统计数据采用按天数据分表，时间信息只要保留小时和分钟，只需要占用3个字节，用于统计数据某些维度数量大，因此用4个字节作为序列字段，加上2个散列字段一起6个字节组成rowkey
3针对通用数据的rowkey
通用数据采用自增序列作为唯一主键，用户可以选择按天建分表也可以选择单表模式。需要确保同时多个入口加载模块运行时散列字段的唯一因子区分
4，针对多条件查询的rowkey
HBas按指定的条件获取一批记录使用scan方法
1，通过setCaching和setBatch方法提高速度
2通过setStartRow和setEndRow限定范围提高性能
3，通过setFilter添加过滤器  分页多条件查询
于是在满足长度，散列 唯一原则后，可以根据多条件查询的条件组合成一个rowkey