HBase中RowKey設計原則有哪些

這篇文章主要介紹了HBase中RowKey設計原則有哪些，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

首先看一下RowKey設計的3條原則

1、散列原則，不要用類似于時間戳這樣的數據直接作為RowKey，如果確實需要用時間戳，可以把它放在低位，高位用散列來占位。

2、長度原則，其實總結就一句話，rowkey只是一個唯一標識符，并沒有更多的實際意義，所以不要搞得太長，但是，我想說但是，如果我的rowkey是有意義的，那么讓他長一些是不是也可以呢？

3、唯一性原則，這一點沒什么好說的，RowKey需要唯一確定一條數據，所以必須唯一。

后面2條原則沒什么好說的，我們重點來看一下散列原則，為什么會有這樣的建議。

在HBase當中，表會被劃分為1...n個Region，被托管在RegionServer中。Region二個重要的屬性:StartKey與EndKey表示這個 Region維護的rowKey范圍，當我們要讀/寫數據時，如果rowKey落在某個start-end key范圍內，那么就會定位到目標region并且讀/寫到相關的數據。

如果我們在建表的時候，不預先設定好分區，隨著表內數據的增多，HBase會自動把表進行split，但是這樣做有幾點問題，第一，分區的原則，可能并不是我們想要的；第二，在表內數據相對較少的時候，無法充分展現分布式并發處理的優勢；第三，split操作，其實是比較耗資源的，如果數據增長過快，可能會相對頻繁的發生。

那么，預分區又是如何實現的，我們看下面這個語句：

create 'testtable', 'common', 'data', {SPLITS => ['1','2','3']}

建好之后，我們可以在HBase的web頁面當中，看到表的分區的分布情況：

我們看到，我們用1,2,3三個數，把一個table劃分為了4個region，這四個region分別是：

x<1,  1<=x<2,  2<=x<3,  3<=x

那么我們在insert的數據的時候，又該怎么做呢？看下面的scala代碼：

val p = new Put(Bytes.toBytes(String.valueOf(random.nextInt(4)) + new Date().getTime))

這句話是為一條新的數據，生成一個RowKey，那么我們的key值由2部分組成，隨機散列+時間戳，其中隨機散列包括：【0,1,2,3】一共4個值，根據上面我們劃分的region，這4個值，將會映射到4個不同的region當中。

好吧，剛才我們直接把一種比較好的解決方案告訴給大家了。

最初的時候，我可不是這么做的，當時我并不知道有預分區這回事，所以我僅僅是建了一個表，這種情況下，它只有一個分區。

create 'testtable', 'common', 'data'

然后我用下面的語句來生成RowKey。

val p = new Put(Bytes.toBytes(new Date().getTime))

這樣會發生什么事情？程序執行之后，持續不斷的往這個默認的region當中寫入數據，事實上也就只有一個regionserver來為我們服務，數據量大了之后，table終于發生了分裂，2個region了，可是情況并沒有任何好轉，因為我們的RowKey是不斷增大的，所以，按照HBase默認的分區原則，所有的新的數據，都被寫到了startkey最大的那個region當中。分布式的性能優勢完全無法體現。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“HBase中RowKey設計原則有哪些”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!