JAVA的全文搜索引擎lucene 简介
Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。
对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。
1、全文检索的实现机制
Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。
比较一下Lucene和数据库：
Lucene 数据库
索引数据源：doc(field1,field2…) doc(field1,field2…)
\ indexer /
_____________
| Lucene Index|
————–
/ searcher \
结果输出：Hits(doc(field1,field2) doc(field1…))
索引数据源：record(field1,field2…) record(field1..)
\ SQL: insert/
_____________
| DB Index |
————-
/ SQL: select \
结果输出：results(record(field1,field2..) record(field1…))
Document：一个需要进行索引的“单元”
一个Document由多个字段组成 Record：记录，包含多个字段
Field：字段 Field：字段
Hits：查询结果集，由匹配的Document组成 RecordSet：查询结果集，由多个Record组成
2、全文检索 ≠ like “%keyword%”
通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。
由于数据库索引不是为全文索引设计的，因此，使用like “%keyword%”时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like”%keyword1%” and like “%keyword2%” …其效率也就可想而知了。
所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。
由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。
可以通过一下表格对比一下数据库的模糊查询：
Lucene全文索引引擎 数据库
索引 将数据源中的数据都通过全文索引一一建立反向索引 对于LIKE查询来说，数据传统的索引是根本用不上的。数据需要逐个便利记录进行GREP式的模糊匹配，比有索引的搜索速度要有多个数量级的下降。
匹配效果 通过词元(term)进行匹配，通过语言分析接口的实现，可以实现对中文等非英语的支持。 使用：like “%net%” 会把netherlands也匹配出来，
多个关键词的模糊匹配：使用like “%com%net%”：就不能匹配词序颠倒的xxx.net..xxx.com
匹配度 有匹配度算法，将匹配程度（相似度）比较高的结果排在前面。 没有匹配程度的控制：比如有记录中net出现5词和出现1次的，结果是一样的。
结果输出 通过特别的算法，将最匹配度最高的头100条结果输出，结果集是缓冲式的小批量读取的。 返回所有的结果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放这些临时结果集。
可定制性 通过不同的语言分析接口实现，可以方便的定制出符合应用需要的索引规则（包括对中文的支持） 没有接口或接口复杂，无法定制
结论 高负载的模糊查询应用，需要负责的模糊查询的规则，索引的资料量比较大 使用率低，模糊匹配规则简单或者需要模糊查询的资料量少
全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求
3、Lucene的创新之处：
大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。
Lucene和其他一些全文检索系统/应用的比较：
Lucene 其他开源全文检索系统
增量索引和批量索引 可以进行增量的索引(Append)，可以对于大量数据进行批量索引，并且接口设计用于优化批量索引和小批量的增量索引。 很多系统只支持批量的索引，有时数据源有一点增加也需要重建索引。
数据源 Lucene没有定义具体的数据源，而是一个文档的结构，因此可以非常灵活的适应各种应用（只要前端有合适的转换器把数据源转换成相应结构）， 很多系统只针对网页，缺乏其他格式文档的灵活性。
索引内容抓取 Lucene的文档是由多个字段组成的，甚至可以控制那些字段需要进行索引，那些字段不需要索引，近一步索引的字段也分为需要分词和不需要分词的类型：
需要进行分词的索引，比如：标题，文章内容字段
不需要进行分词的索引，比如：作者/日期字段 缺乏通用性，往往将文档整个索引了
语言分析 通过语言分析器的不同扩展实现：
可以过滤掉不需要的词：an the of 等，
西文语法分析：将jumps jumped jumper都归结成jump进行索引/检索
非英文支持：对亚洲语言，阿拉伯语言的索引支持 缺乏通用接口实现
查询分析 通过查询分析接口的实现，可以定制自己的查询语法规则：
比如： 多个关键词之间的 + – and or关系等
并发访问 能够支持多用户的使用
4、关于亚洲语言的的切分词问题(Word Segment)
对于中文来说，全文索引首先还要解决一个语言分析的问题，对于英文来说，语句中单词之间是天然通过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。
首先，肯定不能用单个字符作(si-gram)为索引单元，否则查“上海”时，不能让含有“海上”也匹配。
但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？
“北京 天安门” 还是“北 京 天安门”？让计算机能够按照语言习惯进行切分，往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。
另外一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，比如：
“北京天安门” ==> “北京 京天 天安 安门”。
这样，在查询的时候，无论是查询”北京” 还是查询”天安门”，将查询词组按同样的规则进行切分：”北京”，”天安安门”，多个关键词之间按与”and”的关系组合，同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言：韩文，日文都是通用的。
基于自动切分的最大优点是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来说，基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多，而对于英文，索引文件一般只有原文件的30%-40%不同，
自动切分词表切分
实现 实现非常简单 实现复杂
查询 增加了查询分析的复杂程度， 适于实现比较复杂的查询语法规则
存储效率 索引冗余大，索引几乎和原文一样大 索引效率高，为原文大小的30％左右
维护成本 无词表维护成本 词表维护成本非常高：中日韩等语言需要分别维护。
还需要包括词频统计等内容
适用领域 嵌入式系统：运行环境资源有限
分布式系统：无词表同步问题
多语言环境：无词表维护成本 对查询和存储效率要求高的专业搜索引擎
目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。关于中文的语言分析算法，大家可以在Google查关键词”wordsegment search”能找到更多相关的资料。
参考资料：http://www.chedong.com/tech/lucene.html