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