HBase的二级索引种类和设计( 二 ) _HBase

Apache Phoenix：功能围绕着SQL on hbase，支持和兼容多个hbase版本，二级索引只是其中一块功能。二级索引的创建和管理直接有SQL语法支持，使用起来很简便，该项目目前社区活跃度和版本更新迭代情况都比较好。

ApachePhoenix在目前开源的方案中，是一个比较优的选择。主打SQL on HBase，基于SQL能完成HBase的CRUD操作，支持JDBC协议。Apache Phoenix在Hadoop生态里面位置：

文章插图

Phoenix二级索引特点：

Covered Indexes(覆盖索引) ：把关注的数据字段也附在索引表上，只需要通过索引表就能返回所要查询的数据（列），所以索引的列必须包含所需查询的列(SELECT的列和WHRER的列) 。
Functional indexes(函数索引)：索引不局限于列，支持任意的表达式来创建索引。
Global indexes(全局索引)：适用于读多写少场景。通过维护全局索引表，所有的更新和写操作都会引起索引的更新，写入性能受到影响。在读数据时，Phoenix SQL会基于索引字段，执行快速查询。
Local indexes(本地索引)：适用于写多读少场景。在数据写入时，索引数据和表数据都会存储在本地。在数据读取时，由于无法预先确定region的位置，所以在读取数据时需要检查每个region（以找到索引数据），会带来一定性能（网络）开销。

其他的在网上也很多自己基于Coprocessor实现二级索引的文章，大体都是遵循类似的思路：构建一份“索引”的映射关系，存储在另一张hbase表或者其他DB里面。
方案优缺点：

优点：基于Coprocessor的方案，从开发设计的角度看，把很多对二级索引管理的细节都封装在的Coprocessor具体实现类里面，这些细节对外面读写的人是无感知的，简化了数据访问者的使用。
缺点：但是Coprocessor的方案入侵性比较强，增加了在Regionserver内部需要运行和维护二级索引关系表的代码逻辑等，对Regionserver的性能会有一定影响。

2.3 elasticsearch+hbase方案比如说你现在有一行数据
id name age ….30 个字段
但是你现在搜索，只需要根据 id name age 三个字段来搜索
如果你傻乎乎的往 es 里写入一行数据所有的字段，就会导致说 70% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单挑数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少
仅仅只是写入 es 中要用来检索的少数几个字段就可以了，比如说，就写入 es id name age 三个字段就可以了，然后你可以把其他的字段数据存在 MySQL 里面，我们一般是建议用 es + hbase 的这么一个架构。
hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，不要做复杂的搜索，就是做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了
从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。

文章插图

你最好是写入 es 的数据小于等于，或者是略微大于 es 的 filesystem cache 的内存容量
然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放 es，会每次查询都是 5 ~ 10 秒，现在可能性能就会很高，每次查询就是 50ms 。
四个字总结的话，我觉得就是“各司其职”，HBase 就用来存储，ES 就用来做索引，况且目前的实际情况跟文章中说的也很像，要查询的字段就几个，而其他的字段又很大又没用，没必要都丢到 ES 中，浪费查询效率
2.4 Solr+hbase方案Solr是一个独立的企业级搜索应用server，它对并提供相似干Web-service的API接口。用户能够通过http请求，向搜索引擎server提交一定格式的XML文件，生成索引。也能够通过Http Get操作提出查找请求，并得到XML格式的返回结果。
Solr是一个高性能。採用JAVA5开发。基干Lucene的全文搜索server 。同一时候对其进行了扩展。提供了比Lucene更为丰富的查询语言，同一时候实现了可配置、可扩展并对查询性能进行了优化，而且提供了一个完好的功能节理界面。是一款非常优秀的全文搜索引擎。