Lucene的工作原理

Lucene的工作原理Lucene的概述：Lucene(发音为['lusen])是一个非常优秀的开源的全文搜索引擎,我们可以在它的上面开发出各种全文搜索的应用来。Lucene在国外有很高的知名度，现在已经是Apache的顶级项目，在国内，Lucene的应用也越来越多。Lucene的算法原理：Lucene是一个高性能的java全文检索工具包，它使用的是倒排文件索引结构。该结构及相应的生成算法如下：0）设有两篇文章1和2文章1的内容为：TomlivesinGuangzhou,IliveinGuangzhoutoo.文章2的内容为：HeoncelivedinShanghai.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][i][live][guangzhou]文章2的所有关键词为：[he][live][shanghai]2)倒排索引：有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成关键词文章号guangzhou1he2i1live1,2shanghai2tom1通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。加上“出现频率”和“出现位置”信息后，我们的索引结构变为：关键词文章号[出现频率]出现位置guangzhou1[2]3，6he2[1]1i1[1]4live1[2]2，52[1]2shanghai2[1]3tom1[1]1以live这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第2个关键字。以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的（lucene没有使用B树结构），因此lucene可以用二元搜索算法快速定位关键词。实现时lucene将上面三列分别作为词典文件（TermDictionary）、频率文件(frequencies)、位置文件(positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。Lucene中使用了field（域）的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为前缀长度，后缀，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为3，语。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。注意是“上一个词”。由于词典是按顺序排列的，这种压缩方法的效果会非常显著。下面我们可以通过对该索引的查询来解释一下为什么要建立索引。假设要查询单词“live”，lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有文章号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。而用普通的顺序匹配算法，不建索引，而是对所有文章的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。全文检索框架的实现机制：Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==记录==字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。比较一下Lucene和数据库：Lucene数据库索引数据源：doc(field1,field2...)doc(field1,field2...)\indexer/_____________|LuceneIndex|--------------/searcher\结果输出：Hits(doc(field1,field2)doc(field1...))索引数据源：record(field1,field2...)record(field1..)\SQL:insert/_____________|DBIndex|-------------/SQL:select\结果输出：results(record(field1,field2..)record(field1...))Document：一个需要进行索引的“单元,一个Document由多个字段组成Record：记录，包含多个字段Field：字段Field：字段Hits：查询结果集，由匹配的Document组成RecordSet：查询结果集，由多个Record组成全文检索≠like%keyword%由于数据库索引不是为全文索引设计的，因此，使用like%keyword%时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like%keyword1%andlike%keyword2%...其效率也就可想而知了。通常比较厚的书籍后面常常附关键词索引表（比如：北京：12,34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==文章映射关系，利用这样的映射关系索引：[关键词==出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。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的文档是由多个字段组成的，甚至可以控制那些字段需要进行索引，那些字段不需要索引，近一步索引的字段也分为需要分词和不需要分词的类型：缺乏通用性，往往将文档整个索引了需要进行分词的索引，比如：标题，文章内容字段不需要进行分词的索引，比如：作者/日期字段语言分析通过语言分析器的不同扩展实现：可以过滤掉不需要的词：antheof等，西文语法分析：将jumpsjumpedjumper都归结成jump进行索引/检索非英文支持：对亚洲语言，阿拉伯语言的索引支持缺乏通用接口实现查询分析通过查询分析接口的实现，可以定制自己的查询语法规则：比如：多个关键词之间的+-andor关系等功能较强大并发访问能够支持多用户的使用功能较强大关于亚洲语言的的切分词问题(WordSegment)对于中文来说，全文索引首先还要解决一个语言分析的问题，对于英文来说，语句中单词之间是天然通过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。首先，肯定不能用单个字符作(si-gram)为索引单元，否则查“上海”时，不能让含有“海上”也匹配。但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？“北京天安门”还是“北京天安门”？让计算机能够按照语言习惯进行切分，往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。另外一个解决的办法是采用自动切分算法：将单词按照2元