1、rowkey設計不要連續，最好是hash後的結果,避免連續寫單個region server壓力過大。
2、columnfamily儘量少，原因是過多的columnfamily之間會互相影響
3、VERSIONS 最大版本數：通常是3，如果對於更新比較頻繁的應用完全可以設置爲1，能夠快速的淘汰無用數據，對於節省存儲空間和提高查詢速度有效果。不過這類需求在海量數據領域比較小衆。
4、COMPRESSION壓縮算法：可以嘗試snappy算法，相對lzo來說，壓縮率接近，壓縮效率稍高，解壓效率高很多。
5、bloomfilter：根據應用來定，看需要精確到rowkey還是column,通常精確rowkey就可以。不過這裏需要理解一下原理，bloomfilter的作用是對一個region下查找記錄所在的hfile有用。即如果一個region下的hfile數量很多，bloomfilter的作用越明顯。適合那種compaction趕不上flush速度的應用
6、inmemory：表在內存中存放，一直會被忽略的屬性(false)。如果完全將數據存放在內存中，那麼hbase和現在流行的內存數據庫memcached和redis性能差距有多少，尚待實測。
下面以視頻個性化推薦系統爲例，介紹常見的兩種常用的schema設計模式：
第一種推薦模型存儲方式【固定列】：
對於column需要擴展的應用，column可以按普通的方式設計如下面第二種設計。但是對於列相對固定的應用，最好採用將一行記錄封裝到一個column中的方式，並採用Row /Family/Qualifier前綴樹形式進行壓縮，這樣能夠節省存儲空間並且可以提高查詢效率，其效率至少在二分查找以上。 設置表的列屬性 DATA_BLOCK_ENCODING 值爲PREFIX_TREE ,PREFIX_TREE在壓縮空間的基礎上又可以減少CPU。
從作者【HBASE-4676】提供的DataBlock查找性能對比：
說明：
1.作者沒有指出單條KV的平均大小
2.NONE 指的是不啓用DataBlock Encode；PREFIX【HBASE-4218】指的是PREFIX Encode算法；TRIE纔是前綴樹block壓縮算法。
3. 前綴樹壓縮算法在不同的block size下查找性能都很穩定，而NONE和PREFIX由於是用遍歷的方式查找數據，所以查找性能隨着blocksize直線下降。對於我們默認的64K的block大小，性能相差40+倍
4.NONE比PREFIX算法性能好，是由於PREFIX算法需要解壓
其中 三種爲 PREFIX、DIFF或FAST_DIFF目的是以cpu換空間在不計較空間的情形下，即命中率都爲100%，那麼開啓DIFF/FAST_DIFF,相比於NONE，對數據查詢效率沒有提升，甚至會帶來壓縮/解壓縮對CPU資源佔用的情況。
Set ENCODE_ON_DISK to true on column descriptor to have the encoding in place out in the hfile
設計的表結構如下所示：
第二種用戶實時播放記錄記錄存放方式【不定列】：
這種設計有利於scan(startkey,endkey)的掃描方法，而這種方法和get的效率相當，而且還很穩定。
這種情況主要防止客戶端查詢OOM，某一個key下面包含的column過多。通常來說，hbase的column數目不要超過百萬這個數量級。這種情況主要考慮column設計到rowkey的方法解決。下面是我們實踐中的設計table結構。
轉載請附原文鏈接:http://blog.csdn.net/map_lixiupeng/article/details/40894023
