业务模型有点类似于rmdb中的select from table where xx=xx,这里的xx无法做成rowkey，因此需要secondary index，否则只能全表扫描。尽管hbase的全表扫描是优势，但是在线应用也接受不了相应的延迟。
在早期的hbase中(0.20.x)曾经出现过secondary index，但后来因为无法解决的blocker级别issue而在0.89以上的版本中取消了。
目前0.90.x版本的hbase中有IndexBuilder类，用于离线地创建secondary index，用法是hadoop org.apache.hadoop.hbase.mapreduce.IndexBuilder TABLE_NAME COLUMN_FAMILY ATTR [ATTR ...]，如果应用的类型是一次写入或者每天定时写入，那这是个相当不错的选择。
但是如果想在线地写入index，事情就变得相当有趣了。目前的模型通常如下：
- 创建主表的wal edits对象
- 创建index表的wal edits对象，该对象特殊标注下，以便在恢复log时不会处理该对象
- sync这两个对象到hlog中
- 写主表的memstore，写完后执行commit
- 收到commit时，将index的写请求放入后台共享作业队列中，离线处理
- 返回给client
可见hbase由于无法解决多行一致性问题，因此让index的写入滞后于数据的写入，然后通过日志来保障最终一致性，这样产生了以下问题：
- 如何保证两个对象能够sync到hlog中？
- 如何保证failover后，能够知道哪些index队列中的请求还未执行的？
- 当发生failover后一段时间后，master的淘汰hlog机制启动后，如何能够知道哪些index hlog 是没有处理的？由于淘汰机制是检查hlog与storefile中的timestamp来进行的，很可能发生删除还没有处理index hlog的问题
- 如何自动地创建index表？目前只支持提前手工建好
- 读的api如何实现？如果索引不到数据，就直接返回null？还是需要到请求队列中去merge一次？
- index如何加载到内存中
这些问题非常有趣，留待后文慢慢细说。如果大家有思路，或者有其它问题，欢迎一起讨论。