摘要
最近做的一個項目涉及到了多條件的組合查詢，數據存儲用的是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
其查詢步驟如下：
-
首先根據查詢條件來確定索引名，根據其查詢條件為出游天數據 酒店等級確定索引名為aaa,這樣就將查詢的范圍縮小在索引名為aaa的索引數據區內
-
根據出游天數的值為3天，酒店等級的值為4，結合Phoenix的模糊查詢就能確定符合這兩個查詢條件的索引數據的行鍵
-
得到索引數據行鍵后就截取其最后的RowKey
-
最關鍵的Rowkey得到后就能輕易的獲得其對應的列值了，整個查詢過程就結束了。
對於其他更為復雜的組合查詢的二級索引設計如類似。
缺點
需要額外的存儲空間，屬 一種以空間換時間的方式。
注意
1.將查詢條件中的可選字段轉換成數字能節省存儲空間，如交通工具中的飛機，高鐵，火車，輪船，汽車分別轉換成5,4,3,2,1
2.將漢字轉換成拼音才能保證數據按HBase的排序規則排序
3.如果數據量在百萬級別以下可使用Phoenix(HBase的SQL查詢引擎)模糊查詢功能減少索引行鍵的設計
參考資料