1. 程式人生 > >HBase RowKey設計原則(全面)

HBase RowKey設計原則(全面)

這段時間實在太忙了,工作和備考幾乎用盡了所有時間,以前的愛好都漸漸遠離了,現在也就更新部落格這個小喜好了,每天看到日益增長的訪問量還是挺開心的,能幫到別人也是一種快樂。這篇HBase的行健設計原則文章主要依據HBase官方文件和一些相關文章總結而來,可以說是比較靠譜和全面的一個rowkey設計總結。 言歸正傳,對於關係型資料庫,資料定位可以理解為“二維座標”;但是hbase中需要四維來定位一個單元格,即[行健、列族、列限定符、時間戳]

    HBase中rowkey可以唯一標識一行記錄,在HBase查詢的時候,有以下幾種方式:

  1.  通過get方式,指定rowkey獲取唯一一條記錄
  2.  通過scan方式,設定startRow和stopRow引數進行範圍匹配
  3.  全表掃描,即直接掃描整張表中所有行記錄

什麼是熱點?

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

RowKey的設計原則
1. RowKey長度原則 RowKey是一個二進位制碼流,可以是任意字串,最大長度 64kb ,實際應用中一般為10-100bytes,以 byte[] 形式儲存,一般設計成定長。建議越短越好,不要超過16個位元組,原因如下:
  1.    資料的持久化檔案HFile中是按照KeyValue儲存的,如果rowkey過長,比如超過100位元組,1000w行資料,光rowkey就要佔用100*1000w=10億個位元組,將近1G資料,這樣會極大影響HFile的儲存效率;
  2.    MemStore將快取部分資料到記憶體,如果rowkey欄位過長,記憶體的有效利用率就會降低,系統不能快取更多的資料,這樣會降低檢索效率。
  3.    目前作業系統都是64位系統,記憶體8位元組對齊,控制在16個位元組,8位元組的整數倍利用了作業系統的最佳特性。
  4.    其他的如列族名、列名等屬性名也是越短越好。value永遠和它的key一起傳輸的。當具體的值在系統間傳輸時,它的rowkey,列名,時間戳也會一起傳輸。如果你的rowkey和列名和值相比較很大,那麼你將會遇到一些有趣的問題。Hfile中的索引最終佔據了HBase分配的大量記憶體。
2.rowkey雜湊原則 如果rowkey按照時間戳的方式遞增,不要將時間放在二進位制碼的前面,建議將rowkey的高位作為雜湊欄位,由程式隨機生成,低位放時間欄位,這樣將提高資料均衡分佈在每個RegionServer,以實現負載均衡的機率。如果沒有雜湊欄位,首欄位直接是時間資訊,所有的資料都會集中在一個RegionServer上,這樣在資料檢索的時候負載會集中在個別的RegionServer上,造成熱點問題,會降低查詢效率。具體方式有以下幾種 Salting 散佈 在rowkey的前面增加隨機數,具體就是給rowkey分配一個隨機字首以使得它和之前的rowkey的開頭不同。分配的字首種類數量應該和你想使用資料分散到不同的region的數量一致。雜湊之後的rowkey就會根據隨機生成的字首分散到各個region上,以避免熱點。 Hashing 雜湊 雜湊會使同一行永遠用一個字首雜湊。雜湊也可以使負載分散到整個叢集,但是讀卻是可以預測的。使用確定的雜湊可以讓客戶端重構完整的rowkey,可以使用get操作準確獲取某一個行資料 RowKey Reverse 行健反轉 反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分(最沒有意義的部分)放在前面。這樣可以有效的隨機rowkey,但是犧牲了rowkey的有序性。(例如手機號) 反轉rowkey的例子以手機號為rowkey,可以將手機號反轉後的字串作為rowkey,這樣的就避免了以手機號那樣比較固定開頭導致熱點問題 (舉例:寫資料時行健是1到1萬,這種情況如果不雜湊,就會出現寫熱點,總是往儲存最大行健的Region裡寫入資料,十分影響效能。) 3.時間戳反轉 Reversiong the Key rowkey是按照字典順序排序儲存的,因此,設計rowkey的時候,要充分利用這個排序的特點,將經常讀取的資料儲存到一塊,將最近可能會被訪問的資料放到一塊。 一個常見的資料處理問題是快速獲取資料的最近版本,使用反轉的時間戳作為rowkey的一部分對這個問題十分有用,可以用Long.Max_Value-timestamp 追加到key的末尾,例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄,因為HBase中rowkey是有序的,第一條記錄是最後錄入的資料。 (由於這一項是違背雜湊原則的,有可能引起熱點,所以要根據具體情境來看是否適合使用這種方法。大多數情境還是以行健雜湊為主。)
4. rowkey唯一原則 必須在設計上保證其唯一性。

相關推薦

HBase RowKey設計原則全面

這段時間實在太忙了,工作和備考幾乎用盡了所有時間,以前的愛好都漸漸遠離了,現在也就更新部落格這個小喜好了,每天看到日益增長的訪問量還是挺開心的,能幫到別人也是一種快樂。這篇HBase的行健設計原則文

設計模式之設計原則

擴展 原因 依賴 設計原則 細節 面向接口 編程 面向 size 一:   單一職責原則:就一個類而言,應該只有一個引起它變化的原因。 二:   開閉原則:軟件實體對擴展開放,對修改關閉。 三:   裏式代換原則:子類型必須能夠替換掉它們的父類型。 四:   依賴倒轉原則:

設計模式之設計原則

font 通過 size 模式 span 通信 轉發 設計模式 其他 五:   接口分離原則:不應該強迫程序依賴它們不需要使用的方法。即,一個接口不需要提供太多的行為,一個接口應該只提供一種對外的功能,不應該把所有的操作都封裝到一個接口中。 六:   迪米特原則:一個對象應

第2章 面向物件的設計原則SOLID:6_開閉原則

6. 開閉原則(Open Closed Principle,OCP) 6.1 定義 (1)一個類應該對擴充套件開放,對修改關閉。要求通過擴充套件來實現變化,而且是在不修改己有的程式碼情況下進行擴充套件,也不必改動己有的原始碼或二進位制程式碼。 (2)在軟體生命週期內,變化是一個既定的事實

第2章 面向物件的設計原則SOLID:5_迪米特法則

5. 迪米特法則(Law of Demeter,LoD) 5.1 定義 (1)應儘量減少其他物件之間的互動,物件只和自己的朋友交談,即對其他依賴的類越少越好(不要和太多的類發生關係)。 (2)儘量不要讓類和類之間建立直接的關係,這樣可減少類與類之間的依賴,降低類之間的耦合。 (3)一

第2章 面向物件的設計原則SOLID:4_介面隔離原則ISP

4. 介面隔離原則(Interface Segregation Principle,ISP) 4.1 定義 (1)使用多個專門的介面,而不使用單一的總介面,即客戶端不應該依賴那些它不需要的介面。類間的依賴關係應該建立在最小介面上 (2)介面儘量細化,同時介面中的方法儘量少。每個介面中只包

第2章 面向物件的設計原則SOLID:3_依賴倒置原則DIP

3. 依賴倒置原則(Dependence Inversion Principle,DIP) 3.1 定義 (1)要依賴抽象,不要依賴具體的實現類。簡單的說就是對抽象(或介面)進行程式設計,不要依賴實現進行程式設計,這樣就降低了客戶與實現模組間的耦合。包含3層含義:   ①高層模組不應依賴

第2章 面向物件的設計原則SOLID:2_里氏替換原則LSP

2. 里氏替換原則(Liskov Substitution Principle,LSP) 2.1 定義 (1)所有使用基類的地方必須能透明地使用子類替換,而程式的行為沒有任何變化(不會產生執行結果錯誤或異常)。只有這樣,父類才能被真正複用,而且子類也能夠在父類的基礎上增加新的行為。也只有這樣

第2章 面向物件的設計原則SOLID:1_單一職責原則SRP

1. 單一職責原則(Single Responsibility Principle,SRP) 1.1 單一職責的定義 (1)定義:一個類應該僅有一個引起它變化的原因。這裡變化的原因就是所說的“職責”。 (2)如果一個類有多個引起它變化的原因,也就意味著這個類有多個職責。即把多個職責耦合在

大話設計模式C++實現-第3.4.5-設計原則1

第三章-單一職責原則 (1).就一個類而言,應該僅有一個引起它變化的原因。 (2)如果一個類承擔的職責過多,就等於把這些職責耦合在了一起,一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當發生變化時,設計會遭受到意想不到的破壞。 (3)軟體設計真正要做

23中設計模式概括及六種設計原則

一、設計模式分類 總體來說模式依據目的可分為建立型模式(Creational)、結構型模式(Structural)、行為型模式(Behavioral)三種。 建立型模式:處理物件的建立。共5種:工廠方法模式(Factory Method)、抽象工廠模式(Abstract Factory)、建造者模式(Bu

五大設計原則SOLID

一般情況下,我們為軟體構建中層架構的主要目標如下: ①使軟體可容忍被更改 ②使軟體更容易被理解 ③構建可在多個軟體系統中複用的元件   簡要介紹下SOLID原則:   一、 單一職責原則 該設計原則是基於康威定律的一個推論——一個軟體系統的最佳結構

Hbase Rowkey設計原則

長度越短越好   Rowkey是一個二進位制碼流,Rowkey的長度被很多開發者建議說設計在10~100個位元組,不過建議是越短越好,不要超過16個位元組。   原因如下:  (1)資料的持久化檔案HFile中是按照KeyValue儲存的,如果Row

(轉) 面向物件設計原則:開放-封閉原則OCP

原文:https://blog.csdn.net/tjiyu/article/details/57079927 面向物件設計原則(二):開放-封閉原則(OCP)        開放-封閉原則(Open-closed principle,OCP)也

以C/C++語法淺談六大設計原則——依賴倒置原則Dependence Inversion Principle

一. 前言 眾所周知,在軟體開發過程中,我們的六大設計原則與二十三種設計模式可以說是我們開發的思想精髓。然而,網上或者書本大多數的資料都是以java、python等其他語言語法進行介紹與闡述,很少有以C/C++的語法進行深入介紹。鑑於此,本人以淺薄的見識對這些精妙的思想做以總結,方便

商城資料庫設計原則-商品模型的設計

 在電商系統中,商品模型至關重要,是整個電商的核心,下面通過一個簡單的分析,設計一個基礎的商品模型。 商品模型的演化     在以前,那時CMS很流行,最常見的模型是欄目-文章模型。於是做電商的時候,自然就繼承了這種一對多的關係。只是欄目變成了分類,文章變成了商品。商

單一職責原則詳解--七大面向物件設計原則1

單一職責原則來源:         定義:單一職責就是一個類負責一項職責.就一個類而言,應該只專注於做一件事和僅有一個引起它變化的原因。         所謂職責,我們可以理解為功能,就是設計的這個類功能應該只有一個,而不是兩個或更多。也可以理解為引用變化的原因,當你

資料庫設計原則簡明

本文摘錄自http://blog.csdn.net/haiross/article/details/50427382  原文有更詳細講解。 正規化標準 知乎 https://www.zhihu.com/question/24696366 基本表及其欄位之間的關係,應儘量滿

hbase rowkey設計原則 和為什麼nosql查詢速度快

HBase RowKey 概述 HBase是一個分散式的、面向列的資料庫,它和一般關係型資料庫的最大區別是:HBase很適合於儲存非結構化的資料,還有就是它基於列的而不是基於行的模式。 既然HBase是採用KeyValue的列儲存,那Rowkey就是KeyValue的K

Hbase rowkey 設計原則

HBase是三維有序儲存的,三維指的是:RowKey(行健)、column key(columnFamily和qualifier)、TimeStamp(時間戳),通過這三個維度我們可以對HBase中的資料進行快速定位。下面我們主要來討論RowKey的設計原則: HBas