因為一直在做hbase的應用層面的開發，所以體會的比較深的一點是hbase的表結構設計會對系統的性能以及開銷上造成很大的區別，本篇文章先按照hbase表中的rowkey、columnfamily、column、timestamp幾個方面進行一些分析。最后結合分析如何設計一種適合應用的高效表結構。
1、表的屬性
(1)最大版本數：通常是3，如果對於更新比較頻繁的應用完全可以設置為1，能夠快速的淘汰無用數據，對於節省存儲空間和提高查詢速度有效果。不過這類需求在海量數據領域比較小眾。
(2)壓縮算法：可以嘗試一下最新出爐的snappy算法，相對lzo來說，壓縮率接近，壓縮效率稍高，解壓效率高很多。
(3)inmemory：表在內存中存放，一直會被忽略的屬性。如果完全將數據存放在內存中，那么hbase和現在流行的內存數據庫memorycached和redis性能差距有多少，尚待實測。
(4)bloomfilter：根據應用來定，看需要精確到rowkey還是column。不過這里需要理解一下原理，bloomfilter的作用是對一個region下查找記錄所在的hfile有用。即如果一個region下的hfile數量很多，bloomfilter的作用越明顯。適合那種compaction趕不上flush速度的應用。
2、rowkey
rowkey是hbase的key-value存儲中的key，通常使用用戶要查詢的字段作為rowkey，查詢結果作為value。可以通過設計滿足幾種不同的查詢需求。
(1)數字rowkey的從大到小排序：原生hbase只支持從小到大的排序，這樣就對於排行榜一類的查詢需求很尷尬。那么采用rowkey = Integer.MAX_VALUE-rowkey的方式將rowkey進行轉換，最大的變最小，最小的變最大。在應用層再轉回來即可完成排序需求。
(2)rowkey的散列原則：如果rowkey是類似時間戳的方式遞增的生成，建議不要使用正序直接寫入rowkey，而是采用reverse的方式反轉rowkey，使得rowkey大致均衡分布，這樣設計有個好處是能將regionserver的負載均衡，否則容易產生所有新數據都在一個regionserver上堆積的現象，這一點還可以結合table的預切分一起設計。
3、columnfamily
columnfamily盡量少，原因是過多的columnfamily之間會互相影響。
4、column
對於column需要擴展的應用，column可以按普通的方式設計，但是對於列相對固定的應用，最好采用將一行記錄封裝到一個column中的方式，這樣能夠節省存儲空間。封裝的方式推薦protocolbuffer。
以下會分場景介紹一些特殊的表結構設計方法，只是一些摸索，歡迎討論：
value數目過多場景下的表結構設計：
目前我碰到了一種key-value的數據結構，某一個key下面包含的column很多，以致於客戶端查詢的時候oom，bulkload寫入的時候oom，regionsplit的時候失敗這三種后果。通常來講，hbase的column數目不要超過百萬這個數量級。在官方的說明和我實際的測試中都驗證了這一點。
有兩種思路可以參考，第一種是單獨處理這些特殊的rowkey，第二種如下：
可以考慮將column設計到rowkey的方法解決。例如原來的rowkey是uid1,，column是uid2，uid3...。重新設計之后rowkey為<uid1>~<uid2>，<uid1>~<uid3>...當然大家會有疑問，這種方式如何查詢，如果要查詢uid1下面的所有uid怎么辦。這里說明一下hbase並不是只有get一種隨機讀取的方法。而是含有scan(startkey,endkey)的掃描方法，而這種方法和get的效率相當。需要取得uid1下的記錄只需要new Scan("uid1~","uid1~~")即可。
原文地址：http://my.oschina.net/u/1450520/blog/318726