HBase RowKey設計原則

對於關係型資料庫，資料定位可以理解為「二維座標」；但是hbase中需要四維來定位乙個單元格，即[行健、列族、列限定符、時間戳]

hbase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行訪問在臨近位置，便於scan。然而糟糕的rowkey設計是熱點的源頭。 熱點發生在大量的client直接訪問集群的乙個或極少數個節點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起效能下降甚至region不可用，這也會影響同乙個regionserver上的其他region，由於主機無法服務其他region的請求。 設計良好的資料訪問模式以使集群被充分，均衡的利用。

3.1 rowkey長度原則

rowkey是乙個二進位製碼流，可以是任意字串，最大長度 64kb ，實際應用中一般為10-100bytes，以 byte 形式儲存，一般設計成定長。建議越短越好，不要超過16個位元組，原因如下：

3.2 rowkey雜湊原則

如果rowkey按照時間戳的方式遞增，不要將時間放在二進位製碼的前面，建議將rowkey的高位作為雜湊字段，由程式隨機生成，低位放時間字段，這樣將提高資料均衡分布在每個regionserver，以實現負載均衡的機率。如果沒有雜湊字段，首字段直接是時間資訊，所有的資料都會集中在乙個regionserver上，這樣在資料檢索的時候負載會集中在個別的regionserver上，造成熱點問題，會降低查詢效率。具體方式有以下幾種

salting 散布

在rowkey的前面增加隨機數，具體就是給rowkey分配乙個隨機字首以使得它和之前的rowkey的開頭不同。分配的字首種類數量應該和你想使用資料分散到不同的region的數量一致。雜湊之後的rowkey就會根據隨機生成的字首分散到各個region上，以避免熱點。

雜湊會使同一行永遠用乙個字首雜湊。雜湊也可以使負載分散到整個集群，但是讀卻是可以**的。使用確定的雜湊可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某乙個行資料

反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。（例如手機號）

反轉rowkey的例子以手機號為rowkey，可以將手機號反轉後的字串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題

（舉例：寫資料時行健是1到1萬，這種情況如果不雜湊，就會出現寫熱點，總是往儲存最大行健的region裡寫入資料，十分影響效能。）

rowkey是按照字典順序排序儲存的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料儲存到一塊，將最近可能會被訪問的資料放到一塊。

乙個常見的資料處理問題是快速獲取資料的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用long.max_value-timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為hbase中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，那麼這種設計可以很好的支援以下的場景 難以支援的場...

HBase使用 HBase rowkey設計原則

針對這兩種方式，在第五項中，我們簡要介紹了幾種常見的rowkey設計思路 充分利用hbase的分布式特性，將請求分散到不同region上 十進位制字串表達 id反轉 二進位制 高階用法，傳說中的 x00 大量訪問會使熱點region所在的單個機器超出自身承受能力，引起效能下降甚至region不可用 ...