Hbase 表的设计原则 ————总结

一、列族的数量及列族的势

建议将HBase列族的数量设置的越少越好。当强，对于两个或两个以上的列族HBase并不能处理的很好。这是因为HBase的Flushing和压缩是基于Region的。当一个列族所存储的数据达到Flushing的阈值时，该表中全部列族将同时进行Flushing操做。这将带来没必要要的I/O开销，列族越多，该特性带来的影响越大。

此外，还要考虑到同一个表中不一样列族所存储的记录数量的差异，即列族的势(Cardinality)。当两个列族数量差异过大时会使包含记录数量较少列族的数据分散在多个Region上，而Region有可能存储在不一样的RegionServer上。这样，当进行查询或scan操做的时候，系统效率将会受到影响。

在多列簇的状况下，注意各列簇数据的数量级要一致。若是两个列簇的数量级相差太大，会使数量级少的列簇的数据扫描效率低下。
将常常查询和不常常查询的数据放到不一样的列簇。

二、行键(RowKey)的设计

首先应该避免使用时序或单调(递减/递增)行键。由于当数据到来的时候，HBase首先须要根据记录的行键来肯定存储的位置，即Region的位置，若是使用时序或单调行键，那么连续到来的数据将被分配到同一个Region中，而此时系统的其余Region/RegionServer处于空闲状态，这是分布式最不但愿看到的状态。

       若是rowkey是整型，用二进制的方式比用string来存储更节约空间
      合理的控制rowkey的长度，尽量短,由于rowkey的数据也会存在每一个Cell中。
      若是须要将表预分裂为多个region是，最好自定义分裂的规则。

三、尽可能最小化行键和列族的大小

在HBase中，一个具体的值由存储该值的行键、对应的列(列族：列)以及该值的时间戳决定。HBase中索引是为了加速随即访问的速度，索引的建立是基于“行键+列族：列+时间戳+值”的，若是行键和列族的大小过大，甚至超过值自己的大小，纳闷将会增长索引的大小。而且在HBase中数据记录每每很是之多，重复的行键、列将不但使索引的大小过大，也将加剧系统的负担

四、版本的数量

默认状况下为3个，能够经过HColumnDescriptor进行设置，建议不要设置的过大