HBase行鍵設計

唯一原則：行鍵對應關係型資料庫的唯一鍵，系統設計之初必須考慮有足夠的唯一行鍵去支援業務的資料量。

長度原則：長度適中，一般從幾十到一百位元組，建議使用定長，方便從行鍵提取所需資料，而無須查詢出資料內容以節省網路開銷。

雜湊原則：避免遞增，否則讀寫負載都會集中在某個熱點分割槽，降低效能，甚至引起分割槽伺服器過載而宕機。

由於hbase不支援二級索引，所以hbase行鍵作為唯一的也是最有效的索引，需要盡可能多的糅合各種查詢條件以提高查詢效率，常見的設計技巧有：

反轉補齊：對於用來儲存實體資料的表，通常將實體id（如使用者id）反轉補齊位數後作為行鍵的開始，這樣首先滿足了對該實體資料查詢的需求，同時由於反轉了實體id，所以最近產生的實體以及其資料不會落到同乙個region，避免了熱點區間的產生。

使用geohash：geohash演算法可以用來將多維資料對映為一維字串，尤其是基於空間的經緯度資料，空間上靠近的經緯度點對映後的一維字串在字典順序上也靠近（當然會有特殊的臨界問題）。

opentsdb：opentsdb是基於hbase的乙個儲存時序資料的資料庫應用，通常用來儲存一些系統的監控資料或者系統日誌，opentsdb的行鍵設計類似對hbase的行鍵做了乙個二次索引，格式為：

uid___matric___+timebase+uid___tag1key___+uid___tag1value___+uid___tag2key___+uid___tag2value___+uid___tagnkey___+uid___tagnvalue___

其行鍵設計會將所有的監控指標或者需要查詢的業務標籤均對映到乙個等長的uid，然後將監控指標的uid作為行鍵的開始，這樣設計有幾個好處：

因為通常查詢監控資料的時候都會選定乙個監控指標（如cpu、記憶體等），這樣相同監控指標的資料會相鄰儲存，提供查詢效率。

將監控指標對映為等長的uid可以減少行鍵的長度與重複度，減少儲存空間，同時可以方便的從行鍵根據偏移量反向推演出監控指標。