HBase是三維有序儲存的，三維指的是：RowKey(行健)、column key(columnFamily和qualifier)、TimeStamp(時間戳)，通過這三個維度我們可以對HBase中的資料進行快速定位。下面我們主要來討論RowKey的設計原則：

HBase中RowKey可以唯一標識一條記錄，在HBase查詢的時候，我們有兩種方式，第一種是通過get()方法指定RowKey條件後獲取唯一一條記錄，第二種方式是通過scan()方法設定諸如startRow和endRow的引數進行範圍匹配查詢。所以說RowKey的設計至關重要，嚴重影響著查詢的效率， RowKey的設計 主要是遵循以下幾個原則：

1)、RowKey長度原則：RowKey是一個二進位制碼流，可以是任意字串，最大長度為64KB，實際應用中一般為10~100bytes，存為byte[]位元組陣列，一般設計成定長。建議是越短越好，不要超過16個位元組。原因一是資料的持久化檔案HFile中是按照KeyValue儲存的，如果RowKey過長比如100位元組，1000萬列資料光RowKey就要佔用100*1000萬=10億個位元組，將近1G資料，這會極大影響HFile的儲存效率；原因二是memstore將快取部分資料到記憶體，如果RowKey欄位過長記憶體的有效利用率會降低，系統將無法快取更多的資料，這會降低檢索效率。因此RowKey的位元組長度越短越好原因三是目前作業系統大都是64位，記憶體8位元組對齊。控制在16個位元組，8位元組的整數倍利用作業系統的最佳特性。

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

3)、RowKey唯一原則：必須在設計上保證其唯一性。

RowKey是按照字典排序儲存的，因此，設計RowKey時候，要充分利用這個排序特點，將經常一起讀取的資料儲存到一塊，將最近可能會被訪問的資料放在一塊。

舉個例子：如果最近寫入HBase表中的資料是最可能被訪問的，可以考慮將時間戳作為RowKey的一部分，由於是欄位排序，所以可以使用Long.MAX_VALUE-timeStamp作為RowKey，這樣能保證新寫入的資料在讀取時可以別快速命中。

案例分析：

使用者訂單列表查詢RowKey設計。

需求場景

某使用者根據查詢條件查詢歷史訂單列表

查詢條件

開始結束時間(orderTime)—–必選,

訂單號(seriaNum),

狀態(status)，遊戲號(gameID)

結果顯示要求

結果按照時間倒敘排列。

解答

RowKey可以設計為：userNumorderTimeseriaNum

注：這樣設計已經可以唯一標識一條記錄了，訂單詳情都是可以根據訂單號seriaNum來確定。在模糊匹配查詢的時候startRow和endRow只需要設定到userNum$orderTime即可，如下：

startRow=userNum$maxvalue-stopTime

endRow=userNum$maxvalue-startTime

其他欄位用filter實現。