最近进行的项目包含多条件组合查询。 数据存储使用了HBase。 正是HBase没有特别致力于这种场景的查询。 一般的HBase查询是RowKey (显然无法将多条件组合查询的字段连接到RowKey上)，或者将所有表扫描和过滤器组合起来过滤目标数据，所以是HBase的2

需求查询

多个查询条件构成多维组合查询，需要通过组合来查询符合查询条件的数据

HBase的局限性

HBase本身只提供基于行键和全表扫描的查询，但行键索引单一，多维查询困难，例如价格天数酒店交通多条件组合查询困难，全表扫描效率低下。

二级索引的设计

设计思路

级别2索引的本质是在列值和行键之间建立映射关系

例如，如图1所示，在F:C1的列中创建索引的情况下，只需要创建F:C1的各列值和与其对应的行键的映射关系，例如C11-RK1等，就对应于f3360c1的列值从C1=C11中查找与索引数据相对应的RK，查询得到与其相对应的RK=RK1 2。 得到RK1后，可以自然地调查RK1到C2的值。 这是构建二级索引的大致思路，其他组合查询的集成索引的构建也是如此。

逻辑视图

(图2 )部分数据被收纳在HBase中的逻辑视图

表中有两个列族。 其中一个是列族索引，没有存储任何数据。 只是为了将索引数据与主数据分开保存。 索引数据的行密钥格式为RegionStartKey-索引名称-索引关键字-Rowkwy和其他RegionStartKey (因为HBase压缩并存储同一列系列的数据) 在创建HBase表时，由于表是根据起点预先分割的，因此关键字是包含主数据的列，可能是多列的值，而Rowkey对应于主数据的行关键字。 由于主数据的行键格式为出发地-目的地-性价比，因此在保存数据时，同一出发地目的地的数据默认按性价比排序。 由于索引数据的行键和主数据的行键的前缀是起点，因此在存储时同一起点的索引数据和主数据存储在同一区域中，因此在索引处得到RK后不会向其他区域询问目标数据

数据的查询过程

假设查询的条件：

出发点：澳门

目的地：杭州

旅行天数： 3天

酒店等级： 4

其查询步骤如下：

首先根据查询条件确定索引名，然后根据该查询条件为旅行日数据的酒店等级确定索引名为aaa。 由此，将查询的范围缩小到aaa这一索引数据区域，根据旅行日的值设为3天，根据酒店等级的值设为4天，通过与Phoenix的模糊查询进行组合，从而索引了满足这两个查询条件的索引数据的行键对于可以提取其最后一个RowKey最重要键的其他更复杂的组合查询，二级索引设计如下：

缺点

需要额外的存储空间，是在空间中改变时间的方法。

1 .将查询条件的可选字段转换为数字，可以节省飞机、高铁、列车、轮船、汽车等的存储空间。 分别转换为5、4、3、2、1

2 .将汉字转换为拼音，保证数据按照HBase的排序规则排序

3 .如果数据量小于或等于百万级，则使用基于h的SQL查询引擎(phoenix )模糊查询功能减少索引行密钥