为什么要检索增强
大量业务数据迁移到HBase存储，开始查询设计符合业务需求的Rowkey，比如从关系数据库迁移过来，有些数据关系通过反规范化设计，使得整体查询在HBase中能符合Rowkey高效查询⽅方式.
HBase 无法满足的查询
- 模糊查询。
- 任意条件的And/Or组合查询
- 空值查询
- 分组查询
- 分词检索
- 等等。。。。
HBase既然有这么多缺陷，我们能否解决这些问题呢？
HBase 检索增强方法
自建HBase索引（客户端实现双写）
主表一个rowkey，只能设计一个rowkey=X|Y …这种场景
适用场景
- X=a
- X>=a, X>a
- X<=a,或者X<a
- X=a and Y = b
- X=a and Y <= b
- X=a and Y>=b
优点
- 高并发、高效快速
缺点
- 只有一个rowkey设计，后期业务变化不不能修改rowkey结构
- 检索场景简单，有局限性，一个rowkey必须由前缀X出现才能快速查找，比如上述 只提供Y=b的话，依然需要全表扫描
Phoenix（第三方工具）
Phoenix/自建HBase索引扩展更多rowkey设计，允许更多 rowkey=X|Y， rowkey=Y|Z， rowkey=X|Z 。。。这种设计
适用场景
一个表，允许更多类似左边的场景。更多X、Y、Z…条件来组合来进行类似左边描述的条件查询
优点
依然保持高并发、高效rowkey查询。允许有更多rowkey设计，最大化HBase rowkey检索优势，支持JDBC和更好的贴近业务
缺点
- 表变多，如果业务有U/V/W/X/Y/Z 6个条件两两组合的业务场景，就需要15个表，数据膨胀，例如这个时候，X在索引里被保存了了5次。
- 引入第三方工具，工具越多，稳定性越差
- 查询也有局限性，无法模糊查询
Elasticsearch（双写或者使用CP）
任意条件 X、Y、Z…..
适用场景
- X = a or Y= b (rowkey设计不能实现的)
- X> a and Y < b (rowkey设计不能实现的)
- X like “%HBase%”
- Geo地理理距离检索
- 支持分词查询
- 支持facet/group分类分组查询返回，例如一个关键词搜索新闻网站，它可以分政治、体育、经济等类别返回统计与结果
- 任意条件组合查询等
优点
- 支持检索功能更丰富； OR 组合查询，多个条件范围组合查询，like、分词等全文检索，这些查询使⽤用HBase rowkey设计是难以满足的
- 对于类似U/V/W/X/Y/Z 6个条件两两组合的业务场景,数据膨胀率远低于HBase的rowkey⽅方案
缺点
- 类似HBase这种简单kv查询下，并发不 如HBase高效快速
Solr（可以使用第三方lily indexer）
Solr和ES类似，不过如果你是采用CDH搭建的IDC，可以直接用自带的同步工具lily indexer
其他DB保存索引
Mysql/Oracle/Redis/等等。。。各有各的优势。。还是需要看业务场景。
总结
增强HBase的检索能力可以有效弥补HBase的短板，使用合适的检索增强方式可以事半功倍。
