时间序列数据：

以时间作为key 和value作为列 （可以设置不同相关度的数据 为一个列簇）

1 减少行数，用更宽的行 （数据量一定的情况更宽的行可以减少行数，因为你可能两张表各存储1亿，这样检索两亿，但要是放到一张表，它就只用检索1亿个rowkey ） 可以更快的扫描。宽行并不能节省空间。物理存储 还是会展开的，不过在逻辑扫描行的时候减少了行数。

2利用单行偏移量，减少行数让一行存储更多数据，1提高扫描速度，同时每行可以更快的获得更多数据。

3节省空间：列合并，可以减少列数，相应减少列的rowkey副本数而节省空间。

在每个keyvalue中存储更多的数据。每个列都会包含一个rowkey，key是重复存储的，每列都有key的副本。

1不要用 htable  和htablepool 在appserver中因为他们都是同步的，在高并发性能低

推荐使用

Async hbase  基于hbase的异步实现库+ netty or finagle 高并发的开源server

3 每个regionserver 管理的regions不要太多，会导致挂掉恢复成本很高

Key设计：

1key一定要是等长的，变长扫描起来很低效

2进行组合key设计，  metric+时间戳 对metric（监控项）进行枚举表编码，这样可以节省大量磁盘空间

3 Rowkey的散列原则，防止出现热点

Rowkey设计原则

1.Rowkey的唯一原则

2. Rowkey的排序原则

3. Rowkey的散列原则

Region热点问题：

1、Rowkey反转

2、Rowkey前缀加Salt加盐

3、Hash散列让一个给定的行有相同的前缀，这在分散了Region负载的同时，使读操作也能够推断。

4Rowkey的-短原则

其一是HBase的持久化文件HFile是按照KeyValue存储的，

其二是MemStore缓存部分数据到内存，Rowkey过长内存的利用率会降低

做Rowkey设计时，先考虑业务是读比写多、还是读比写少，即便HBase为写优化，也可能出现热点问题，如果我们读比较多，除了考虑以上Rowkey设计原则外，还可以考虑HBase的Coprocessor甚至elastic search结合的方法，无论哪种方式，都建议做实际业务场景下数据的压力测试以得到最优结果