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

查詢需求

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

HBase的局限性

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

二級索引的設計

設計思路

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

如(圖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查詢引擎)模糊查詢功能減少索引行鍵的設計