Hbase 進階使用方式

HBase有兩個基本的key結構, 一個是row key另一個是column key, 以下來看看如何靈活的運用這兩套key來解決一些常見的實務問題.

重要觀念回顧

邏輯配置不同於實體配置, 由於人類的大腦辨識2維資料強過辨識多維資料, 因此, 在設計資料庫這種複雜的關係時, 就習慣用[表]來顯示. 所以不管是關聯式資料庫還是HBase這種欄導向的資料庫, 在設計時都會畫張表出來. 在設計資料庫系統時, 也都有表的概念. 但是雖然看起來都是表, 這兩種資料庫在實際儲存資料時其實是採用完全不同的方法.

在此我粗略的把以下幾個關鍵字視為邏輯配置的關鍵字

• Table
• Row
• Column Family
• Column Qualifier

把以下幾個字視為實體配置時的關鍵字

• Region
• Region Server
• Cluster

請注意, 這裡的邏輯配置和實體配置的說法是為了方便理解, 並不嚴謹.

HBase的資料表邏輯配置 

      「HBase在邏輯配置上的主要切割單位是Column Family」,這句話是說, HBase在儲存資料時, 會以Column Family為單位儲存, 不同Column Family儲存在不同的檔案中.
以下圖為例, 這張資料表中有兩個 column family 1(cf1與cf2)之中各有兩個column qualify(c1與c2),
HBase在進行儲存時, 會把cf1:c1和cf1:c2合併成一個檔案, 把cf2:c1和cf2:c2合併成一個檔案, 這裡這個合併的動作稱為folded(中文書譯做「拌入」, 我覺得稱作「檔案化」比較貼切).
      上面提到的cf1:c1是由column family：column qualify的組合, 這個組合就是HBase中的Column key.

「列」是以實際儲存單元(actual cell)的線性集合(linear set)來儲存
引用自：HBase The Definitive Guide 

比較高窄型資料表與扁平型資料表

      在處理資料如何儲存與存到哪裡的問題時, 有兩種選擇. 高窄型(tall-narrow)與平寬型(flat-wide).高窄型的資料表有少量的行, 但有許多的列, 平寬型則正好相反.
      由於HBase只可以在列的邊界上做分割, 因此強烈建議使用高窄型資料表.
      舉電子郵件為例, 我們可以這樣設計：一個列裡存放一位使用者的所有郵件(row key為user id). 這樣會發生, 少數的使用者有超級多的電子郵件, 而令單一列有可能超過region所限制的最大檔案空間, 且面臨region的分割處理工作.
      想像一下比較好的處理方式是, 每一個單獨的列上, 改成存單一電子郵件, 也就是將row key 換成user id與message id的組合. 這樣一來就可以輕巧的避免掉上述的問題.

局部Key掃描（partial key scans）

      HBase的掃描(scan)功能和HTable為主的用戶端API, 對於將資料表轉換成高窄型而不喪失查詢的細緻度上, 提供了partial key scans的重要功能.
在上一段提到的電子郵件例子裡, 當我們把資料表透過row key的組合轉換成高窄型資料表時, 我們會得到一串由許多key組合而成的row key, 例如 <userid>-<msgid>-<attachid>, 而局部Key掃描讓我們可以設定, 要掃描row key中的哪些Key. 透過局部key掃描一方面可以提昇查詢的精準度, 一方面又可以減少不必要的查詢時間, 非常方便使用.

輔助索引

雖然HBase原來沒有支援輔助索引, 但還是有一些狀況會需要用到. 這些狀況通常是這樣：row key, column family, column qualify...這些主要的資料定位資訊不夠用, 這時候就會需要用到輔助索引. 這時可能的解決方案入下：

讓客戶端來管理
將索引功能直接轉移到應用程式層來處理.

索引交易
使用開放原碼專案 ITHBase. 這個專案擴充了 HBase的功能, 在客戶端與主機端的類別上加了一些特殊的實作. 核心的擴充是加入了交易機制, 用於確保所有輔助索引的更新是一致的。並藉由提供一個客戶端的IndexdTableDescriptor來增加對索引的支援, 定義了一個資料表背後的輔助索引運作方式.

索引式 HBase
類似ITHBase專案, 這裡也以採用IHBase(Indexed HBase). 此解決方案不使用獨立的資料表來儲存每個索引, 而是直接在記憶體中維護他們.