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進行設定，建議不要設定的過大