在實際的設計中我們可能更多的是結合多種設計方法來實現rowkey的最優化設計，比如設計訂單狀態表時使用：rowkey: reverse(order_id) + (long.max_value – timestamp)。
這樣設計的好處：
一是通過reverse訂單號避免region熱點，
二是可以按時間倒排顯示。
這樣設計的好處是：
設計加鹽的目的是為了增加查詢的併發性，假如salt的範圍是0~n，那我們在查詢的時候，可以將資料分為n個split同時做scan操作。經過我們的多次測試驗證，增加併發度能夠將整體的查詢速度提公升5～20倍以上。隨後的eventid和date是用來做範圍scan使用的。在我們的查詢場景中，大部分都是指定了eventid的，因此我們把eventid放在了第二個位置上，同時呢，eventid的取值有幾十個，通過salt + eventid的方式可以保證不會形成熱點。在單機部署版本中，hbase會儲存所有的event資料，所以我們把date放在rowkey的第三個位置上以實現按date做scan，批量scan效能甚至可以做到毫秒級返回。
這樣的rowkey設計能夠很好的支援如下幾個查詢場景：
(可以根據rowkey模糊查詢)
1、全表scan
在這種情況下，我們仍然可以將全表資料切分成n份併發查詢，從而實現查詢的實時響應。
2、只按照event_id查詢
3、按照event_id和date查詢最後我們順帶提下hbase的表設計，hbase表設計通常可以是寬表（wide table）模式，即一行包括很多列。同樣的資訊也可以用高表（tall table）形式儲存，通常高表的效能比寬表要高出 50%以上，所以推薦大家使用高表來完成表設計。表設計時，我們也應該要考慮hbase資料庫的一些特性：
1、在hbase表中是通過rowkey的字典序來進行資料排序的
2、所有儲存在hbase表中的資料都是二進位制的位元組
3、原子性只在行內保證，hbase不支援跨行事務
4、列族(column family)在表建立之前就要定義好
5. 列族中的列標識(column qualifier)可以在表建立完以後動態插入資料時新增
在做rowkey設計時，請先考慮業務是讀比寫多、還是讀比寫少，hbase本身是為寫優化的，即便是這樣，也可能會出現熱點問題，而如果我們讀比較多的話，除了考慮以上rowkey設計原則外，還可以考慮hbase的coprocessor甚至elastic search結合的方法，無論哪種方式，都建議做實際業務場景下資料的壓力測試以得到最優結果。
HBase RowKey設計原則
對於關係型資料庫，資料定位可以理解為 二維座標 但是hbase中需要四維來定位乙個單元格，即 行健 列族 列限定符 時間戳 hbase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行訪問在臨近位置，便於scan。然而糟糕的rowkey設計是熱點...
HBase Rowkey 設計指南
文章目錄 2 rowkey設計技巧 3 rowkey 設計案例剖析 我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。那麼 rowkey 到底是什麼？rowkey 的特點如下 如果我們的 rowkey 設計為 uid ph...
HBase Rowkey 設計指南
我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。那麼 rowkey 到底是什麼？rowkey 的特點如下 如果我們的 rowkey 設計為 uid phone name，那麼這種設計可以很好的支援以下的場景 難以支援的場...