二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性，RDBMS早已支持，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。这篇文章会以Hbase做为对象来讨论如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook方案和官方Coprocessor的介绍。
理论目标在HBase中实现二级索引与索引Join需要考虑三个目标：1，高性能的范围检索。2，数据的低冗余（存储所占的数据量）。3，数据的一致性。
性能与数据冗余，一致性是相互制约的关系。如果你实现了高性能地范围检索，必然需要靠冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。如果你不要求高效地范围检索，那么可以不考虑产生冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。
理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正：

1，按索引建表每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。单表以row key存储索引，column value存储id值或其他数据 ，这就是Hbase索引表的结构。
如何Join？多索引（多表）的join场景中，主要有两种参考方案：
1，按索引的种类扫描各自独立的单索引表，最后将扫描结果merge。这个方案的特点是简单，但是如果多个索引扫描结果数据量比较大的话，merge就会遇到瓶颈。
比如，现在有一张1亿的用户信息表，建有出生地和年龄两个索引，我想得到一个条件是在杭州出生，年龄为20岁的按用户id正序排列前10个的用户列表。有一种方案是，系统先扫描出生地为杭州的索引，得到一个用户id结果集，这个集合的规模假设是10万。然后扫描年龄，规模是5万，最后merge这些用户id，去重，排序得到结果。
这明显有问题，如何改良？保证出生地和年龄的结果是排过序的，可以减少merge的数据量？但Hbase是按row key排序，value是不能排序的。变通一下 – 将用户id冗余到row key里？OK，这是一种解决方案了，这个方案的图示如下：

单索引
组合索引

检索性能
优异
优异

存储
数据不冗余，节省存储。
数据冗余，存储比较浪费。

事务性
多个索引保证事务性比较困难。
多个索引保证事务性比较困难。

join
性能较差
性能优异

count,sum,avg,etc
符合条件的结果集全表扫描
符合条件的结果集全表扫描

从上表中可以得知，方案1,2都存在更新时事务性保证比较困难的问题。如果业务系统可以接受最终一致性的话，事务性会稍微好做一些。否则只能借助于复杂的分布式事务，比如JTA，Chubby等技术。count, sum, avg, max, min等聚合功能，Hbase只能通过硬扫的方式，并且很悲剧，你可能需要做一些hack操作（比如加一个CF,value为null），否则你在扫描时可能需要往客户端传回所有数据。当然你可以在这个场景上做一些优化，比如增加状态表等，但复杂性带来的风险会更高。还有一种终极解决方案就是在业务上只提供上一页和下一页，这或许是最简单有效的方案了。
2，单张表多个列族，索引基于列Hbase提供了列族Column Family特性。列索引是将Column Family做为index，多个index值散落到Qualifier，多个column值依据version排列（CF, Qualifer, Version Hbase会保证有序，其中CF和Qualifier正序，Version倒序）。
举个典型的例子，就是用户卖了很多商品，这些商品的标题title需要支持like %title%查询。传统基于RDMBS就是模糊查询，基于search engine就是分词+倒排表。在HBase中，模糊查询显然不满足我们的要求，接下来只能通过分词+倒排的方式来存储。基于CF的倒排表索引结构见下图：

列索引
表索引

检索性能
检索数据需要走多次scan，第一次scan row key，第二次scan qualifier，第三次scan version。
只需要走一次row key的scan即可。

存储
在没有组合索引时，存储较节省
在没有组合索引时，存储较节省

事务性
容易保证
保证事务性比较困难

join
性能较差，只有在建立组合条件Qualifier的时候性能会有所改善
性能较差，只有在建立组合表索引的时候性能会有所改善

额外的问题
1，同一个row里每个qualifier的version是有大小限制的，不能超过Int的最大值。（别以为这个值很大，对于海量数据存储，上亿很平常）2，version的count总数需要额外做处理获取。3，单个row数据超过split大小时，会导致不能compaction或compaction内存吃紧，增加风险。

count,sum,avg,etc
符合条件的结果集全表扫描
符合条件的结果集全表扫描

虽然列索引缺点这么多，但是存储节省带来的成本优势有时还是值得我们去这么做的，何况它还解决了事务性问题，需要用户自己去权衡。值得一提的是，Facebook的消息应用服务器就是基于类似的方案来实现的。
3，ITHBase方案一中的多表，解决了性能问题，同时带来了存储冗余和数据一致性问题。这两个问题中，只要解决其中一项，其实也就满足了大多数业务场景。本方案中，着重关注的是数据一致性。ITHbase的全称是 Indexed Transactional HBase，从名字中就能看出，事务性是它的重要特性。
ITHBase的事务原理简介建一张事务表GLOBAL_TRX_LOG，每次开启事务时，在表中记录状态。因为是基于Hbase的HTable，事务表同样会写WAL用于恢复，不过这个日志格式被ITHbase改造过，它称之为THLog。客户端对多张表更新时，先启动事务，然后每次PUT，将事务id传递给HRegionServer。ITHbase通过继承HRegionServer和HReogin类，重写了大多数操作接口方法，比如put, update, delete, 用于获取transactionalId和状态。当server收到操作和事务id后，先确认服务端收到，标记当前事务为待写入状态（需要再发起一次PUT）。当所有表的操作完成后，由客户端统一做commit写入，做二阶段提交。

preFlush, postFlush: Called before and after the memstore is flushed into a new store file.
preCompact, postCompact: Called before and after compaction.
preSplit, postSplit: Called after the region is split.
preClose and postClose: Called before and after the region is reported as closed to the master.

The RegionObserver interface is defines these hooks:
preGet, postGet: Called before and after a client makes a Get request.
preExists, postExists: Called before and after the client tests for existence using a Get.
prePut and postPut: Called before and after the client stores a value.
preDelete and postDelete: Called before and after the client deletes a value.
preScannerOpen postScannerOpen: Called before and after the client opens a new scanner.
preScannerNext, postScannerNext: Called before and after the client asks for the next row on a scanner.
preScannerClose, postScannerClose: Called before and after the client closes a scanner.
preCheckAndPut, postCheckAndPut: Called before and after the client calls checkAndPut().
preCheckAndDelete, postCheckAndDelete: Called before and after the client calls checkAndDelete().

利用这些hooks可以实现region级二级索引，实现count, sum, avg, max, min等聚合操作而不需要返回所有的数据，详见 https://issues.apache.org/jira/browse/HBASE-1512。
二级索引的原理猜测因为coprocessor的最终方案还未公布，就提供的这些hooks来说，二级索引的实现应该是拦截同一个region的put, get, scan, delete等操作。与此同时在同一个reigon里维护一个索引CF，建立对应的索引表。基于region的索引表其实有很多局限性，比如全局排序就很难做。
不过我觉得Coprocessor最大的好处在于其提供了server端的完全扩展能力，这对于Hbase来说是一个大的跃进。
如何join？
目前还未发布，不过就了解很难从本质上有所突破。解决方案无非就是merge和composite index，同样事务性是需要解决的难题之一。
业界已经公开的二级索引方案罗列：
0.19.3版Secondary Index
一直关注HBase的同学，或许知道，早在HBase 0.19.3版发布时，曾经加入过secondary index的功能，Issue详见这里。它的使用例子也很简单：http://blog.rajeevsharma.in/2009/06/secondary-indexes-in-hbase.html
0.19.3版Secondary Index通过将列值以row key方法存储，提供索引scan。但HBase早期的需求主要来自Hadoop。事务的复杂性以及当时发现hadoop-core里有个很难解决的与ITHBase兼容的问题，致使官方在0.20.0版将其核心代码移出了hbase-core，改为contrib第三方扩展，Issue详见这里。
Transactional tableindexed-ITHBase****
这个方案就是在0.19.3版被官方剥离出核心的第三方扩展，它的方案上面已经介绍过了。目前支持最新的Hbase 0.90。是否具备工业强度的稳定性是用户选择它的主要障碍。
https://github.com/hbase-trx/hbase-transactional-tableindexed
Facebook方案
facebook采用的是单表多列索引的解决方案，上面已经提到过了。很完美地解决了数据一致性问题，这主要跟他们的使用场景有关。

global ordering
yes
no
IHBase has an index for each region. The flip side of not having global ordering is compatibility with the good old HRegion: results are coming back in row order (and not value order as in ITHBase)

Full table scan?
no
no
THbase does a partial scan on the index table. ITHBase supports specifying start/end rows to limit the number of scanned regions

Multiple Index Usage
no
yes
IHBase can take advantage of multiple indexes in the same scan. IHBase IdxScan object accepts an Expression which allows intersection/unison of several indexed column criteria

Extra disk storage
yes
no
IHBase indexes are created when the region starts/flushes and do not require any extra storage

Extra RAM
yes
yes
IHBase indexes are in memory and hence increase the memory overhead. THBbase indexes increase the number of regions each region server has to support thus costing memory too

Parallel scanning support
no
yes
In ITHBase the index table needs to be consulted and then GETs are issued for each matching row. The behavior of IHBase (as perceived by the client) is no different than a regular scan and hence supports parallel scanning seamlessly. parallel GET can be implemented to speedup THbase scans

原理简介
在Memstore满了以后刷磁盘时，IHBase会进行拦截请求并为这个memstore的数据构建索引。索引另一个CF的方式存储在表内。不过只支持region级别（类似coprocessor）scan的时候，IHBase会结合索引列中的标记，来加速scan。
http://github.com/ykulbak/ihbase

转:http://kenwublog.com/hbase-secondary-index-and-join

http://blog.csdn.net/kirayuan/article/details/6735222