以下為使用hbase一段時間的幾個思考，由於在記憶體充足的情況下hbase能提供比較滿意的讀效能，因此寫效能是思考的重點。希望讀者提出不同意見討論
1 autoflush=false
2 hbase.hregion.max.filesize
hbase中hfile的預設最大值(hbase.hregion.max.filesize)是256mb，而google的bigtable**中對tablet的最大值也推薦為100-200mb，這個大小有什麼秘密呢？
眾所周知hbase中資料一開始會寫入memstore，當memstore滿64mb以後，會flush到disk上而成為storefile。當storefile數量超過3時，會啟動compaction過程將它們合併為乙個storefile。這個過程中會刪除一些timestamp過期的資料，比如update的資料。而當合併後的storefile大小大於hfile預設最大值時，會觸發split動作，將它切分成兩個region。
根據持續insert壓力測試，並設定了不同的hbase.hregion.max.filesize，根據結果得到如下結論：值越小，平均吞吐量越大，但吞吐量越不穩定；值越大，平均吞吐量越小，吞吐量不穩定的時間相對更小。
為什麼會這樣呢？推論如下：
3.table中family和qualifier
對於傳統關係型資料庫中的一張table，在業務轉換到hbase上建模時，從效能的角度應該如何設定family和qualifier呢？
hbase目前不能良好的處理超過包含2-3個cf的表。因為某個cf在flush發生時，它鄰近的cf也會因關聯效應被觸發flush，最終導致系統產生更多io
最極端的，可以每一列都設定成乙個family，也可以只有乙個family，但所有列都是其中的乙個qualifier，那麼有什麼區別呢？
family越多，那麼獲取每乙個cell資料的優勢越明顯，因為io和網路都減少了，而如果只有乙個family，那麼每一次讀都會讀取當前rowkey的所有資料，網路和io上會有一些損失。
當然如果要獲取的是固定的幾列資料，那麼把這幾列寫到乙個family中比分別設定family要更好，因為只需一次請求就能拿回所有資料。
首先，不同的family是在同乙個region下面。而每乙個family都會分配乙個memstore，所以
更多的family會消耗更多的記憶體。
其次,目前版本的hbase，在flush和compaction都是以region為單位的，也就是說當乙個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中只有很少的資料也會觸發flush而生成小檔案。這樣就增加了compaction發生的機率，而compaction也是以region為單位的，
這樣就很容易發生compaction風暴從而降低系統的整體吞吐量。
第三，由於hfile是以family為單位的，因此對於多個family來說，
資料被分散到了更多的hfile中，減小了split發生的機率
Hbase效能優化
1 表的設計 1.1 pre creating regions 預設情況下，在建立hbase表的時候會自動建立乙個region分割槽，當匯入資料的時候，所有的hbase客戶端都向這乙個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的re...
hbase資料讀取優化 HBase效能優化 總結篇
1 hbase.hregion.max.filesize應該設定多少合適 預設值 256m 說明 maximum hstorefile size.if any one of a column families hstorefiles has?grown to exceed this value,th...
Hbase查詢效能優化
hbase雖然能提供海量資料的實時讀寫，但是一旦資料量非常大，查詢延遲也會非常高，所以要做好優化工作。1 列族越少越好 1 列族 cf 數量，在記憶體結構中乙個cf對應乙個store區域，乙個store中又存在多個storefile小檔案，小storefile是不斷合併新的大的storefile，資...