一、把一個傳統的關係型數據庫中的數據映射到hbase，從性能的角度如何優化ColumnFamily和qualifierColumn.
二、兩個比較極端的情況，（1）關係型數據庫中的每一列對應一個columnFamily，（2）關係型數據庫中一張表對應一個columnFamily。
三、從讀的角度分析性能
（1）如果columnFamily越多，讀取一個cell的速度優勢是比較明顯的，因爲找到這個columnfamily，就等於找了column及其對應的值；
（2）如果一張表對應一個columnfamily，找到對應的rowkey後，要把columnfamily對應的多列值都讀取到，這樣磁盤io和網絡消耗的都比較多，速度會慢些。
（3）如果某些列是經常要一起讀取的，把這些歸到一個columnfamily後面，一次請求就可以獲取這些列，比分多次請求獲取效率要高。
四、從寫的角度分析性能
（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的操作，讓集羣更多的時間處在穩定運行狀態，這樣有利於查詢。