HBase RowKey設計原則

本文引自淘寶技術部文章：http://rdc.taobao.org/?p=457

1. 建議使用String如果不是特殊要求，RowKey最好都是String。
   • 方便線上使用Shell查數據、排查錯誤
   • 更容易讓數據均勻分佈
   • 不必考慮存儲成本
2. RowKey的長度儘量短如果RowKey太長話，第一是，存儲開銷會增加，影響存儲效率；第二是，內存中Rowkey字段過長，內存的利用率會降低，這會降低索引命中率。

   一般的做法是：

   • 時間使用Long來表示
   • 儘量使用編碼壓縮
3. RowKey儘量散列RowKey的設計，最重要的是要保證散列，這樣就會保證所有的數據都不都是在一個region上，避免做讀寫的時候負載將會集中在個別region上面。

   假設我們需要存儲一個用戶的所有微博（暫時不需要考慮時間倒排），這時候的RowKey的設計是UserId_WeiboId ，但是這樣設計的話，UserId 的分佈就很可能不均勻，因爲RowKey是字符串排序的。（默認字典順序排序）

   有兩種辦法來解決這個問題

   • ReversesUserId字符串反轉後存儲
   • Hash或者ModUserIdMD5 後作取前6位爲前綴加入到 UserId 前面
4. RowKey排序假設我們有個很多微博用戶發微博，但是這個時候，我們要開闢一個“廣場”，所有的微博都是按照時間倒排序展示在這個“廣場”裏。這個時候我們就得爲原來的UserId_WeiboId建立一張索引表，並且這個表的Rowkey要和時間相關
   • Rowkey的設計可以使用當前時間 - 微博發表時間的 long 值作爲 RowKey 的前綴
   • RowKey散列
   • 如果數據可以定期清理如果數據不是需要一直保存的話，就算所有數據落在一個region，因爲按時間搜索會指定startRow，存儲時候Rowkey也是連續的，所以速度也非常塊，當然數據容量最好和DBA商量一下
   • 如果數據都需要保存把DayOfMonth作爲前綴

     那麼RowKey會是 DayOfMonth_(當前時間 - 微博發表時間)

     不過這樣在代碼實現上面的時候會有一些麻煩。

5. 關於事務目前HBase的Put，Delete操作都是事務的，但是如果您希望能夠對好幾個Table發起一連串操作並且希望是事務的話，目前還沒有好的辦法。所以HBase使用的時候，要有解決數據出錯的覺悟。