Hbase Rowkey设计原则

转载自：https://blog.youkuaiyun.com/gongpulin/article/details/78328546

1. 长度越短越好
   　　Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。
   　　原因如下：
   　（1）数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率；
   　（2）MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。
   　（3）目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。

2. 散列原则
   　　如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。

3. 唯一性
   　　HBase按指定的条件获取一批记录时，使用的就是scan方法。 scan方法有以下特点：
   　　1）scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；
   　　2）scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下），可以在遍历结果时获得很好的性能。
   　　3）scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。

   　　设计RowKey时可以这样做：采用 UserID + CreateTime + FileID组成RowKey。需要注意以下几点：
   　　（1）每条记录的RowKey，每个字段都需要填充到相同长度。假如预期我们最多有10万量级的用户，则userID应该统一填充至6位，如000001，000002…
   　　（2）结尾添加全局唯一的FileID的用意也是使每个文件对应的记录全局唯一。