當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路、**交易或者乙個監控系統。它們顯著的特點就是rowkey中含有事件發生時間。帶來的乙個問題便是hbase對於row的不均衡分布，它們被儲存在乙個唯一的rowkey區間中，被稱為region，區間的範圍被稱為start key和end key。
對於單調遞增的時間型別資料，很容易被雜湊到同乙個region中，這樣它們會被儲存在同乙個伺服器上，從而所有的訪問和更新操作都會集中到這一台伺服器上，從而在集群中形成乙個hot spot，從而不能將集群的整體效能發揮出來。
要解決這個問題是非常容易的，只需要將所有的資料雜湊到全部的region上即可。這是可以做到的，比如，在rowkey前面加上乙個非執行緒序列，常常有如下選擇：
hash雜湊
您可以使用乙個hash字首來保證所有的行被分發到多個region伺服器上。例如：
byte prefix =
(byte) (long.hashcode(timestamp) % );
byte rowkey =
bytes.add(bytes.tobytes(prefix), bytes.tobytes(timestamp);
這個公式可以產生足夠的數字，將資料雜湊到所有的region伺服器上。當然，公式裡假定了region伺服器的數目。如果您打算後期擴容您的集群，那麼您可以把它先設定為集群的整數倍。生成的rowkey類似下面：
0myrowkey-1,
1myrowkey-2, 2myrowkey-3, 0myrowkey-4, 1myrowkey-5, \
2myrowkey-6, …
當他們將按如下順序被傳送到各個region伺服器上去：
0myrowkey-1
0myrowkey-4
1myrowkey-2
1myrowkey-5
…換句話說，對於0myrowkey-1和0myrowkey-4的更新操作會被傳送到同乙個region伺服器上去（假定它們沒有被雜湊到兩個region上去），1myrowkey-2和1myrowkey-5會被傳送到同一臺伺服器上。
這種方式的缺點是，rowkey的範圍必須通過**來控制，同時對資料的訪問，可能要訪問多台region伺服器。當然，可以通過多個執行緒同時訪問，來實現並行化的資料讀取。這種類似於只有map的mapreduce任務，可以大大增加io的效能。
Hbase熱點問題
需求描述 掃瞄 查詢 某個區間 列用hbase多節點的資源，分布式掃瞄，加快速度 然後拼接到一起 如何打散資料 冠字型大小逆序，hash 並不一定資料連續就會造成熱點，這個是由資料訪問模式決定的。ex 時間作為rowkey，但查詢經常按乙個時間段來查詢 時間作為rowkey會造成時間差不多的在乙個r...
Hbase rowkey熱點問題
當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是 rowkey 中含有事件發生時間。帶來的乙個問題便是 hbase 對於row 的不均衡分布，它們被儲存在乙個唯一的 rowkey 區間中，被稱為 region 區間的範圍被稱...
redis熱點問題
請求分片集中，超過單 server 的效能極限。在服務端讀資料進行訪問時，往往會對資料進行分片切分，此過程中會在某一主機 server 上對相應的 key 進行訪問，當訪問超過 server 極限時，就會導致熱點 key 問題的產生。需要避免失效那一刻大量請求同時去重新構建快取。因為重新構建快取，需...