rowkey 行键

• 应避免使用时序或单调行键。因为当数据到来时，HBASE首先需要根据记录的行键来确定存储位置，即Region的位置。如果使用时序或单调 行建，那么连续到来的数据将会被分配到同一个Region当中，而此时系统化中的其他Region/RegionServer将处于空闲状态，这是分布式 系统最不希望看到的。
• 数字rowkey的从大到小排序：原生hbase只支持从小到大的排序，这样就对于排行榜一类的查询需求很尴尬。那么采用rowkey = Integer.MAX_VALUE-rowkey的方式将rowkey进行转换，最大的变最小，最小的变最大。在应用层再转回来即可完成排序需求。
• rowkey的散列原则：如果rowkey是类似时间戳的方式递增的生成，建议不要使用正序直接写入rowkey，而是采用reverse的 方式反转rowkey，使得rowkey大致均衡分布，这样设计有个好处是能将regionserver的负载均衡，否则容易产生所有新数据都在一个 regionserver上堆积的现象，这一点还可以结合table的预切分一起设计。

模式，建议使用tall narrow模式

把HBase的查询等价为一个逐层过滤的行为，那么在设计存储时就应该明白，使设计越趋向单一的keyvalue性能会越好；如果是因为复杂的业务 逻辑导致查询需要确定rowkey、column、timestamp，甚至更夸张的是用到了HBase的Filter在server端做value的处 理，那么整个性能会非常低。

因此在表结构设计时，HBase里有tall narrow和flat wide两种设计模式，前者行多列少，整个表结构高且窄；后者行少列多，表结构平且宽；但是由于HBase只能在行的边界做split，因此如果选择 flat wide的结构，那么在特殊行变的超级大（超过file或region的上限）时，那么这种行为会导致compaction，而这样做是要把row读内存 的~~因此，强烈推荐使用tall narrow模式设计表结构，这样结构更趋近于key value，性能更好。