hbase设计，
表的设计在hbase中相当重要，通过此文记录一些hbase设计中可能需要注意的部分
基础知识
hbase有两种基本的键结构，行键（row key）和列键（column key）。他们可以存储的信息有两类：
- 键本身存储内容
- 键的排列顺序
hbase中每一行单元格被有序的存储，同时不同的列族的数据存储在不同的文件中。即磁盘上一个列族下的所有单元格都存储在一个store file中，不同的列族不会存储在一个store file中。
hbase存储是每个单元格都保存了它的行键和列键，同时空值单元格不被存储。
含有信息的整个单元格在hbase中叫做key-value。key-value先按行键排序（字典序，升序）再按列键排序，最后按时间戳降序排序。
根据以上结构，不难发现，按行来筛选，是hbase最优效率的删选方式
原则一：选择高表而不是宽表
我们已经知道在hbase的查询中，按照row key来查询是最有效率的方式。所以显然高表（拥有更多的行键）具有更高的查询效率
对时间序列的处理
时间序列是我们实际中最容易遇到的一种数据，比如我们实时监控自己实验室的网络流量，统计不同时间段的流量。而这样的有序序列会导致一个显而易见的问题——所有的数据都被击中在了一些热点region上。而由于一个region只能由一个服务器管理，最终导致的结果就是系统产生读写热点，不符合我们分布式负载均衡的思想。所以必须有一些方法来解决这个问题
salting方法
用户可以使用salting前缀来保证数据分散到所有的region服务器。例如
byte prefix = (byte)(Long.hashCode(timestamp)%<number of region servers>);
byte[] row key = Bytes.add(Bytes.toBytes(prefix),Bytes.toBytes(timestamp))这样做的坏处就是用户想要扫描一个连续的范围时，可能需要对每个region服务器都发起请求。好处就是这样就可以并发的读取数据。
以上方法其实就是一种组合行键的方法，其核心思想就是将连续递增的时间戳由第一位变为第二位。所以当我们的行键已经有多个字段的时候我们就可以不必这么做，只需要调整位置即可。比如我们有五个探针来监测网络数据，这五个的编号是0~4，自然的我们就可以把此编号放在row key的第一位
随机化
另一种完全不同的方式是将行键随机化，例如
byte[] row key = MD5[timestamp]采用MD5之类的散列函数能将行键分散到所有的region服务器上。
但是这种方法显然不适用于需要时间扫描访问的情况，因为它完全破坏了原始数据的连续性。另一方面，如果我们对数据只是随机访问，一次读取一行，那么该方法便可行。