转载请注明出处：jiq•钦's technical Blog
Hbase特征：
近期在学习Hbase。Hbase基于行健是建立了索引的，查询速度会很快，全然实时。
可是Hbase要基于行健之外的字段进行查询。那么就仅仅能是全盘扫描，基本上不可接受。
所以Hbase一般来说会针对详细的应用场景来设计行健，利用基于行健的查询的实时性来达到Hbase数据的实时查询。
关系型数据库基于索引字段的实时查询：
然后联想到关系型SQL数据库，他们针对主键是建立了B/B+/B-树索引的，基于主键的查询是实时的。范围扫描也是实时的。
更重要的是，基于非主键的其它字段，关系型数据库也能够非常方便地为其建立索引，从而达到实时查询。
Hbase的二级索引：
那么Hbase这样的NOSQL数据库可不能够也为除了行健之外的字段建立索引，从而针对这些字段的查询达到实时的效果呢？
答案是肯定的。
在Hbase里面针对除了行健之外的字段建立索引称之为“二级索引”。
通常建立二级索引的方式是利用Hbase中的“协处理器”，协处理器主要包括Observer和Endpoint两种模式，前者类似于关系型数据库中的触发器trigger，而后者类似于关系型数据库中的存储过程，通过Observer能够讲用户代码嵌入到现有的执行过程中，在特定的时间发生时就会触发相应的这段用户代码，即回调函数。
眼下有三种Observer接口：
1、 RegionObserver：提供相应数据操作事件的钩子,该类操作有Get、Put、Delete、Scan 等等。
每个 region 都会有一个 RegionObserver 实例。
2、 WALObserver：提供预写日志(write-ahead log,WAL)相关操作的钩子。WALObserver在WAL处理过程中执行,每个region server有一个实例。
3、 MasterObserver：提供DDL操作的钩子,该类操作有创建表、删除表、改动表的元信息等。MasterObserver执行在HBase master上。
每一类observer都能够载入多个。全部的observer会按链式顺序运行。
Hbase社区关于使用Coprocessor框架建立二级索引的方案主要有三种：
1、 基于WALObserver在一个索引表内生成索引，通过栏截Write Ahead Log写入操作，提取写入HLog的KeyValue对信息，把对应信息存储到索引表中。
2、 基于RegionObserver在一个Region内维护一个索引列族，通过拦截Region的put、delete等操作,提取对应信息存储到同一个Region的索引列族中，这样的方式的索引是局部索引。不支持全排序。
3、 基于RegionObserver在一个索引表内生成索引。通过栏截Region的put、delete等操作,提取对应信息存储到索引表中。
这个时候大家可能想知道索引表是什么样子的。一般来说，假设某一个Hbase表中有一列叫做所在地区，存储的是用户当前所在的城市，比方南京。上海这样。那么要针对着一些创建相应的二级索引，当插入新的一行记录的时候。在协处理器的钩子函数Observer中就会提取出这一列的值，在相应的索引表中插入一行索引记录。这行索引记录的rowkey是该列提取出来的值，而将这行索引记录的rowkey是刚才插入的那条记录的真正的rowkey，这样在检索地区，比方用户输入一个“南京”。或者运行基于Hbase的SQL语句：select * from userTable where location=’南京’的时候，就会检測到location这一列已经被创建了二级索引，所以就会在索引表中查找rowkey为’南京’的记录。然后取出真正的rowkey，在相应的数据表中取出相应的记录，展示给用户。
关系型SQL数据库和NoSQL数据的针对非主键的索引建立还是有非常多相似的地方的。
二级索引与全文检索：
可是有一点要注意，二级索引和全文检索是两个不同的概念：
建立二级索引通常是为了可以实时查询。而全文检索的目的是为了可以高速地在数据库中查找到自己关心的内容。前者是属于一种针对某一列值进行全然匹配的方式。而后一种是须要对数据进行分词，对分词的结果建立‘倒排索引’，从而可以支持依据特定的keyword查找其所属的那段内容（或者说所属的文档/记录）。
Hbase中的全文检索：
那么在Hbase中的全文检索一般怎么做呢？
之前接触过solr。是在Lucence上面的一层封装好的库，支持搭建分布式集群方式的全文检索服务。其原理就是简单地将要进行全文检索的字段的内容进行分词，然后将分词后的结果分别建立倒排索引。
Hbase中要实现全文检索。一般就能够结合Lucence/Solr来做，利用他们的自己主动创建索引的功能，针对Solr来说。无非就是其输入源不同了，曾经可能一般针对关系型数据库，如今输入源变为了Hbase。
全文检索不是实时的，并非说你往Hbase中插入一条记录，立即你就能够实时地在较快的时间内查询到，由于后台建立索引是须要一个过程的。一般来说可能几分钟左右吧。
关系型数据库中的全文检索：
在这里了解到了Hbase的全文检索之后，自然而然就联想到了关系型数据库中的全文检索。
关系型数据库的全文检索和Hbase的事实上差点儿是一样的。
比較流行的方式也是採用和Solr这样成熟的开源的全文检索库结合实现。将关系型数据库作为Solr的数据输入源，它们会定期自己主动从关系型数据库中抽取数据。或者由关系型数据库的插入/删除/更新操作触发，来在Solr中为指定的字段分词后的结果建立倒排索引。
另外国内也有一些比較出名的商用的全文检索引擎，我们公司眼下使用的就是这样的。
关系型数据库中的模糊查询like：
在思考查询的时候，非常难不想到关系型数据库中的模糊查询。
个人认为，模糊查询看似是和针对某一字段的全文检索类似，事实上在功能上讲（不谈效率）要比这个更加强大。比方你针对“我是季义钦”这句话，你可能利用全文检索引擎。分词时候会分成“我”，“是”。“季义钦”三个词（实际的分词器可能不这样。我仅仅是举个样例）。这个时候你全文检索仅仅可以搜索到“我”，“是”，“季义钦”三个词，假设你要搜索“义钦”那么就会搜索不到。
可是关系型数据库中的模糊查询，你要是用“%义钦”来查询绝对能查询到。
为什么呢？
我了解了一下，发现关系型数据库中的模糊查询并没有为这个要模糊查询的字段建立整个字段的索引，更没有分词之后再针对分词结果建立索引，而是拿到“%义钦”的查询条件之后，全表扫描，对这个正則表達式进行匹配。
尽管你把通配符放在前面。像“like %义钦”这样，这个查询肯定不会走索引，而是会全表扫描，可是假设你的模糊查询是“like 季%”。即将通配符放在前后面，那么这个查询是有可能走索引的，并且通配符放在前面的查询事实上是有一些技巧来进行详细的优化的。比方看看这个样例：http://blog.csdn.net/firstboy0513/article/details/6912632。
在大部分关系型数据库中，事实上是能够为指定字段建立全文索引（注意，这里所说的并非不是採用第三方全文检索引擎）的，比方MYSQL中像这样：
MATCH (col1,col2,...) AGAINST (expr[search_modifier])
search_modifier: { IN BOOLEAN MODE | WITHQUERY EXPANSION }
比如：SELECT * FROM tab_name WHERE MATCH (col1,col2) AGAINST(search_word);
这里的table须要是MyISAM类型的表。col1、col2须要是char、varchar或text类型，在查询之前须要在col1和col2上建立一个全文索引。
以下有一段话须要注意：
MySQL在高并发连接、数据库记录数较多的情况下，SELECT... WHERE ... LIKE '%...%'的全文搜索方式不仅效率差，并且以通配符%和_开头作查询时，使用不到索引，须要全表扫描，对数据库的压力也非常大。MySQL针对这一问题提供了一种全文索引解决方式，这不只提高了性能和效率（由于MySQL对这些字段做了索引来优化搜索）。并且实现了更高质量的搜索。可是。至今为止。MySQL对中文全文索引无法正确支持。
--- 这个问题能够通过使用一些MYSQL中文全文检索插件来解决。
关于Oracle中的全文检索能够參考这篇文章：http://www.iteye.com/topic/1118055。
这篇文章是个人意见，如果您有任何疑问或更正，欢迎大家讨论，谢谢！
版权声明：本文博客原创文章，博客，未经同意，不得转载。