hbase rowkey設計原則 和為什麼nosql查詢速度快
HBase RowKey
概述
HBase是一個分散式的、面向列的資料庫，它和一般關係型資料庫的最大區別是：HBase很適合於儲存非結構化的資料，還有就是它基於列的而不是基於行的模式。
既然HBase是採用KeyValue的列儲存，那Rowkey就是KeyValue的Key了，表示唯一一行。Rowkey也是一段二進位制碼流，最大長度為64KB，內容可以由使用的使用者自定義。資料載入時，一般也是根據Rowkey的二進位制序由小到大進行的。
HBase是根據Rowkey來進行檢索的，系統通過找到某個Rowkey (或者某個 Rowkey 範圍)所在的Region，然後將查詢資料的請求路由到該Region獲取資料。HBase的檢索支援3種方式：
- 通過單個Rowkey訪問，即按照某個Rowkey鍵值進行get操作，這樣獲取唯一一條記錄；
- 通過Rowkey的range進行scan，即通過設定startRowKey和endRowKey，在這個範圍內進行掃描。這樣可以按指定的條件獲取一批記錄；
- 全表掃描，即直接掃描整張表中所有行記錄。
HBASE按單個Rowkey檢索的效率是很高的，耗時在1毫秒以下，每秒鐘可獲取1000~2000條記錄，不過非key列的查詢很慢。
HBase的RowKey設計
設計原則
Rowkey長度原則
Rowkey是一個二進位制碼流，Rowkey的長度被很多開發者建議說設計在10~100個位元組，不過建議是越短越好，不要超過16個位元組。
原因如下：
- 資料的持久化檔案HFile中是按照KeyValue儲存的，如果Rowkey過長比如100個位元組，1000萬列資料光Rowkey就要佔用100*1000萬=10億個位元組，將近1G資料，這會極大影響HFile的儲存效率；
- MemStore將快取部分資料到記憶體，如果Rowkey欄位過長記憶體的有效利用率會降低，系統將無法快取更多的資料，這會降低檢索效率。因此Rowkey的位元組長度越短越好。
- 目前作業系統是都是64位系統，記憶體8位元組對齊。控制在16個位元組，8位元組的整數倍利用作業系統的最佳特性。
Rowkey雜湊原則
如果Rowkey是按時間戳的方式遞增，不要將時間放在二進位制碼的前面，建議將Rowkey的高位作為雜湊欄位，由程式迴圈生成，低位放時間欄位，這樣將提高資料均衡分佈在每個Regionserver實現負載均衡的機率。如果沒有雜湊欄位，首欄位直接是時間資訊將產生所有新資料都在一個RegionServer上堆積的熱點現象，這樣在做資料檢索的時候負載將會集中在個別RegionServer，降低查詢效率。（原因：在一天中的某個時間點只會訪問某個或某幾個RegionServer）
Rowkey唯一原則
必須在設計上保證其唯一性。
場景應用
比如根據userID以及時間、業務ID、業務型別作為一個RowKey。
設計RowKey的時候，將userID放在前面，依次為時間、業務ID、業務型別。
為什麼將userID放前面，是因為雜湊均勻，不會形成資料熱點。時間的話，可以用long.maxValue-time，為什麼這樣，因為這樣可以按時間倒序訪問，符合我們的習慣。其他的兩個欄位是唯一性的需要以精準定位（可以有可以沒有，只要能唯一定位既可以）。
下面說說為什麼hbase等Nosql的查詢速度那麼快呢？
1，hbase的按列儲存的，rowkey是有序排列的，按區劃分rowkey的
2，有一部分資料是放在memstore記憶體中的，讀取會快點