HBase二級索引的設計(案例講解)

摘要

最近作的一個項目涉及到了多條件的組合查 詢，數據存儲用的是HBase，偏偏HBase對於這種場景的查詢特別不給力，通常HBase的查詢都是經過RowKey(要把多條件組合查詢的字段都拼 接在RowKey中顯然不太可能)，或者全表掃描再結合過濾器篩選出目標數據(過低效)，因此經過設計HBase的二級索引來解決這個問題

查詢需求

多個查詢條件構成多維度的組合查詢，須要根據不一樣組合查詢出符合查詢條件的數據

HBase的侷限性

HBase自己只提供基於行鍵和全表掃描的查詢，而行鍵索引單一，對於多維度的查詢困難(如：對於價格+天數+酒店+交通的多條件組合查詢困難)，全表掃描效率低下。

二級索引的設計

設計思路

                               （圖1）設計思路

二級索引的本質就是創建各列值與行鍵之間的映射關係

如(圖1)，當要對F:C1這列創建索引時，只須要創建F:C1各列值到其對應行鍵 的映射關係，如C11->RK1等，這樣就完成了對F:C1列值的二級索引的構建，當要查詢符合F:C1=C11對應的F:C2的列值時（即根據 C1=C11來查詢C2的值,圖1青色部分）其查詢步驟以下： 1. 根據C1=C11到索引數據中查找其對應的RK，查詢獲得其對應的RK=RK1 2. 獲得RK1後就天然能根據RK1來查詢C2的值了 這是構建二級索引大概思路，其餘組合查詢的聯合索引的創建也相似。

邏輯視圖

                                            (圖2) 部分數據在HBase中存儲的邏輯視圖

表中有兩個列族，其中一個是列族 INDEX，其並不存儲任何的數據，僅僅是爲了將索引數據與主數據分開存儲（由於在HBase中同一列族的數據會被壓縮在一塊兒存儲），索引數據的行鍵格式 爲：RegionStartKey-索引名-索引鍵-Rowkwy,其餘RegionStartKey就是出發點，由於在建立HBase表時就對錶根據出 發點進行了預分區，索引鍵爲主數據中某列(多是多列)的列值，Rowkey對應主數據的行鍵；主數據的行鍵格式爲：出發點-目的地-性價比，因此在存儲 數據時，同一出發點 目的地的數據默認是按性價比排序的；索引數據的行鍵和主數據的行鍵的前綴都是出發點，因此在存儲時相同出發點的索引數據和主數據是存儲在同一個 Region中的，這樣避免了在經過索引獲得RK後又去其餘Region上查詢目標數據，提升了查詢效率。

數據的查詢過程

假設查詢的條件：

• 出發點：澳門

• 目的地：杭州

• 出遊天數：3天

• 酒店等級：4

其查詢步驟以下：

1. 首先根據查詢條件來肯定索引名，根據其查詢條件爲出遊天數據 酒店等級肯定索引名爲aaa,這樣就將查詢的範圍縮小在索引名爲aaa的索引數據區內

2. 根據出遊天數的值爲3天，酒店等級的值爲4，結合Phoenix的模糊查詢就能肯定符合這兩個查詢條件的索引數據的行鍵

3. 獲得索引數據行鍵後就截取其最後的RowKey

4. 最關鍵的Rowkey獲得後就能輕易的得到其對應的列值了，整個查詢過程就結束了。

對於其餘更爲複雜的組合查詢的二級索引設計如相似。

缺點

須要額外的存儲空間，屬 一種以空間換時間的方式。

 

注意

1.將查詢條件中的可選字段轉換成數字能節省存儲空間，如交通工具中的飛機，高鐵，火車，輪船，汽車分別轉換成5,4,3,2,1

2.將漢字轉換成拼音才能保證數據按HBase的排序規則排序

3.若是數據量在百萬級別如下可以使用Phoenix(HBase的SQL查詢引擎)模糊查詢功能減小索引行鍵的設計