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

查詢需求

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

HBase的局限性

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

二級索引的設計

設計思路

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

如(圖1)，當要對F:C1這列建立索引時，只需要建立F:C1各列值到其對應行鍵的映射關系，如C11->RK1等，這樣就完成了對F:C1列值的二級索引的構建，當要查詢符合F:C1=C11對應的F:C2的列值時(即根據(jù)C1=C11來查詢C2的值,圖1青色部分)其查詢步驟如下： 1. 根據(jù)C1=C11到索引數(shù)據(jù)中查找其對應的RK，查詢得到其對應的RK=RK1 2. 得到RK1后就自然能根據(jù)RK1來查詢C2的值了 這是構建二級索引大概思路，其他組合查詢的聯(lián)合索引的建立也類似。

邏輯視圖

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

表中有兩個列族，其中一個是列族INDEX，其并不存儲任何的數(shù)據(jù)，僅僅是為了將索引數(shù)據(jù)與主數(shù)據(jù)分開存儲(因為在HBase中同一列族的數(shù)據(jù)會被壓縮在一起存儲)，索引數(shù)據(jù)的行鍵格式為：RegionStartKey-索引名-索引鍵-Rowkwy,其他RegionStartKey就是出發(fā)點，因為在創(chuàng)建HBase表時就對表根據(jù)出發(fā)點進行了預分區(qū)，索引鍵為主數(shù)據(jù)中某列(可能是多列)的列值，Rowkey對應主數(shù)據(jù)的行鍵;主數(shù)據(jù)的行鍵格式為：出發(fā)點-目的地-性價比，所以在存儲數(shù)據(jù)時，同一出發(fā)點 目的地的數(shù)據(jù)默認是按性價比排序的;索引數(shù)據(jù)的行鍵和主數(shù)據(jù)的行鍵的前綴都是出發(fā)點，所以在存儲時相同出發(fā)點的索引數(shù)據(jù)和主數(shù)據(jù)是存儲在同一個Region中的，這樣避免了在通過索引得到RK后又去其他Region上查詢目標數(shù)據(jù)，提高了查詢效率。

數(shù)據(jù)的查詢過程

假設查詢的條件：

• 出發(fā)點：澳門
• 目的地：杭州
• 出游天數(shù)：3天
• 酒店等級：4

其查詢步驟如下：

• 首先根據(jù)查詢條件來確定索引名，根據(jù)其查詢條件為出游天數(shù)據(jù) 酒店等級確定索引名為aaa,這樣就將查詢的范圍縮小在索引名為aaa的索引數(shù)據(jù)區(qū)內
• 根據(jù)出游天數(shù)的值為3天，酒店等級的值為4，結合Phoenix的模糊查詢就能確定符合這兩個查詢條件的索引數(shù)據(jù)的行鍵
• 得到索引數(shù)據(jù)行鍵后就截取其最后的RowKey
• 最關鍵的Rowkey得到后就能輕易的獲得其對應的列值了，整個查詢過程就結束了。

對于其他更為復雜的組合查詢的二級索引設計如類似。

缺點

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

1. 將查詢條件中的可選字段轉換成數(shù)字能節(jié)省存儲空間，如交通工具中的飛機，高鐵，火車，輪船，汽車分別轉換成5,4,3,2,1
2. 將漢字轉換成拼音才能保證數(shù)據(jù)按HBase的排序規(guī)則排序
3. 如果數(shù)據(jù)量在百萬級別以下可使用Phoenix(HBase的SQL查詢引擎)模糊查詢功能減少索引行鍵的設計