長度越短越好
　　Rowkey是一個二進位制碼流，Rowkey的長度被很多開發者建議說設計在10~100個位元組，不過建議是越短越好，不要超過16個位元組。
　　原因如下：
　（1）資料的持久化檔案HFile中是按照KeyValue儲存的，如果Rowkey過長比如100個位元組，1000萬列資料光Rowkey就要佔用100*1000萬=10億個位元組，將近1G資料，這會極大影響HFile的儲存效率；
　（2）MemStore將快取部分資料到記憶體，如果Rowkey欄位過長記憶體的有效利用率會降低，系統將無法快取更多的資料，這會降低檢索效率。因此Rowkey的位元組長度越短越好。
　（3）目前作業系統是都是64位系統，記憶體8位元組對齊。控制在16個位元組，8位元組的整數倍利用作業系統的最佳特性。

雜湊原則
　　如果Rowkey是按時間戳的方式遞增，不要將時間放在二進位制碼的前面，建議將Rowkey的高位作為雜湊欄位，由程式迴圈生成，低位放時間欄位，這樣將提高資料均衡分佈在每個Regionserver實現負載均衡的機率。如果沒有雜湊欄位，首欄位直接是時間資訊將產生所有新資料都在一個 RegionServer上堆積的熱點現象，這樣在做資料檢索的時候負載將會集中在個別RegionServer，降低查詢效率。

唯一性
　　HBase按指定的條件獲取一批記錄時，使用的就是scan方法。 scan方法有以下特點：
　　1）scan可以通過setCaching與setBatch方法提高速度（以空間換時間）；
　　2）scan可以通過setStartRow與setEndRow來限定範圍。範圍越小，效能越高。通過巧妙的RowKey設計使我們批量獲取記錄集合中的元素挨在一起（應該在同一個Region下），可以在遍歷結果時獲得很好的效能。
　　3）scan可以通過setFilter方法新增過濾器，這也是分頁、多條件查詢的基礎。

　　設計RowKey時可以這樣做：採用 UserID + CreateTime + FileID組成RowKey。需要注意以下幾點：
　　（1）每條記錄的RowKey，每個欄位都需要填充到相同長度。假如預期我們最多有10萬量級的使用者，則userID應該統一填充至6位，如000001，000002…
　　（2）結尾新增全域性唯一的FileID的用意也是使每個檔案對應的記錄全域性唯一。