Lucene.Net学习心得
一、Lucene点滴
(发音为['lusen])，我经常就读鹿神，是头活蹦乱跳的好鹿，研究它吧，保证感觉它很神！Lucene是一个非常优秀的开源的全文搜索引擎，我们可以在它的上面开发出各种全文搜索的应用来。Lucene在国外有很高的知名度，现在已经是Apache的顶级项目。
二、倒排索引原理简述
Lucene是一个高性能的java全文检索工具包，它使用的是倒排文件索引结构。具体解释算法理论就不讲了，直接用例子来说明吧，如果你认真仔细的读懂例子，真正领会了其中的思想，你肯定就明白了Lucene索引的基本原理！记住：理解！把例子用你自己的语言表述出来，就是翻译成你自己的东西，以后你想自己写，也就是换成计算机语言再翻译一次！！
Lucene结构及相应的生成算法如下：
我们设有两篇文章1和2
文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的内容为：He once lived in Shanghai.
1)全文分析：
由于Lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施
a. 我们现在有的是文章内容，即一大串字符串，我们先要找出全文字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。（中文通常用词典的方式比较准确）
b. 文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉，即分词解析中的过滤
c. 用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。即解析过程中的额外处理（用户可以根据自己需要增加多重处理）。
d. 用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”即进一步优化处理（可以更人性更友好）
e. 文章中的标点符号通常不表示某种概念，也可以过滤掉
所有上面描述的步骤在lucene中都由Analyzer类完成！你了解了过程，你就可以根据自己的兴趣或者需要去关心特点的步骤相关代码，或者自己进一步添砖加瓦扩展功能。
经过上面处理后
文章1的所有关键词为：[tom] [live] [guangzhou] [live] [guangzhou]
文章2的所有关键词为：[he] [live] [shanghai]
2) 倒排索引：
有了关键词后，我们就可以建立倒排索引了。
上面经过解析后的对应关系是：“文章号”对“文章中所有关键词”。
这种对应比较符合我们正常的思维习惯，反过来对应的话，就要颠倒思维，所以这种算法叫做倒排！ 倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成
关键词 文章号
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1
进一步扩展上述基本倒排索引，通常我们仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene 中记录的就是这种位置。
加上“出现频率”和“出现位置”信息后，我们的索引结构充实后变为：
| 关键词 | 文章号 | [出现频率] | 出现位置 |
| guangzhou | 1 | [2] | 3，6 |
| he | 2 | [1] | 1 |
| i | 1 | [1] | 4 |
| live | 1 | [2] | 2，5 |
| 2 | [1] | 2 | |
| shanghai | 2 | [1] | 3 |
| tom | 1 | [1] | 1 |
以第4行的 live 词语索引记录作实例我们说明一下该结构：
live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。
以上就是lucene索引结构中最核心的部分。是不是描述起来很简单，没错，其实也就是这么简单！算法都是人想出来的，毛主席说过办法总比困难多，计算机算法也不例外，你何必恐惧它呢，本来就是很容易的事情！！！
【进一步深入探索，如果你不想深入，完全可以略过不看】
如果你对计算机算法和数据结构稍有研究，你就很容易发现，我们上面生成的倒排索引关键字是按字母字符顺序排列的（Lucene没有使用B树结构），因此Lucene可以用二元搜索算法快速定位关键词。
具体实现时Lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件(positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。
Lucene中使用了field的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。
为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。注意是“上一个词”。由于词典是按顺序排列的，这种压缩方法的效果会非常显著。
三、全文检索框架的实现机制：
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组成 |
请一定记住：全文检索 ≠ 数据库SQL语句中的 like "%keyword%"
由于数据库索引不是为全文索引设计的，因此，使用like"%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like"%keyword2%" ...其效率也就可想而知了。
通常比较厚的书籍后面常常附关键词索引表（比如：北京：12,34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。
所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。
由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。
Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。
我们对比一下Lucene全文索引和关系数据库模糊查询 算法区别：
| Lucene全文索引引擎 | 数据库 | |
| 索引 | 将数据源中的数据都通过全文索引一一建立倒排索引 | 对于LIKE查询来说，数据传统的索引是根本用不上的。数据需要逐个便利记录进行GREP式的模糊匹配，比有索引的搜索速度要有多个数量级的下降。 |
| 匹配效果 | 通过词元(term)进行匹配，通过语言分析接口的实现，可以实现对中文等非英语的支持。 | 使用：like "%net%" 会把netherlands也匹配出来， 多个关键词的模糊匹配：使用like "%com%net%"：就不能匹配词序颠倒的xxx.net..xxx.com |
| 匹配度 | 有匹配度算法，将匹配程度（相似度）比较高的结果排在前面。 | 没有匹配程度的控制：比如有记录中net出现5词和出现1次的，结果是一样的 |
| 结果输出 | 通过特别的算法，将最匹配度最高的头100条结果输出，结果集是缓冲式的小批量读取的。 | 返回所有的结果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放这些临时结果集。 |
| 可定制性 | 通过不同的语言分析接口实现，可以方便的定制出符合应用需要的索引规则（包括对中文的支持） | 没有接口或接口复杂，无法定制 |
| 结论 | 高负载的模糊查询应用，需要负责的模糊查询的规则，索引的资料量比较大 | 使用率低，模糊匹配规则简单或者需要模糊查询的资料量少 |
全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求。
Lucene的创新之处：
大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。
Lucene和其他一些全文检索系统/应用的比较：
| Lucene | 其他开源全文检索系统 | |
| 增量索引和批量索引 | 可以进行增量的索引(Append)，可以对于大量数据进行批量索引，并且接口设计用于优化批量索引和小批量的增量索引。 | 很多系统只支持批量的索引，有时数据源有一点增加也需要重建索引。 |
| 数据源 | Lucene没有定义具体的数据源，而是一个文档的结构，因此可以非常灵活的适应各种应用（只要前端有合适的转换器把数据源转换成相应结构）。 | 很多系统只针对网页，缺乏其他格式文档的灵活性。 |
| 索引内容抓取 | Lucene的文档是由多个字段组成的，甚至可以控制那些字段需要进行索引，那些字段不需要索引，近一步索引的字段也分为需要分词和不需要分词的类型： 需要进行分词的索引，比如：标题，文章内容字段 不需要进行分词的索引，比如：作者/日期字段 |
缺乏通用性，往往将文档整个索引了 |
| 语言分析 | 通过语言分析器的不同扩展实现： 可以过滤掉不需要的词：an the of 等， 西文语法分析：将jumps jumped jumper都归结成jump进行索引/检索 非英文支持：对亚洲语言，阿拉伯语言的索引支持 |
缺乏通用接口实现 |
| 查询分析 | 通过查询分析接口的实现，可以定制自己的查询语法规则： 比如： 多个关键词之间的 + - and or关系等 |
功能较强大 |
| 并发访问 | 能够支持多用户的使用 | 功能较强大 |
四、关于亚洲语言的的切分词问题(Word Segment)
对于中文来说，全文索引首先还要解决一个语言分析的问题，对于英文来说，语句中单词之间是天然通过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。
首先，肯定不能用单个字符作(si-gram)为索引单元，否则查“上海”时，不能让含有“海上”也匹配。但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？“北京 天安门” 还是“北 京 天安门”？让计算机能够按照语言习惯进行切分，往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。
另外一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，比如：
"北京天安门" ==> "北京 京天 天安 安门"。
这样，在查询的时候，无论是查询"北京" 还是查询"天安门"，将查询词组按同样的规则进行切分："北京"，"天安安门"，多个关键词之间按与"and"的关系组合，同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言：韩文，日文都是通用的。
基于自动切分的最大优点是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来说，基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多，而对于英文，索引文件一般只有原文件的30%-40%不同。
| 自动切分 | 词表切分 | |
| 实现 | 实现非常简单 | 实现复杂 |
| 查询 | 增加了查询分析的复杂程度 | 适于实现比较复杂的查询语法规则 |
| 存储效率 | 索引冗余大，索引几乎和原文一样大 | 索引效率高，为原文大小的30％左右 |
| 维护成本 | 无词表维护成本 | 词表维护成本非常高：中日韩等语言需要分别维护。 还需要包括词频统计等内容 |
| 适用领域 | 嵌入式系统：运行环境资源有限 分布式系统：无词表同步问题 多语言环境：无词表维护成本 |
对查询和存储效率要求高的专业搜索引擎 |
目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。
五、Lucene的结构框架：
注意：Lucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，纯Java的词法分析生成器），所以如果从源代码编译或需要修改其中的QueryParser、定制自己的词法分析器，还需要从https://javacc.dev.java.net/下载javacc。
Lucene的组成结构：对于外部应用来说索引模块(index)和检索模块(search)是主要的外部应用入口。
| org.apache.Lucene.search/ | 搜索入口 |
| org.apache.Lucene.index/ | 索引入口 |
| org.apache.Lucene.analysis/ | 语言分析器 |
| org.apache.Lucene.queryParser/ | 查询分析器 |
| org.apache.Lucene.document/ | 存储结构 |
| org.apache.Lucene.store/ | 底层IO/存储结构 |
| org.apache.Lucene.util/ | 一些公用的数据结构 |
六、从Lucene学到更多：
Luene的确是一个面对对象设计的典范。如果你要学习面向对象编程，你要学习java，建议你学习Lucene吧，玩一个实实在在的项目，而且是有名的基础项目，在无形之中你既可以学习这个项目的使用，又可以学习java语法，又可以学习大师们的代码技巧，还可以以后为Lucene做点什么，真的你可以一举多得！！！何乐不为呢？！
- 所有的问题都通过一个额外抽象层来方便以后的扩展和重用：你可以通过重新实现来达到自己的目的，而对其他模块而不需要；
- 简单的应用入口Searcher, Indexer，并调用底层一系列组件协同的完成搜索任务；
- 所有的对象的任务都非常专一：比如搜索过程：QueryParser分析将查询语句转换成一系列的精确查询的组合(Query)，通过底层的索引读取结构IndexReader进行索引的读取，并用相应的打分器给搜索结果进行打分/排序等。所有的功能模块原子化程度非常高，因此可以通过重新实现而不需要修改其他模块。
- 除了灵活的应用接口设计，Lucene还提供了一些适合大多数应用的语言分析器实现（SimpleAnalyser,StandardAnalyser），这也是新用户能够很快上手的重要原因之一。
