當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路、**交易或者乙個監控系統。它們顯著的特點就是
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熱點問題
當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是rowkey中含有事件發生時間。帶來的乙個問題便是hbase對於row的不均衡分布，它們被儲存在乙個唯一的rowkey區間中，被稱為region，區間的範圍被稱為start k...
Hbase熱點問題
需求描述 掃瞄 查詢 某個區間 列用hbase多節點的資源，分布式掃瞄，加快速度 然後拼接到一起 如何打散資料 冠字型大小逆序，hash 並不一定資料連續就會造成熱點，這個是由資料訪問模式決定的。ex 時間作為rowkey，但查詢經常按乙個時間段來查詢 時間作為rowkey會造成時間差不多的在乙個r...
redis熱點問題
請求分片集中，超過單 server 的效能極限。在服務端讀資料進行訪問時，往往會對資料進行分片切分，此過程中會在某一主機 server 上對相應的 key 進行訪問，當訪問超過 server 極限時，就會導致熱點 key 問題的產生。需要避免失效那一刻大量請求同時去重新構建快取。因為重新構建快取，需...