HBase 優化，columnFamily和qualifierColumn的設計原則

1、把一個傳統的關係型數據庫中的數據映射到hbase，從性能的角度如何優化ColumnFamily和qualifierColumn.

2、兩個比較極端的狀況，（1）關係型數據庫中的每一列對應一個columnFamily，（2）關係型數據庫中一張表對應一個columnFamily。

3、從讀的角度分析性能

（1）若是columnFamily越多，讀取一個cell的速度優點是比較明顯的，由於找到這個columnfamily，就等於找了column及其對應的值；

（2）若是一張表對應一個columnfamily，找到對應的rowkey後，要把columnfamily對應的多列值都讀取到，這樣磁盤io和網絡消耗的都比較多，速度會慢些。

（3）若是某些列是常常要一塊兒讀取的，把這些歸到一個columnfamily後面，一次請求就能夠獲取這些列，比分屢次請求獲取效率要高。

4、從寫的角度分析性能

（1）從regionserver內存消耗角度，根據hbase特色，一個columnfamily對應一個HStore,而每個Hstore都有一個本身的memstore，若是columnfamily太多，對regionserver的內存消耗就很大。

（2）從flush和compaction角度，目前hbase的flush和compaction都是以region爲單位（雖然觸發這個動做的條件有多個），若是columnfamily太多，很容易觸發flush操做，對於不少memstore中的數據量可能還不多，這樣flush就會產生大量小文件，而大量的小文件（即storefile）就會觸發compaction操做，頻繁的這樣操做，會下降集羣的性能。

（3）從split角度分析，storefile是以columnfamily爲單位的，大量的columnfamily能夠減小split的發生，但這是一把雙刃劍；由於的更少的split會致使部分region過於偏大，而regionserver之間進行balance時按region的數量進行負載均衡而不是按region的大小，這樣可能就會致使balance失效。從好的一方面來看，更少的split會讓集羣運行的更穩定，而後選擇在集羣空閒或壓力小的時候手動執行split和balance。

（4）所以對於寫部分，通常離線集羣，一張表使用一個columnfamily便可，對於在線集羣，能夠根據狀況合理分配columnfamily個數。

補充：目前咱們的集羣是在線集羣，咱們有一張在線使用表存儲了不少數據，通過綜合考慮只設計了一個columnfamily，主要考慮到，對於這個表中數據，天天查詢量能夠打三千萬左右次，而表中天天新增數據只有幾十G，這樣設計能夠減小split和flush的操做，讓集羣更多的時間處在穩定運行狀態，這樣有利於查詢。

轉載自：https://my.oschina.net/u/3197158/blog/994898/