HBase 二级索引
为什么需要二级索引
HBase 一个令人惋惜的地方，就是不支持二级索引。因此，在实际项目开发中有一些补充方案来填补 HBase 的二级索引能力的缺陷。
HBase 系统单纯从解决大数据实时读写问题角度出发，重点关注于分布式存储的扩展性、容错性、读写性能等方面，为此也牺牲了很多传统关系型数据库的功能，比如 事务、SQL 表达与分析等。
实际上，这是 NoSQL 最初的含义，以解决大数据的实时存取为首要目标，提供简单的 Get、Put、Scan 接口，解决用户的大数据量存储的需求。因此，HBase 完全是一个非常优秀的大数据实时存取引擎，解决了传统数据库的容量问题。
就目前官方的 HBase 系统来说，并不支持二级索引，只有 rowkey 作为一级索引， 如果要对库里的非 rowkey 字段进行数据检索和查询， 往往要通过 MapReduce/Spark 等分布式计算框架进行，硬件资源消耗和时间延迟都会比较高。
为了 HBase 的数据查询更高效、适应更多的场景， 诸如使用非 rowkey 字段检索也能做到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 因此需要在原生 HBase 基础上构建二级索引， 以满足现实中更复杂多样的业务需求。
二级索引解决方案
基于 HBase 的 Coprocessor 的方案（典型代表 phoenix 组件）
- 官方文档：http://phoenix.apache.org/secondary_indexing.html
- 读写性能：有一定读写性能损害，索引越多，写入性能影响越大
- TTL功能：支持比较好
- 索引的使用限制：一个表的索引数不要超过10个
- 索引类型：全局索引、本地索引、覆盖索引
- 学习成本：类 JDBC 的 sql 语法，多参考官方的语法（http://phoenix.apache.org/language/index.html）
- 开源/社区活跃程度：开源，目前社区不太活跃
- 优点：社区文档多、使用简单、实时查询无延迟
- 缺点：非商业化方案，没有专门的技术支持
云厂自研的二级索引（典型代表阿里云自研增强版二级索引）
- 官方文档：https://help.aliyun.com/document_detail/144577.html?spm=a2c4g.11174283.6.576.4999363f2uZWt0
- 读写性能：二级索引内置于 HBase，官方的性能评测文档说比 Phoenix 好
- TTL功能：只能在单列索引上生效
- 索引的使用限制：一个表的索引个数最多不超过5个、组合索引的列最多不要超过3个
- 索引类型：全局索引、本地索引、覆盖索引
- 学习成本：内部封装的很简单，在使用上就是 HBase 的原生用法
- 开源/社区活跃程度：非开源、阿里云私有
- 优点：性能好、实时查询无延迟
- 缺点：被云厂商锁定
基于搜索平台的索引方案（如 Solr、ES 等）
- 官方文档：http://phoenix.apache.org/secondary_indexing.html
- 读写性能：有一定读写性能损害、数据同步的延迟需要考虑
- TTL功能：HBase 是单个 KV 过期，而 Solr 中只能按照 Document（对应HBase的一行）过期，过期的时间不完全一致
- 索引的使用限制：没有限制，完全取决于 Solr
- 索引类型：非常灵活
- 学习成本：需要熟悉 Solr 语法
- 开源/社区活跃程度：开源社区活跃
- 优点：查询方式更加灵活
- 缺点：引入搜索引擎组件、太重了，而且有明显的延迟问题
总结
- 为了不被云厂商锁定，所以不采用云厂商独有的二级索引方案
- 对于实时性要求高、索引数量少的场景，完全可以使用 phoenix，相对简易
- 对于实时性要求不高、搜索场景比较复杂的，需要引入搜索引擎，如 Solr 或 ES 进行索引构建
