2 索烦?br />3 更新索引
那么如何创徏索引Q?br />首先Q要创徏一个IndexWriter对象Q这个对象负责初始化和创建烦引。相对于之前的准备工作，然后在分?br /> 一下你要做索引的文档等?br />然后Q就是添加烦引?br /> 索引文gQ也向数据库一P是一条一条的数据。在索引里面Q我们叫Document.q个东西Q我们可以和数据库里面的记录作对应。也有何数据库一L字段Q不q，对于每一个字D，你可以设|不同的记录属性，比如Q有的字D不创徏索引Q那么在dq个索引记录的时候，׃不进行分词处理。有的字D，不予存储Q也是_可能对这个字D作索引Q检索有用，但是Q检索出来的记录里面׃在有q个字段的数据。有的字D可能既不作索引Q也不作存储Q那是不予处理?br />如果讄完了q个Document的对象的各个字段的属性，那么可以添加这条烦引了?br />所以，我们再程序实现的时候，也就是这么过q程?br />刚学Q主要现理一下思\。目前，仅此而已。希望多多指正，共同学习Q共同探讨?br />
]]>
Lucene的工作原?/h4>
Lucene的概qͼ
Lucene(发音?['lusen] )是一个非怼U的开源的全文搜烦引擎,我们可以在它的上面开发出各种全文搜烦的应用来。Lucene在国外有很高的知名度Q现在已l是Apache的顶U项目，在国内，Lucene的应用也来多?/p>
Lucene的算法原理：
Lucene是一个高性能的java全文索工具包Q它使用的是倒排文g索引l构。该l构及相应的生成法如下Q?
0Q设有两文??
文章1的内容ؓQTom lives in Guangzhou,I live in Guangzhou too.
文章2的内容ؓQHe once lived in Shanghai.
1)全文分析Q由于lucene是基于关键词索引和查询的Q首先我们要取得q两文章的关键词，通常我们需要如下处理措?
a.我们现在有的是文章内容，即一个字W串Q我们先要找出字W串中的所有单词，卛_词。英文单词由于用I格分隔Q比较好处理。中文单词间是连在一L需要特D的分词处理?
b.文章中的”in? “once?“too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义Q这些不代表概念的词可以qo?
c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来Q所以所有单词需要统一大小写?
d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来Q所以需要把“lives”，“lived”还原成“live?
e.文章中的标点W号通常不表C某U概念，也可以过滤掉
在lucene中以上措施由Analyzercd?/font>
l过上面处理?
文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有关键词为：[he] [live] [shanghai]
2) 倒排索引Q有了关键词后，我们可以徏立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关pd过来，变成Q“关键词”对“拥有该关键词的所有文章号”?/font>文章1Q?l过倒排后变?
关键?文章?
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1
通常仅知道关键词在哪些文章中出现q不够，我们q需要知道关键词在文章中出现ơ数和出现的位置Q通常有两U位|：a)字符位置Q即记录该词是文章中W几个字W（优点是关键词亮显时定位快Q；b)关键词位|，卌录该词是文章中第几个关键词（优点是节U烦引空间、词l（phaseQ查询快Q，lucene中记录的是q种位置?
加上“出现频率”和“出C|”信息后Q我们的索引l构变ؓQ?/p>
| 关键?/td> | 文章?/td> | [出现频率] | 出现位置 |
| guangzhou | 1 | [2] | 3Q? |
| he | 2 | [1] | 1 |
| i | 1 | [1] | 4 |
| live | 1 | [2] | 2Q? |
| 2 | [1] | 2 | |
| shanghai | 2 | [1] | 3 |
| tom | 1 | [1] | 1 |
以live q行Z我们说明一下该l构Qlive在文?中出C2ơ，文章2中出C一ơ，它的出现位置为?,5,2”这表示什么呢Q我们需要结合文章号和出现频率来分析Q文?中出C2ơ，那么?,5”就表示live在文?中出现的两个位置Q文?中出C一ơ，剩下的?”就表示live是文?中第 2个关键字?
以上是lucene索引l构中最核心的部分。我们注意到关键字是按字W顺序排列的Qlucene没有使用B树结构）Q?/font>因此lucene可以?font color="#008080">二元搜烦法快速定位关键词?
实现?lucene上面三列分别作?font color="#800000">词典文gQTerm DictionaryQ?font color="#800000">频率文g(frequencies)?font color="#800000">位置文g (positions)保存。其?font color="#008080">词典文g不仅保存有每个关键词Q还保留了指向频率文件和位置文g的指针，通过指针可以扑ֈ该关键字的频率信息和位置信息?
Lucene中用了field的概念，用于表达信息所在位|（如标题中Q文章中Qurl中）Q?/font>在徏索引中，?font color="#008080">field信息也记录在词典文g?/font>Q每个关键词都有一个field信息(因ؓ每个关键字一定属于一个或多个field)?
Z减小索引文g的大，Lucene对烦引还使用?font color="#800000">压羃技?/font>。首先，对词典文件中的关键词q行了压~，关键词压~ؓ<前缀长度Q后~>Q例如：当前词ؓ“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压~ؓ<3Q语>。其ơ大量用到的是对数字的压~，数字只保存与上一个值的差|q样可以减小数字的长度，q而减保存该数字需要的字节敎ͼ。例如当前文章号?6389Q不压羃要用3个字节保存）Q上一文章h16382Q压~后保存7Q只用一个字节）?注意是“上一个词”。由于词典是按顺序排列的Q这U压~方法的效果会非常显著?/font>
下面我们可以通过对该索引的查询来解释一下ؓ什么要建立索引?
假设要查询单?“live”，lucene先对词典二元查找、找到该词，通过指向频率文g的指针读出所有文章号Q然后返回结果。词兔R常非常，因而，整个q程的时间是毫秒U的?
而用普通的序匚w法Q不建烦引，而是Ҏ有文章的内容q行字符串匹配，q个q程会相当~慢Q当文章数目很大Ӟ旉往往是无法忍受的?/p>
全文索框架的实现机制Q?/strong>
Lucene的API接口设计的比较通用Q输入输出结构都很像数据库的?=>记录==>字段Q所以很多传l的应用的文件、数据库{都可以比较方便的映到Lucene的存储结?接口中。M上看Q可以先把Lucene当成一个支持全文烦引的数据库系l?/p>
比较一下Lucene和数据库Q?/p>
| Lucene | 数据?/td> |
|
索引数据源：doc(field1,field2...) doc(field1,field2...) \ indexer / l果输出QHits(doc(field1,field2) doc(field1...)) |
索引数据源：record(field1,field2...) record(field1..) \ SQL: insert/ l果输出Qresults(record(field1,field2..) record(field1...)) |
|
DocumentQ一个需要进行烦引的“单?一个Document由多个字D늻? |
RecordQ记录，包含多个字段 |
|
FieldQ字D?/p> |
FieldQ字D?/td> |
|
HitsQ查询结果集Q由匚w的Documentl成 |
RecordSetQ查询结果集Q由多个Recordl成 |
全文??like "%keyword%"
׃数据库烦引不是ؓ全文索引设计的，因此Q用like "%keyword%"Ӟ数据库烦引是不v作用的，在用like查询Ӟ搜烦q程又变成类g一页M的遍历过E了Q所以对于含有模p查询的数据库服务来_LIKEҎ能的危x极大的。如果是需要对多个关键词进行模p匹配：like"%keyword1%" and like "%keyword2%" ...其效率也可惌知了?/p>
通常比较厚的书籍后面常常附关键词索引表（比如Q北京：12, 34，上vQ?,77……）Q它能够帮助读者比较快地找到相兛_容的늠。而数据库索引能够大大提高查询的速度原理也是一P惛_一下通过书后面的索引查找的速度要比一一地d定w多少倍……而烦引之所以效率高Q另外一个原因是它是排好序的。对于检索系l来说核心是一个排序问题?/p>
所以徏立一个高效检索系l的关键是徏立一个类gU技索引一L反向索引机制Q将数据源（比如多篇文章Q排序顺序存储的同时Q有另外一个排好序的关键词列表Q用于存储关键词==>文章映射关系Q利用这L映射关系索引Q[关键?=>出现关键词的文章~号Q出现次敎ͼ甚至包括位置Qv始偏U量Q结束偏U量Q，出现频率]Q检索过E就是把模糊查询变成多个可以利用索引的精查询的逻辑l合的过E。从而大大提高了多关键词查询的效率，所以，全文索问题归l到最后是一个排序问题?/p>
由此可以看出模糊查询相对数据库的_查询是一个非怸定的问题，q也是大部分数据库对全文索支持有限的原因。Lucene最核心的特征是通过Ҏ的烦引结构实C传统数据库不擅长的全文烦引机Ӟq提供了扩展接口Q以方便针对不同应用的定制?/p>
可以通过一下表格对比一下数据库的模p查询：
| Lucene全文索引引擎 | 数据?/td> | |
| 索引 | 数据源中的数据都通过全文索引一一建立反向索引 | 对于LIKE查询来说Q数据传l的索引是根本用不上的。数据需要逐个便利记录q行GREP式的模糊匚wQ比有烦引的搜烦速度要有多个数量U的下降?/td> |
| 匚w效果 | 通过词元(term)q行匚wQ通过语言分析接口的实玎ͼ可以实现对中文等非英语的支持?/td> | 使用Qlike "%net%" 会把netherlands也匹配出来， 多个关键词的模糊匚wQ用like "%com%net%"Q就不能匚w词序颠倒的xxx.net..xxx.com |
| 匚w?/td> | 有匹配度法Q将匚wE度Q相似度Q比较高的结果排在前面?/td> | 没有匚wE度的控Ӟ比如有记录中net出现5词和出现1ơ的Q结果是一L |
| l果输出 | 通过特别的算法，最匚w度最高的?00条结果输出，l果集是~冲式的批量读取的?/td> | q回所有的l果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放q些临时l果集?/td> |
| 可定制?/td> | 通过不同的语a分析接口实现Q可以方便的定制出符合应用需要的索引规则Q包括对中文的支持） | 没有接口或接口复杂，无法定制 |
| l论 | 高负载的模糊查询应用Q需要负责的模糊查询的规则，索引的资料量比较?/td> | 使用率低Q模p匹配规则简单或者需要模p查询的资料量少 |
全文索和数据库应用最大的不同在于Q让最相关?/span>
?00条结果满?8%以上用户的需求?/font>
Lucene的创C处：
大部分的搜烦Q数据库Q引擎都是用B树结构来l护索引Q烦引的更新会导致大量的IO操作QLucene在实CQ对此稍微有所改进Q不是维护一个烦引文Ӟ而是在扩展烦引的时候不断创建新的烦引文Ӟ然后定期的把q些新的烦引文件合q到原先的大索引中（针对不同的更新策略，Ҏ的大可以调_Q这样在不媄响检索的效率的前提下Q提高了索引的效率?/p>
Lucene和其他一些全文检索系l?应用的比较：
| Lucene | 其他开源全文检索系l?/td> | |
| 增量索引和批量烦?/td> | 可以q行增量的烦?Append)Q可以对于大量数据进行批量烦引，q且接口设计用于优化扚w索引和小扚w的增量烦引?/td> | 很多pȝ只支持批量的索引Q有时数据源有一点增加也需要重建烦引?/td> |
| 数据?/td> | Lucene没有定义具体的数据源Q而是一个文档的l构Q因此可以非常灵zȝ适应各种应用Q只要前端有合适的转换器把数据源{换成相应l构Q?/td> | 很多pȝ只针对网，~Z其他格式文档的灵zL?/td> |
| 索引内容抓取 | Lucene的文档是由多个字D늻成的Q甚臛_以控刉些字D需要进行烦引，那些字段不需要烦引，q一步烦引的字段也分为需要分词和不需要分词的cdQ?br /> 需要进行分词的索引Q比如：标题Q文章内容字D?br /> 不需要进行分词的索引Q比如：作?日期字段 | ~Z通用性，往往文档整个烦引了 |
| 语言分析 | 通过语言分析器的不同扩展实现Q?br />可以qo掉不需要的词：an the of {， 西文语法分析Q将jumps jumped jumper都归l成jumpq行索引/?br />非英文支持：对亚z语aQ阿拉伯语言的烦引支?/td> | ~Z通用接口实现 |
| 查询分析 | 通过查询分析接口的实玎ͼ可以定制自己的查询语法规则： 比如Q?多个关键词之间的 + - and or关系{?/td> | 功能较强?/td> |
| q发讉K | 能够支持多用L使用 | 功能较强?/td> |
关于亚洲语言的的切分词问?Word Segment)
对于中文来说Q全文烦引首先还要解决一个语a分析的问题，对于英文来说Q语句中单词之间是天焉过I格分开的，但亚z语a的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行烦引的话，q个词如何切分出来就是一个很大的问题?br /> 首先Q肯定不能用单个字符?si-gram)为烦引单元，否则查“上”时Q不能让含有“v上”也匚w?br />但一句话Q“北京天安门”，计算机如何按照中文的语言习惯q行切分呢？
“北?天安门?q是“北 ?天安门”？让计机能够按照语言习惯q行切分Q往往需要机器有一个比较丰富的词库才能够比较准的识别句中的单词?br /> 另外一个解决的办法是采用自动切分算法：单词按?元语?bigram)方式切分出来Q比如：
"北京天安? ==> "北京 京天 天安 安门"?br />q样Q在查询的时候，无论是查?北京" q是查询"天安?Q将查询词组按同L规则q行切分Q?北京"Q?天安安门"Q多个关键词之间按与"and"的关pȝ合，同样能够正确地映到相应的烦引中。这U方式对于其他亚z语aQ韩文，日文都是通用的?br /> Z自动切分的最大优Ҏ没有词表l护成本Q实现简单，~点是烦引效率低Q但对于中小型应用来_Z2元语法的切分q是够用的。基?元切分后的烦引一般大和源文件差不多Q而对于英文，索引文g一般只有原文g?0%-40%不同?
| 自动切分 | 词表切分 | |
| 实现 | 实现非常?/td> | 实现复杂 |
| 查询 | 增加了查询分析的复杂E度 | 适于实现比较复杂的查询语法规?/td> |
| 存储效率 | 索引冗余大，索引几乎和原文一样大 | 索引效率高，为原文大的30Q左?/td> |
| l护成本 | 无词表维护成?/td> | 词表l护成本非常高：中日韩等语言需要分别维护?br />q需要包括词频统计等内容 |
| 适用领域 | 嵌入式系l：q行环境资源有限 分布式系l：无词表同步问?br />多语a环境Q无词表l护成本 |
Ҏ询和存储效率要求高的专业搜烦引擎 |
目前比较大的搜烦引擎的语a分析法一般是Z以上2个机制的l合。关于中文的语言分析法Q大家可以在Google查关键词"wordsegment search"能找到更多相关的资料?/p>
Lucene的结构框Ӟ
注意QLucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCCQJavaCompilerCompilerQ纯Java的词法分析生成器Q，所以如果从源代码编译或需要修改其中的QueryParser、定制自q词法分析器，q需要从https://javacc.dev.java.net/下蝲javacc?br /> lucene的组成结构：对于外部应用来说索引模块(index)和检索模?search)是主要的外部应用入口?
| org.apache.Lucene.search/ | 搜烦入口 |
| org.apache.Lucene.index/ | 索引入口 |
| org.apache.Lucene.analysis/ | 语言分析?/td> |
| org.apache.Lucene.queryParser/ | 查询分析?/td> |
| org.apache.Lucene.document/ | 存储l构 |
| org.apache.Lucene.store/ | 底层IO/存储l构 |
| org.apache.Lucene.util/ | 一些公用的数据l构 |
从Lucene学到更多Q?/strong>
摘引Q?a >车东BLOGQ?a >http://www.chedong.com/tech/lucene.html
Luene的确是一个面对对象设计的典范?/p>
q些优点都是非常值得在以后的开发中学习借鉴的。作Z个通用工具包，Lunece的确l予了需要将全文索功能嵌入到应用中的开发者很多的便利?br /> 此外Q通过对Lucene的学习和使用Q我也更深刻地理解了Z么很多数据库优化设计中要求，比如Q?/p>
优秀的开放源代码全文索系lLucene
雪地雏鹰-[信息索]
Lucene研究
Lucene实现的全文检?/a>
]]>
作者： 车东 Email: chedongATbigfoot.com/chedongATchedong.com
写于Q?002/08 最后更斎ͼ
02/22/2006 14:42:55
Feed Back >> (Read this before you ask question)
版权声明Q可以Q意{载，转蝲时请务必以超链接形式标明文章原始出处和作者信息及本声?br />http://www.chedong.com/tech/lucene.html
关键词：Lucene java full-text search engine Chinese word segment
内容摘要Q?/p>
Lucene是一个基于Java的全文烦引工具包?/p>
- ZJava的全文烦引引擎Lucene介：关于作者和Lucene的历?/a>
- 全文索的实现QLuene全文索引和数据库索引的比?/a>
- 中文切分词机制简介：Z词库和自动切分词法的比?/a>
- 具体的安装和使用介：pȝl构介绍和演C?/a>
- Hacking LuceneQ简化的查询分析器，删除的实玎ͼ定制的排序，应用接口的扩?/a>
- 从Lucene我们q可以学C?/a>
Lucene不是一个完整的全文索引应用Q而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各U应用中实现针对应用的全文烦?索功能?/p>
Lucene的作者：Lucene的A献?a >Doug Cutting是一位资深全文烦?索专Ӟ曄是V-Twin搜烦引擎(Apple的Copland操作pȝ的成׃一)的主要开发者，后在Excite担Q高pȝ架构设计师，目前从事于一些INTERNET底层架构的研I。他贡献出的Lucene的目标是为各U中型应用E序加入全文索功能?/p>
Lucene的发展历E：早先发布在作者自qwww.lucene.comQ后来发布在SourceForgeQ?001q年底成为APACHE基金会jakarta的一个子目Q?a >http://jakarta.apache.org/lucene/
已经有很多Java目都用了Lucene作ؓ其后台的全文索引引擎Q比较著名的有：
- J iveQWEB论坛pȝQ?
- EyebrowsQ邮件列表HTML归档/览/查询pȝQ本文的主要参考文档?a >TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrowspȝ的主要开发者之一Q而EyeBrows已经成ؓ目前APACHE目的主要邮件列表归档系l?
- Cocoon:ZXML的web发布框架Q全文检索部分用了Lucene
-
Eclipse:ZJava的开攑ּ发^収ͼ帮助部分的全文烦引用了Lucene
对于中文用户来说Q最兛_的问题是其是否支持中文的全文索。但通过后面对于Lucene的结构的介绍Q你会了解到׃Lucene良好架构设计Q对中文的支持只需对其语言词法分析接口q行扩展p实现对中文检索的支持?/p>
Lucene的API接口设计的比较通用Q输入输出结构都很像数据库的?=>记录==>字段Q所以很多传l的应用的文件、数据库{都可以比较方便的映到Lucene的存储结?接口中。M上看Q可以先?b>Lucene当成一个支持全文烦引的数据库系l?/b>?/p>
比较一下Lucene和数据库Q?/p>
| Lucene | 数据?/td> |
索引数据源：doc(field1,field2...) doc(field1,field2...) |
索引数据源：record(field1,field2...) record(field1..) |
| DocumentQ一个需要进行烦引的“单元?br />一个Document由多个字D늻?/td> | RecordQ记录，包含多个字段 |
| FieldQ字D?/td> | FieldQ字D?/td> |
| HitsQ查询结果集Q由匚w的Documentl成 | RecordSetQ查询结果集Q由多个Recordl成 |
全文??like "%keyword%"
通常比较厚的书籍后面常常附关键词索引表（比如Q北京：12, 34，上vQ?,77……）Q它能够帮助读者比较快地找到相兛_容的늠。而数据库索引能够大大提高查询的速度原理也是一P惛_一下通过书后面的索引查找的速度要比一一地d定w多少倍……而烦引之所以效率高Q另外一个原因是它是排好序的?b>对于索系l来说核心是一个排序问?/b>?/p>
׃数据库烦引不是ؓ全文索引设计的，因此Q?b>使用like "%keyword%"Ӟ数据库烦引是不v作用?/b>Q在使用like查询Ӟ搜烦q程又变成类g一页M的遍历过E了Q所以对于含有模p查询的数据库服务来_LIKEҎ能的危x极大的。如果是需要对多个关键词进行模p匹配：like"%keyword1%" and like "%keyword2%" ...其效率也可惌知了?/p>
所以徏立一个高效检索系l的关键是徏立一个类gU技索引一L反向索引机制Q将数据源（比如多篇文章Q排序顺序存储的同时Q有另外一个排好序的关键词列表Q用于存储关键词==>文章映射关系Q利用这L映射关系索引Q[关键?=>出现关键词的文章~号Q出现次敎ͼ甚至包括位置Qv始偏U量Q结束偏U量Q，出现频率]Q检索过E就是把模糊查询变成多个可以利用索引的精查询的逻辑l合的过E?/b>。从而大大提高了多关键词查询的效率，所以，全文索问题归l到最后是一个排序问题?/p>
由此可以看出模糊查询相对数据库的_查询是一个非怸定的问题，q也是大部分数据库对全文索支持有限的原因。Lucene最核心的特征是通过Ҏ的烦引结构实C传统数据库不擅长的全文烦引机Ӟq提供了扩展接口Q以方便针对不同应用的定制?/p>
可以通过一下表格对比一下数据库的模p查询：
| Lucene全文索引引擎 | 数据?/td> | |
| 索引 | 数据源中的数据都通过全文索引一一建立反向索引 | 对于LIKE查询来说Q数据传l的索引是根本用不上的。数据需要逐个便利记录q行GREP式的模糊匚wQ比有烦引的搜烦速度要有多个数量U的下降?/td> |
| 匚w效果 | 通过词元(term)q行匚wQ通过语言分析接口的实玎ͼ可以实现对中文等非英语的支持?/td> | 使用Qlike "%net%" 会把netherlands也匹配出来， 多个关键词的模糊匚wQ用like "%com%net%"Q就不能匚w词序颠倒的xxx.net..xxx.com |
| 匚w?/td> | 有匹配度法Q将匚wE度Q相似度Q比较高的结果排在前面?/td> | 没有匚wE度的控Ӟ比如有记录中net出现5词和出现1ơ的Q结果是一L?/td> |
| l果输出 | 通过特别的算法，最匚w度最高的?00条结果输出，l果集是~冲式的批量读取的?/td> | q回所有的l果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放q些临时l果集?/td> |
| 可定制?/td> | 通过不同的语a分析接口实现Q可以方便的定制出符合应用需要的索引规则Q包括对中文的支持） | 没有接口或接口复杂，无法定制 |
| l论 | 高负载的模糊查询应用Q需要负责的模糊查询的规则，索引的资料量比较?/td> | 使用率低Q模p匹配规则简单或者需要模p查询的资料量少 |
全文索和数据库应用最大的不同在于Q让
最相关?/span>
?00条结果满?8%以上用户的需?br />
Lucene的创C处：
大部分的搜烦Q数据库Q引擎都是用B树结构来l护索引Q烦引的更新会导致大量的IO操作QLucene在实CQ对此稍微有所改进Q不是维护一个烦引文Ӟ而是在扩展烦引的时候不断创建新的烦引文Ӟ然后定期的把q些新的烦引文件合q到原先的大索引中（针对不同的更新策略，Ҏ的大可以调_Q这样在不媄响检索的效率的前提下Q提高了索引的效率?/p>
Lucene和其他一些全文检索系l?应用的比较：
| Lucene | 其他开源全文检索系l?/td> | |
| 增量索引和批量烦?/td> | 可以q行增量的烦?Append)Q可以对于大量数据进行批量烦引，q且接口设计用于优化扚w索引和小扚w的增量烦引?/td> | 很多pȝ只支持批量的索引Q有时数据源有一点增加也需要重建烦引?/td> |
| 数据?/td> | Lucene没有定义具体的数据源Q而是一个文档的l构Q因此可以非常灵zȝ适应各种应用Q只要前端有合适的转换器把数据源{换成相应l构Q， | 很多pȝ只针对网，~Z其他格式文档的灵zL?/td> |
| 索引内容抓取 | Lucene的文档是由多个字D늻成的Q甚臛_以控刉些字D需要进行烦引，那些字段不需要烦引，q一步烦引的字段也分为需要分词和不需要分词的cdQ?br /> 需要进行分词的索引Q比如：标题Q文章内容字D?br /> 不需要进行分词的索引Q比如：作?日期字段 | ~Z通用性，往往文档整个烦引了 |
| 语言分析 | 通过语言分析器的不同扩展实现Q?br />可以qo掉不需要的词：an the of {， 西文语法分析Q将jumps jumped jumper都归l成jumpq行索引/?br />非英文支持：对亚z语aQ阿拉伯语言的烦引支?/td> | ~Z通用接口实现 |
| 查询分析 | 通过查询分析接口的实玎ͼ可以定制自己的查询语法规则： 比如Q?多个关键词之间的 + - and or关系{?/td> | |
| q发讉K | 能够支持多用L使用 |
对于中文来说Q全文烦引首先还要解决一个语a分析的问题，对于英文来说Q语句中单词之间是天焉过I格分开的，但亚z语a的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行烦引的话，q个词如何切分出来就是一个很大的问题?/p>
首先Q肯定不能用单个字符?si-gram)为烦引单元，否则查“上”时Q不能让含有“v上”也匚w?/p>
但一句话Q“北京天安门”，计算机如何按照中文的语言习惯q行切分呢？
“北?天安门?q是“北 ?天安门”？让计机能够按照语言习惯q行切分Q往往需要机器有一个比较丰富的词库才能够比较准的识别句中的单词?/p>
另外一个解决的办法是采用自动切分算法：单词按?元语?bigram)方式切分出来Q比如：
"北京天安? ==> "北京 京天 天安 安门"?/p>
q样Q在查询的时候，无论是查?北京" q是查询"天安?Q将查询词组按同L规则q行切分Q?北京"Q?天安安门"Q多个关键词之间按与"and"的关pȝ合，同样能够正确地映到相应的烦引中。这U方式对于其他亚z语aQ韩文，日文都是通用的?/p>
Z自动切分的最大优Ҏ没有词表l护成本Q实现简单，~点是烦引效率低Q但对于中小型应用来_Z2元语法的切分q是够用的。基?元切分后的烦引一般大和源文件差不多Q而对于英文，索引文g一般只有原文g?0%-40%不同Q?/p>
|
|
自动切分 | 词表切分 |
| 实现 | 实现非常?/td> | 实现复杂 |
| 查询 | 增加了查询分析的复杂E度Q?/td> | 适于实现比较复杂的查询语法规?/td> |
| 存储效率 | 索引冗余大，索引几乎和原文一样大 | 索引效率高，为原文大的30Q左?/td> |
| l护成本 | 无词表维护成?/td> | 词表l护成本非常高：中日韩等语言需要分别维护?br />q需要包括词频统计等内容 |
| 适用领域 | 嵌入式系l：q行环境资源有限 分布式系l：无词表同步问?br />多语a环境Q无词表l护成本 |
Ҏ询和存储效率要求高的专业搜烦引擎 |
目前比较大的搜烦引擎的语a分析法一般是Z以上2个机制的l合。关于中文的语言分析法Q大家可以在Google查关键词"wordsegment search"能找到更多相关的资料?/p>
下蝲Q?a >http://jakarta.apache.org/lucene/
注意QLucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCCQJavaCompilerCompilerQ纯Java的词法分析生成器Q，所以如果从源代码编译或需要修改其中的QueryParser、定制自q词法分析器，q需要从https://javacc.dev.java.net/下蝲javacc?/p>
lucene的组成结构：对于外部应用来说索引模块(index)和检索模?search)是主要的外部应用入口
| org.apache.Lucene.search/ | 搜烦入口 |
| org.apache.Lucene.index/ | 索引入口 |
| org.apache.Lucene.analysis/ | 语言分析?/td> |
| org.apache.Lucene.queryParser/ | 查询分析?/td> |
| org.apache.Lucene.document/ | 存储l构 |
| org.apache.Lucene.store/ | 底层IO/存储l构 |
| org.apache.Lucene.util/ | 一些公用的数据l构 |
单的例子演示一下Lucene的用方法：
索引q程Q从命o行读取文件名Q多个）Q将文g分\?path字段)和内?body字段)2个字D进行存储，q对内容q行全文索引Q烦引的单位是Document对象Q每个Document对象包含多个字段Field对象Q针对不同的字段属性和数据输出的需求，对字D还可以选择不同的烦?存储字段规则Q列表如下：| Ҏ | 切词 | 索引 | 存储 | 用?/th> |
|---|---|---|---|---|
| Field.Text(String name, String value) | Yes | Yes | Yes | 切分词烦引ƈ存储Q比如：标题Q内容字D?/td> |
| Field.Text(String name, Reader value) | Yes | Yes | No | 切分词烦引不存储Q比如：META信息Q?br />不用于返回显C，但需要进行检索内?/td> |
| Field.Keyword(String name, String value) | No | Yes | Yes | 不切分烦引ƈ存储Q比如：日期字段 |
| Field.UnIndexed(String name, String value) | No | No | Yes | 不烦引，只存储，比如Q文件\?/td> |
| Field.UnStored(String name, String value) | Yes | Yes | No | 只全文烦引，不存?/td> |
public class IndexFiles {
//使用ҎQ? IndexFiles [索引输出目录] [索引的文件列表] ...
public static void main(String[] args) throws Exception {
String indexPath = args[0];
IndexWriter writer;
//用指定的语言分析器构造一个新的写索引器（W?个参数表C是否ؓq加索引Q?br /> writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);
for (int i=1; i<args.length; i++) {
System.out.println("Indexing file " + args[i]);
InputStream is = new FileInputStream(args[i]);
//构造包?个字DField的Document对象
//一个是路径path字段Q不索引Q只存储
//一个是内容body字段Q进行全文烦引，q存?br /> Document doc = new Document();
doc.add(Field.UnIndexed("path", args[i]));
doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
//文档写入烦?br /> writer.addDocument(doc);
is.close();
};
//关闭写烦引器
writer.close();
}
}
索引q程中可以看刎ͼ
- 语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的Q虽然lucene~省提供?个比较通用的分析器SimpleAnalyser和StandardAnalyserQ这2个分析器~省都不支持中文Q所以要加入对中文语a的切分规则，需要修改这2个分析器?
- Luceneq没有规定数据源的格式，而只提供了一个通用的结构（Document对象Q来接受索引的输入，因此输入的数据源可以是：数据库，WORD文档QPDF文档QHTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象卛_q行索引?
- 对于大批量的数据索引Q还可以通过调整IndexerWrite的文件合q率属性（mergeFactorQ来提高扚w索引的效率?
索过E和l果昄Q?/p>
搜烦l果q回的是Hits对象Q可以通过它再讉KDocument==>Field中的内容?/p>
假设Ҏbody字段q行全文索，可以查询结果的path字段和相应查询的匚w?score)打印出来Q?/p>
public class Search {
public static void main(String[] args) throws Exception {
String indexPath = args[0], queryString = args[1];
//指向索引目录的搜索器
Searcher searcher = new IndexSearcher(indexPath);
//查询解析器：使用和烦引同L语言分析?br /> Query query = QueryParser.parse(queryString, "body",
new SimpleAnalyzer());
//搜烦l果使用Hits存储
Hits hits = searcher.search(query);
//通过hits可以讉K到相应字D늚数据和查询的匚w?br /> for (int i=0; i<hits.length(); i++) {
System.out.println(hits.doc(i).get("path") + "; Score: " +
hits.score(i));
};
}
}在整个检索过E中Q语a分析器，查询分析器，甚至搜烦器（SearcherQ都是提供了抽象的接口，可以Ҏ需要进行定制?
化的查询分析?/b>
个h感觉lucene成ؓJAKARTA目后，d了太多的旉用于调试日趋复杂QueryParserQ而其中大部分是大多数用户q不很熟悉的Q目前LUCENE支持的语法：
Query ::= ( Clause )*
Clause ::= ["+", "-"] [<TERM> ":"] ( <TERM> | "(" Query ")")
中间的逻辑包括Qand or + - &&||{符P而且q有"短语查询"和针对西文的前缀/模糊查询{，个h感觉对于一般应用来_q些功能有一些华而不实，其实能够实现目前cM于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择?/p>
d修改删除指定记录QDocumentQ?/b>
Lucene提供了烦引的扩展机制Q因此烦引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另徏索引Q然后利用IndexReader.delete(Termterm)Ҏ通过q个记录ID删除相应的Document?/p>
Ҏ某个字段值的排序功能
lucene~省是按照自q相关度算法（scoreQ进行结果排序的Q但能够Ҏ其他字段q行l果排序是一个在LUCENE的开发邮件列表中l常提到的问题，很多原先Z数据库应用都需要除了基于匹配度QscoreQ以外的排序功能。而从全文索的原理我们可以了解刎ͼM不基于烦引的搜烦q程效率都会D效率非常的低Q如果基于其他字D늚排序需要在搜烦q程中访问存储字D，速度回大大降低，因此非常是不可取的?/p>
但这里也有一个折中的解决ҎQ在搜烦q程中能够媄响排序结果的只有索引中已l存储的docID和scoreq?个参敎ͼ所以，Zscore以外的排序，其实可以通过数据源预先排好序，然后ҎdocIDq行排序来实现。这样就避免了在LUCENE搜烦l果外对l果再次q行排序和在搜烦q程中访问不在烦引中的某个字D倹{?/p>
q里需要修改的是IndexSearcher中的HitCollectorq程Q?/p>
...
scorer.score(new HitCollector() {
private float minScore = 0.0f;
public final void collect(int doc, float score) {
if (score > 0.0f && // ignore zeroed buckets
(bits==null || bits.get(doc))) { // skip docs not in bits
totalHits[0]++;
if (score >= minScore) {
/* 原先QLucenedocID和相应的匚w度score例入l果命中列表中：
* hq.put(new ScoreDoc(doc, score)); // update hit queue
* 如果用doc ?1/doc 代替 scoreQ就实现了根据docID排或逆排
* 假设数据源烦引时已经按照某个字段排好了序Q而结果根据docID排序也就实现?br /> * 针对某个字段的排序，甚至可以实现更复杂的score和docID的拟合?br /> */
hq.put(new ScoreDoc(doc, (float) 1/doc ));
if (hq.size() > nDocs) { // if hit queue overfull
hq.pop(); // remove lowest in hit queue
minScore = ((ScoreDoc)hq.top()).score; // reset minScore
}
}
}
}
}, reader.maxDoc());
更通用的输入输出接?/b>
虽然lucene没有定义一个确定的输入文档格式Q但来多的h惛_使用一个标准的中间格式作ؓLucene的数据导入接口，然后其他数据Q比如PDF只需要通过解析器{换成标准的中间格式就可以q行数据索引了。这个中间格式主要以XMLZQ类似实现已l不?Q?个：
数据? WORD PDF HTML DB other
\ | | | /
XML中间格式
|
Lucene INDEX
目前q没有针对MSWord文档的解析器Q因为Word文档和基于ASCII的RTF文档不同Q需要用COM对象机制解析。这个是我在Google上查的相兌料：http://www.intrinsyc.com/products/enterprise_applications.asp
另外一个办法就是把Word文档转换成textQ?a >http://www.winfield.demon.nl/index.html
索引q程优化
索引一般分2U情况，一U是批量的索引扩展Q一U是大批量的索引重徏。在索引q程中，q不是每ơ新的DOC加入q去索引都重新进行一ơ烦引文件的写入操作Q文件I/O是一仉常消耗资源的事情Q?/p>
Lucene先在内存中进行烦引操作，q根据一定的扚wq行文g的写入。这个批ơ的间隔大Q文件的写入ơ数少Q但占用内存会很多。反之占用内存少Q但文gIO操作频繁Q烦引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造烦引器后根据应用环境的情况充分利用内存减少文g的操作。根据我的用经验：~省Indexer是每20条记录烦引后写入一ơ，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左叟?br />
搜烦q程优化
lucene支持内存索引Q这L搜烦比基于文件的I/O有数量的速度提升?br />http://www.onjava.com/lpt/a/3273
而尽可能减少IndexSearcher的创建和Ҏ索结果的前台的缓存也是必要的?br />
Lucene面向全文索的优化在于首次索引索后Qƈ不把所有的记录QDocumentQ具体内容读取出来，而v只将所有结果中匚w度最高的?00条结果（TopDocsQ的ID攑ֈl果集缓存中q返回，q里可以比较一下数据库索：如果是一?0,000条的数据库检索结果集Q数据库是一定要把所有记录内定w取得以后再开始返回给应用l果集的。所以即使检索匹配L很多QLucene的结果集占用的内存空间也不会很多。对于一般的模糊索应用是用不到这么多的结果的Q头100条已l可以满?0%以上的检索需求?br />
如果首批~存l果数用完后q要d更后面的l果时Searcher会再ơ检索ƈ生成一个上ơ的搜烦~存数大1倍的~存Qƈ再重新向后抓取。所以如果构造一个SearcherL1Q?20条结果，Searcher其实是进行了2ơ搜索过E：?00条取完后Q缓存结果用完，Searcher重新索再构造一?00条的l果~存Q依此类推，400条缓存，800条缓存。由于每ơSearcher对象消失后，q些~存也访问那不到了，你有可能惛_l果记录~存下来Q缓存数量保证?00以下以充分利用首ơ的l果~存Q不让Lucene费多次索，而且可以分q行l果~存?br />
Lucene的另外一个特Ҏ在收集结果的q程中将匚w度低的结果自动过滤掉了。这也是和数据库应用需要将搜烦的结果全部返回不同之处?/p>
我的一些尝?/a>Q?/p> Luene的确是一个面对对象设计的典范 q些优点都是非常值得在以后的开发中学习借鉴的。作Z个通用工具包，Lunece的确l予了需要将全文索功能嵌入到应用中的开发者很多的便利?/p> 此外Q通过对Lucene的学习和使用Q我也更深刻地理解了Z么很多数据库优化设计中要求，比如Q?/p> 参考资料： Apache: Lucene Project The Lucene search engine: Powerful, flexible, and free Lucene Tutorial Notes on distributed searching with Lucene 中文语言的切分词 搜烦引擎工具介绍 Lucene作者Cutting的几论文和专利 Lucene?NET实现QdotLucene Lucene作者Cutting的另外一个项目：ZJava的搜索引擎Nutch 关于Z词表和N-Gram的切分词比较 特别感谢Q?br />前网易CTO许良?Jack Xu)l我的指|是您我带入了搜索引擎这个行业?/p>原文出处Q?lt;a>http://www.chedong.com/tech/lucene.html</a>
http://jakarta.apache.org/lucene/
Lucene开?用户邮g列表归档
Lucene-dev@jakarta.apache.org
Lucene-user@jakarta.apache.org
http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html
http://www.darksleep.com/puff/lucene/lucene.html
http://home.clara.net/markharwood/lucene/
http://www.google.com/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment
http://searchtools.com/
http://lucene.sourceforge.net/publications.html
http://sourceforge.net/projects/dotlucene/
http://www.nutch.org/ http://sourceforge.net/projects/nutch/
http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html
2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座：非常详细的Lucene架构解说
<<q回