在HBase中，表格的Rowkey按照字典排序，Region按照RowKey设置split point进行shard，通过这种方式实现的全局、分布式索引，成为了其成功的最大的砝码。图1显示了HBase表格的Rowkey切分与Region的部署关系图。
图1： HBase Rowkey-Region 关系图
然而，随着在HBase系统上应用的驱动，人们发现Global-Rowkey-Indexing不再满足应用的需求。单一的通过Rowkey检索数据的方式，不再满足更多应用的需求，人们希望像SQL一样检索数据，select * from table where col=val。可是，HBase之前的定位是大表的存储，要进行这样的查询，往往是要通过类似Hive、Pig等系统进行全表的MapReduce计算，这种方式既浪费了机器的计算资源，又因高延迟使得应用黯然失色。于是，在业界和社区，针对HBase Secondary Indexing的方案，成为HBase新版本(0.96)呼声最高的一项Feature。
粗略分析了当前的技术，大概的方案可以总结为这样两类：
1、使用HBase的coprocessor。CoProcessor相当于HBase的Observer+hook，目前支持MasterObserver、RegionObserver和WALObserver，基本上对于HBase Table的管理、数据的Put、Delete、Get等操作都可以找到对应的pre和post。这样如果需要对于某一项Column建立Secondary Indexing，就可以在Put、Delete的时候，将其信息更新到另外一张索引表中。如图二所示，对于Indexing里面的value值是否存储的问题，可以根据需要进行控制，如果value的空间开销不大，逆向的检索又比较频繁，可以直接存储在Indexing Table中，反之则避免这种情况。
图2 使用HBase Coprocessor实现Secondary Indexing
2、由客户端发起对于主表和索引表的Put、Delete操作的双重操作。源自：http://hadoop-hbase.blogspot.com/2012/10/musings-on-secondary-indexes.html 【墙外】
它具体的做法总结起来有：
设置主表的TTL(Time To Live)比索引表小一点，让其略早一点消亡。
不要在IndexingTable存储Value值，即删除如图2所示的val列。
Put操作时，对于操作的主表的所有列，使用同一的Local TimeStamp的值，更新到Indexing Table，然后使用该TimeStamp插入主表数据。
Delete操作时，首先操作主表的数据，然后再去更新Indexing Table的数据。
虽然在这种方案里无法保证原子性和一致性，但是通过TimeStamp的设置，No Locks和 No Server-side codes，使其在二级索引上有着较大的优势。至于中间出错的环节，我们看看是否可以容忍：
1）Put索引表成功，Put主表失败。由于Indexing Table不存储val值，仍需要跳转到Main Table,所以这样的错误相当于拿一个Stale index去访问对应Rowkey吧了，对结果正确性没有影响。
2）Delete主表成功，Delete索引表失败。都是索引表的内容>=主表的内容而已，而实际返回值需要通过主表进行。
生产环境下，什么样的方法实用性更强？
就这个问题，根据个人当前对于生产环境下HBase集群的经验，综合上面两种方式的优劣，可以通过这样的方式设计。
1、主表服务在线业务，它的性能需要保证。使用coprocessor和客户端的封装也好，都会影响其性能，所以在正常情况下，直接操作都不太合适。如果想使用方案二，我倒是感觉，可以调整Indexing Table的操作方式，去除保证其安全性的内容，比如可以关闭写HLOG，这样会进一步减低其操作的延迟。
2、离线更新索引表。在真正需要二级索引的场景内，其时效性要求往往不高。可以将索引实时更新到Redis等KV系统中，定时从KV更新索引到Hbase的Indexing Table中。PS:Redis里面有DB设置的概念，可以按照时间段进行隔离，这样某段时间内的数据会更新到Redis上，保证Redis导入MapReduce之后仍然可以进行update操作。
PS：社区和生产系统关于Hbase二级索引的方案，还在继续当中，会持续关注。
