Lucene是一个基于Java的全文烦(ch)引工具包?/p>
- ZJava的全文烦(ch)引引擎Lucene介：(x)关于作者和Lucene的历?/a>
- 全文(g)索的实现QLuene全文索引和数据库索引的比?/a>
- 中文切分词机制简介：(x)Z词库和自动切分词法的比?/a>
- 具体的安装和使用介：(x)pȝl构介绍和演C?/a>
- Hacking LuceneQ简化的查询分析器，删除的实玎ͼ定制的排序，应用接口的扩?/a>
- 从Lucene我们q可以学C?/a>
Lucene不是一个完整的全文索引应用Q而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各U应用中实现针对应用的全文烦(ch)?(g)索功能?/p>
Lucene的作者：(x)Lucene的A(ch)献?a style="text-decoration: underline; color: #3165ce; ">Doug Cutting是一位资深全文烦(ch)?(g)索专Ӟ曄是V-Twin搜烦(ch)引擎(Apple的Copland操作pȝ的成׃一)的主要开发者，后在Excite担Q高pȝ架构设计师，目前从事于一些INTERNET底层架构的研I。他贡献出的Lucene的目标是为各U中型应用E序加入全文(g)索功能?/p>
Lucene的发展历E：(x)早先发布在作者自qwww.lucene.comQ后来发布在SourceForgeQ?001q年底成为APACHE基金?x)jakarta的一个子目Q?a style="text-decoration: underline; color: #3165ce; ">http://jakarta.apache.org/lucene/
已经有很多Java目都用了(jin)Lucene作ؓ(f)其后台的全文索引引擎Q比较著名的有：(x)
- JiveQWEB论坛pȝQ?/li>
- EyebrowsQ邮件列表HTML归/览/查询pȝQ本文的主要参考文?#8220;TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrowspȝ的主要开发者之一Q而EyeBrows已经成ؓ(f)目前APACHE目的主要邮件列表归档系l?/li>
- Cocoon:ZXML的web发布框架Q全文检索部分用了(jin)Lucene
-
Eclipse:ZJava的开攑ּ发^収ͼ帮助部分的全文烦(ch)引用了(jin)Lucene
对于中文用户来说Q最兛_(j)的问题是其是否支持中文的全文(g)索。但通过后面对于Lucene的结构的介绍Q你?x)?jin)解到׃Lucene良好架构设计Q对中文的支持只需对其语言词法分析接口q行扩展p实现对中文检索的支持?/p>
Lucene的API接口设计的比较通用Q输入输出结构都很像数据库的?=>记录==>字段Q所以很多传l的应用的文件、数据库{都可以比较方便的映到Lucene的存储结?接口中。M上看Q可以先?strong>Lucene当成一个支持全文烦(ch)引的数据库系l?/strong>?/p>
比较一下Lucene和数据库Q?/p>
| Lucene | 数据?/td> |
索引数据源：(x)doc(field1,field2...) doc(field1,field2...) |
索引数据源：(x)record(field1,field2...) record(field1..) |
| DocumentQ一个需要进行烦(ch)引的“单元” 一个Document由多个字D늻?/td> | RecordQ记录，包含多个字段 |
| FieldQ字D?/td> | FieldQ字D?/td> |
| HitsQ查询结果集Q由匚w的Documentl成 | RecordSetQ查询结果集Q由多个Recordl成 |
全文(g)?≠ like "%keyword%"
通常比较厚的书籍后面常常附关键词索引表（比如Q北京：(x)12, 34， 上vQ?,77?#8230;…Q，它能够帮助读者比较快地找到相兛_容的늠。而数据库索引能够大大提高查询的速度原理也是一P惛_一下通过书后面的索引查找的速度要比一一地d定w多少?#8230;…而烦(ch)引之所以效率高Q另外一个原因是它是排好序的?strong>对于(g)索系l来说核?j)是一个排序问?/strong>?/p>
׃数据库烦(ch)引不是ؓ(f)全文索引设计的，因此Q?strong>使用like "%keyword%"Ӟ数据库烦(ch)引是不v作用?/strong>Q在使用like查询Ӟ搜烦(ch)q程又变成类g一页M的遍历过E了(jin)Q所以对于含有模p查询的数据库服务来_(d)LIKEҎ(gu)能的危x(chng)极大的。如果是需要对多个关键词进行模p匹配：(x)like"%keyword1%" and like "%keyword2%" ...其效率也可惌知?jin)?/p>
所以徏立一个高效检索系l的关键是徏立一个类gU技索引一L(fng)反向索引机制Q将数据源（比如多篇文章Q排序顺序存储的同时Q有另外一个排好序的关键词列表Q用于存储关键词==>文章映射关系Q利用这L(fng)映射关系索引Q[关键?=>出现关键词的文章~号Q出现次敎ͼ甚至包括位置Qv始偏U量Q结束偏U量Q，出现频率]Q检索过E就是把模糊查询变成多个可以利用索引的精查询的逻辑l合的过E?/strong>。从而大大提高(sh)(jin)多关键词查询的效率，所以，全文(g)索问题归l到最后是一个排序问题?/p>
由此可以看出模糊查询相对数据库的_查询是一个非怸定的问题，q也是大部分数据库对全文(g)索支持有限的原因。Lucene最核心(j)的特征是通过Ҏ(gu)的烦(ch)引结构实C(jin)传统数据库不擅长的全文烦(ch)引机Ӟq提供了(jin)扩展接口Q以方便针对不同应用的定制?/p>
可以通过一下表格对比一下数据库的模p查询：(x) 全文(g)索和数据库应用最大的不同在于Q让最相关?/span>?00条结果满?8%以上用户的需?br />
大部分的搜烦(ch)Q数据库Q引擎都是用B?wi)结构来l护索引Q烦(ch)引的更新?x)导致大量的IO操作QLucene在实CQ对此稍微有所改进Q不是维护一个烦(ch)引文Ӟ而是在扩展烦(ch)引的时候不断创建新的烦(ch)引文Ӟ然后定期的把q些新的烦(ch)引文件合q到原先的大索引中（针对不同的更新策略，Ҏ(gu)的大可以调_(d)(j)Q这样在不媄(jing)响检索的效率的前提下Q提高(sh)(jin)索引的效率?/p>
Lucene和其他一些全文检索系l?应用的比较：(x) 对于中文来说Q全文烦(ch)引首先还要解决一个语a分析的问题，对于英文来说Q语句中单词之间是天焉过I格分开的，但亚z语a的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“?#8221;q行索引的话Q这个词如何切分出来是一个很大的问题?/p>
首先Q肯定不能用单个字符?si-gram)为烦(ch)引单元，否则?#8220;上v”Ӟ不能让含?#8220;上”也匹配?/p>
但一句话Q?#8220;北京天安?#8221;Q计机如何按照中文的语a?fn)惯q行切分呢？ 另外一个解决的办法是采用自动切分算法：(x)单词按?元语?bigram)方式切分出来Q比如：(x) q样Q在查询的时候，无论是查?北京" q是查询"天安?Q将查询词组按同L(fng)规则q行切分Q?北京"Q?天安安门"Q多个关键词之间按与"and"的关pȝ合，同样能够正确地映到相应的烦(ch)引中。这U方式对于其他亚z语aQ韩文，日文都是通用的?/p>
Z自动切分的最大优Ҏ(gu)没有词表l护成本Q实现简单，~点是烦(ch)引效率低Q但对于中小型应用来_(d)Z2元语法的切分q是够用的。基?元切分后的烦(ch)引一般大和源文件差不多Q而对于英文，索引文g一般只有原文g?0%-40%不同Q?/p>
目前比较大的搜烦(ch)引擎的语a分析法一般是Z以上2个机制的l合。关于中文的语言分析法Q大家可以在Google查关键词"wordsegment search"能找到更多相关的资料?/p>
下蝲Q?a style="text-decoration: underline; color: #3165ce; ">http://jakarta.apache.org/lucene/ 注意QLucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCCQJavaCompilerCompilerQ纯Java的词法分析生成器Q，所以如果从源代码编译或需要修改其中的QueryParser、定制自q词法分析器，q需要从https://javacc.dev.java.net/下蝲javacc?/p>
lucene的组成结构：(x)对于外部应用来说索引模块(index)和检索模?search)是主要的外部应用入口 单的例子演示一下Lucene的用方法：(x) 索引q程中可以看刎ͼ(x) (g)索过E和l果昄Q?/p>
搜烦(ch)l果q回的是Hits对象Q可以通过它再讉KDocument==>Field中的内容?/p>
假设Ҏ(gu)body字段q行全文(g)索，可以查询结果的path字段和相应查询的匚w?score)打印出来Q?/p>
化的查询分析?/strong> 个h感觉lucene成ؓ(f)JAKARTA目后，d?jin)太多的旉用于调试日趋复杂QueryParserQ而其中大部分是大多数用户q不很熟(zhn)的Q目前LUCENE支持的语法：(x) Query ::= ( Clause )* 中间的逻辑包括Qand or + - &&||{符P而且q有"短语查询"和针对西文的前缀/模糊查询{，个h感觉对于一般应用来_(d)q些功能有一些华而不实，其实能够实现目前cM于Google的查询语句分析功能其实对于大多数用户来说已经够了(jin)。所以，Lucene早期版本的QueryParser仍是比较好的选择?/p>
d修改删除指定记录QDocumentQ?/strong> Lucene提供?jin)?ch)引的扩展机制Q因此烦(ch)引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另徏索引Q然后利用IndexReader.delete(Termterm)Ҏ(gu)通过q个记录ID删除相应的Document?/p>
Ҏ(gu)某个字段值的排序功能 lucene~省是按照自q相关度算法（scoreQ进行结果排序的Q但能够Ҏ(gu)其他字段q行l果排序是一个在LUCENE的开发邮件列表中l常提到的问题，很多原先Z数据库应用都需要除?jin)基于匹配度QscoreQ以外的排序功能。而从全文(g)索的原理我们可以?jin)解刎ͼM不基于烦(ch)引的搜烦(ch)q程效率都会(x)D效率非常的低Q如果基于其他字D늚排序需要在搜烦(ch)q程中访问存储字D，速度回大大降低，因此非常是不可取的?/p>
但这里也有一个折?sh)的解决?gu)Q在搜烦(ch)q程中能够媄(jing)响排序结果的只有索引中已l存储的docID和scoreq?个参敎ͼ所以，Zscore以外的排序，其实可以通过数据源预先排好序，然后Ҏ(gu)docIDq行排序来实现。这样就避免?jin)在LUCENE搜烦(ch)l果外对l果再次q行排序和在搜烦(ch)q程中访问不在烦(ch)引中的某个字D倹{?/p>
q里需要修改的是IndexSearcher中的HitCollectorq程Q?/p>
更通用的输入输出接?/strong> 虽然lucene没有定义一个确定的输入文档格式Q但来多的h惛_使用一个标准的中间格式作ؓ(f)Lucene的数据导入接口，然后其他数据Q比如PDF只需要通过解析器{换成标准的中间格式就可以q行数据索引?jin)。这个中间格式主要以XMLZQ类似实现已l不?Q?个：(x) 目前q没有针对MSWord文档的解析器Q因为Word文档和基于ASCII的RTF文不同Q需要用COM对象机制解析。这个是我在Google上查的相兌料：(x)http://www.intrinsyc.com/products/enterprise_applications.asp 索引一般分2U情况，一U是批量的索引扩展Q一U是大批量的索引重徏。在索引q程中，q不是每ơ新的DOC加入q去索引都重新进行一ơ烦(ch)引文件的写入操作Q文件I/O是一仉常消耗资源的事情Q?/p>
Lucene先在内存?sh)进行?ch)引操作，q根据一定的扚wq行文g的写入。这个批ơ的间隔大Q文件的写入ơ数少Q但占用内存?sh)(x)很多。反之占用内存少Q但文gIO操作频繁Q烦(ch)引速度?x)很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造烦(ch)引器后根据应用环境的情况充分利用内存减少文g的操作。根据我的用经验：(x)~省Indexer是每20条记录烦(ch)引后写入一ơ，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左叟?br />
搜烦(ch)q程优化 lucene支持内存索引Q这L(fng)搜烦(ch)比基于文件的I/O有数量的速度提升?br />
http://www.onjava.com/lpt/a/3273 Lucene面向全文(g)索的优化在于首次索引(g)索后Qƈ不把所有的记录QDocumentQ具体内容读取出来，而v只将所有结果中匚w度最高的?00条结果（TopDocsQ的ID攑ֈl果集缓存(sh)q返回，q里可以比较一下数据库(g)索：(x)如果是一?0,000条的数据库检索结果集Q数据库是一定要把所有记录内定w取得以后再开始返回给应用l果集的。所以即使检索匹配L很多QLucene的结果集占用的内存空间也不会(x)很多。对于一般的模糊(g)索应用是用不到这么多的结果的Q头100条已l可以满?0%以上的检索需求?br />
如果首批~存l果数用完后q要d更后面的l果时Searcher?x)再ơ检索ƈ生成一个上ơ的搜烦(ch)~存数大1倍的~存Qƈ再重新向后抓取。所以如果构造一个SearcherL1Q?20条结果，Searcher其实是进行了(jin)2ơ搜索过E：(x)?00条取完后Q缓存结果用完，Searcher重新(g)索再构造一?00条的l果~存Q依此类推，400条缓存，800条缓存。由于每ơSearcher对象消失后，q些~存?sh)访问那不到了(jin)，你有可能惛_l果记录~存?sh)来Q缓存数量保证?00以下以充分利用首ơ的l果~存Q不让Lucene费多次(g)索，而且可以分q行l果~存?br />
Lucene的另外一个特Ҏ(gu)在收集结果的q程中将匚w度低的结果自动过滤掉?jin)。这也是和数据库应用需要将搜烦(ch)的结果全部返回不同之处?/p>
我的一些尝?/a>Q?/p>
Luene的确是一个面对对象设计的典范 q些优点都是非常值得在以后的开发中学习(fn)借鉴的。作Z个通用工具包，Lunece的确l予?jin)需要将全文(g)索功能嵌入到应用中的开发者很多的便利?/p>
此外Q通过对Lucene的学?fn)和使用Q我也更深刻地理解了(jin)Z么很多数据库优化设计中要求，比如Q?/p>
参考资料：(x) Apache: Lucene Project The Lucene search engine: Powerful, flexible, and free Lucene Tutorial Notes on distributed searching with Lucene 中文语言的切分词 搜烦(ch)引擎工具介绍 Lucene作者Cutting的几论文和专利 Lucene?NET实现QdotLucene Lucene作者Cutting的另外一个项目：(x)ZJava的搜索引擎Nutch 关于Z词表和N-Gram的切分词比较 特别感谢Q?br />
前网易CTO许良?Jack Xu)l我的指|(x)是?zhn)我带入了(jin)搜索引擎这个行业?/p>
Lucene全文索引引擎
数据?/td>
索引
数据源中的数据都通过全文索引一一建立反向索引
对于LIKE查询来说Q数据传l的索引是根本用不上的。数据需要逐个便利记录q行GREP式的模糊匚wQ比有烦(ch)引的搜烦(ch)速度要有多个数量U的下降?/td>
匚w效果
通过词元(term)q行匚wQ通过语言分析接口的实玎ͼ可以实现对中文等非英语的支持?/td>
使用Qlike "%net%" ?x)把netherlands也匹配出来，
多个关键词的模糊匚wQ用like "%com%net%"Q就不能匚w词序颠倒的xxx.net..xxx.com
匚w?/td>
有匹配度法Q将匚wE度Q相似度Q比较高的结果排在前面?/td>
没有匚wE度的控Ӟ(x)比如有记录中net出现5词和出现1ơ的Q结果是一L(fng)?/td>
l果输出
通过特别的算法，最匚w度最高的?00条结果输出，l果集是~冲式的批量读取的?/td>
q回所有的l果集，在匹配条目非常多的时候（比如上万条）(j)需要大量的内存存放q些临时l果集?/td>
可定制?/td>
通过不同的语a分析接口实现Q可以方便的定制出符合应用需要的索引规则Q包括对中文的支持）(j)
没有接口或接口复杂，无法定制
l论
高负载的模糊查询应用Q需要负责的模糊查询的规则，索引的资料量比较?/td>
使用率低Q模p匹配规则简单或者需要模p查询的资料量少
Lucene的创C处：(x)
Lucene
其他开源全文检索系l?/td>
增量索引和批量烦(ch)?/td>
可以q行增量的烦(ch)?Append)Q可以对于大量数据进行批量烦(ch)引，q且接口设计用于优化扚w索引和小扚w的增量烦(ch)引?/td>
很多pȝ只支持批量的索引Q有时数据源有一点增加也需要重建烦(ch)引?/td>
数据?/td>
Lucene没有定义具体的数据源Q而是一个文档的l构Q因此可以非常灵zȝ适应各种应用Q只要前端有合适的转换器把数据源{换成相应l构Q，
很多pȝ只针对网，~Z其他格式文的灵zL?/td>
索引内容抓取
Lucene的文是由多个字D늻成的Q甚臛_以控刉些字D需要进行烦(ch)引，那些字段不需要烦(ch)引，q一步烦(ch)引的字段也分为需要分词和不需要分词的cdQ?br />
需要进行分词的索引Q比如：(x)标题Q文章内容字D?br />
不需要进行分词的索引Q比如：(x)作?日期字段
~Z通用性，往往文整个烦(ch)引了(jin)
语言分析
通过语言分析器的不同扩展实现Q?br />
可以qo(h)掉不需要的词：(x)an the of {，
西文语法分析Q将jumps jumped jumper都归l成jumpq行索引/(g)?br />
非英文支持：(x)对亚z语aQ阿拉伯语言的烦(ch)引支?/td>
~Z通用接口实现
查询分析
通过查询分析接口的实玎ͼ可以定制自己的查询语法规则：(x)
比如Q?多个关键词之间的 + - and or关系{?/td>
q发讉K
能够支持多用L(fng)使用
“北京 天安?#8221; q是“??天安?#8221;Q让计算够按照语a?fn)惯q行切分Q往往需要机器有一个比较丰富的词库才能够比较准的识别?gu)句中的单词?/p>
"北京天安? ==> "北京 京天 天安 安门"?/p>
自动切分
词表切分
实现
实现非常?/td>
实现复杂
查询
增加?jin)查询分析的复杂E度Q?/td>
适于实现比较复杂的查询语法规?/td>
存储效率
索引冗余大，索引几乎和原文一样大
索引效率高，为原文大的30Q左?/td>
l护成本
无词表维护成?/td>
词表l护成本非常高：(x)中日韩等语言需要分别维护?br />
q需要包括词频统计等内容
适用领域
嵌入式系l：(x)q行环境资源有限
分布式系l：(x)无词表同步问?br />
多语a环境Q无词表l护成本Ҏ(gu)询和存储效率要求高的专业搜烦(ch)引擎
org.apache.Lucene.search/
搜烦(ch)入口
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构
Ҏ(gu) 切词 索引 存储 用?/th>
Field.Text(String name, String value)
Yes
Yes
Yes
切分词烦(ch)引ƈ存储Q比如：(x)标题Q内容字D?/td>
Field.Text(String name, Reader value)
Yes
Yes
No
切分词烦(ch)引不存储Q比如：(x)META信息Q?br />
不用于返回显C，但需要进行检索内?/td>
Field.Keyword(String name, String value)
No
Yes
Yes
不切分烦(ch)引ƈ存储Q比如：(x)日期字段
Field.UnIndexed(String name, String value)
No
No
Yes
不烦(ch)引，只存储，比如Q文件\?/td>
Field.UnStored(String name, String value)
Yes
Yes
No
只全文烦(ch)引，不存?/td>
public class IndexFiles {
//使用Ҏ(gu)Q? IndexFiles [索引输出目录] [索引的文件列表] ...
public static void main(String[] args) throws Exception {
String indexPath = args[0];
IndexWriter writer;
//用指定的语言分析器构造一个新的写索引器（W?个参数表C是否ؓ(f)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进行全文烦(ch)引，q存?br />
Document doc = new Document();
doc.add(Field.UnIndexed("path", args[i]));
doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
//文档写入烦(ch)?br />
writer.addDocument(doc);
is.close();
};
//关闭写烦(ch)引器
writer.close();
}
}
public class Search {
在整个检索过E中Q语a分析器，查询分析器，甚至搜烦(ch)器（SearcherQ都是提供了(jin)抽象的接口，可以Ҏ(gu)需要进行定制?
public static void main(String[] args) throws Exception {
String indexPath = args[0], queryString = args[1];
//指向索引目录的搜索器
Searcher searcher = new IndexSearcher(indexPath);
//查询解析器：(x)使用和烦(ch)引同L(fng)语言分析?br />
Query query = QueryParser.parse(queryString, "body",
new SimpleAnalyzer());
//搜烦(ch)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));
};
}
}
Clause ::= ["+", "-"] [<TERM> ":"] ( <TERM> | "(" Query ")")...
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果命中列表中：(x)
* hq.put(new ScoreDoc(doc, score)); // update hit queue
* 如果用doc ?1/doc 代替 scoreQ就实现?jin)根据docID排或逆排
* 假设数据源烦(ch)引时已经按照某个字段排好?jin)序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());数据? WORD PDF HTML DB other
\ | | | /
XML中间格式
|
Lucene INDEX
另外一个办法就是把Word文档转换成textQ?a style="text-decoration: underline; color: #3165ce; ">http://www.winfield.demon.nl/index.html
索引q程优化
而尽可能减少IndexSearcher的创建和Ҏ(gu)索结果的前台的缓存(sh)是必要的?br />
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的讲座：(x)非常详细的Lucene架构解说
]]>