设计类图

1：搜索类图

2.Lucene的索引效率

一般书籍后面经常附关键词索引表（好比：北京：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条结果输出，结果集是缓冲式的小批量读取的。	返回全部的结果集，在匹配条目很是多的时候（好比上万条）须要大量的内存存放这些临时结果集。
可定制性	经过不一样的语言分析接口实现，能够方便的定制出符合应用须要的索引规则（包括对中文的支持）	没有接口或接口复杂，没法定制
结论	高负载的模糊查询应用，须要负责的模糊查询的规则，索引的资料量比较大	使用率低，模糊匹配规则简单或者须要模糊查询的资料量少

 

3 中文切分词机制

对于中文来讲，全文索引首先还要解决一个语言分析的问题，对于英文来讲，语句中单词之间是自然经过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，全部，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。

首先，确定不能用单个字符做(si-gram)为索引单元，不然查“上海”时，不能让含有“海上”也匹配。但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？“北京 天安门” 仍是“北 京 天安门”？让计算机可以按照语言习惯进行切分，每每须要机器有一个比较丰富的词库才可以比较准确的识别出语句中的单词。另一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，好比："北京天安门" ==> "北京 京天 天安 安门"。这样，在查询的时候，不管是查询"北京" 仍是查询"天安门"，将查询词组按一样的规则进行切分："北京"，"天安安门"，多个关键词之间按与"and"的关系组合，一样可以正确地映射到相应的索引中。这种方式对于其余亚洲语言：韩文，日文都是通用的。

基于自动切分的最大优势是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来讲，基于2元语法的切分仍是够用的。基于2元切分后的索引通常大小和源文件差很少，而对于英文，索引文件通常只有原文件的30%-40%不一样，

	自动切分	词表切分
实现	实现很是简单	实现复杂
查询	增长了查询分析的复杂程度，	适于实现比较复杂的查询语法规则
存储效率	索引冗余大，索引几乎和原文同样大	索引效率高，为原文大小的30％左右
维护成本	无词表维护成本	词表维护成本很是高：中日韩等语言须要分别维护。 还须要包括词频统计等内容
适用领域	嵌入式系统：运行环境资源有限 分布式系统：无词表同步问题 多语言环境：无词表维护成本	对查询和存储效率要求高的专业搜索引擎