1、列族的数量及列族的势
建议将HBase列族的数量设置的越少越好。当强，对于两个或两个以上的列族HBase并不能处理的很好。这是由于HBase的Flushing和压缩是基于Region的。当一个列族所存储的数据达到Flushing的阈值时，该表中所有列族将同时进行Flushing操作。这将带来不必要的I/O开销，列族越多，该特性带来的影响越大。
此外，还要考虑到同一个表中不同列族所存储的记录数量的差别，即列族的势(Cardinality)。当两个列族数量差别过大时会使包含记录数量较少列族的数据分散在多个Region上，而Region有可能存储在不同的RegionServer上。这样，当进行查询或scan操作的时候，系统效率将会受到影响。
在多列簇的情况下，注意各列簇数据的数量级要一致。如果两个列簇的数量级相差太大，会使数量级少的列簇的数据扫描效率低下。
将经常查询和不经常查询的数据放到不同的列簇。
2、行键(RowKey)的设计
首先应该避免使用时序或单调(递减/递增)行键。因为当数据到来的时候，HBase首先需要根据记录的行键来确定存储的位置，即Region的位置，如果使用时序或单调行键，那么连续到来的数据将被分配到同一个Region中，而此时系统的其他Region/RegionServer处于空闲状态，这是分布式最不希望看到的状态。
如果rowkey是整型，用二进制的方式比用string来存储更节约空间
合理的控制rowkey的长度，尽可能短,因为rowkey的数据也会存在每个Cell中。
如果需要将表预分裂为多个region是，最好自定义分裂的规则。
3、尽量最小化行键和列族的大小
在HBase中，一个具体的值由存储该值的行键、对应的列(列族：列)以及该值的时间戳决定。HBase中索引是为了加速随即访问的速度，索引的创建是基于“行键+列族：列+时间戳+值”的，如果行键和列族的大小过大，甚至超过值本身的大小，纳闷将会增加索引的大小。并且在HBase中数据记录往往非常之多，重复的行键、列将不但使索引的大小过大，也将加重系统的负担
4、版本的数量
默认情况下为3个，可以通过HColumnDescriptor进行设置，建议不要设置的过大