在应用中加入全文检索功能
uM!r|X)8 ——基于Java的全文索引引擎Lucene简介
<Phr`/ 作者: 车东 Email: chedongATbigfoot.com/chedongATchedong.com
Wes"t}[25 ZYt"=\_ 写于:2002/08 最后更新: 11/29/2006 17:23:30
DBrzw+;e3 Feed Back >> (Read this before you ask question)
&l}xBQAL S$_Ts1Ge6 版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
-clg'Aa;. http://www.chedong.com/tech/lucene.html N*)8L[7_; yD
id`ym 关键词:Lucene java full-text search engine Chinese word segment
X1PlW8pd ~Wd8>a{w 内容摘要:
hD.wKX?oO *z:lq2"G Lucene是一个基于Java的全文索引工具包。
MKYE]D; (IQ L`3f% 基于Java的全文索引引擎Lucene简介:关于作者和Lucene的历史
XK9*,WA9r 全文检索的实现:Luene全文索引和数据库索引的比较
iW%0pLn 中文切分词机制简介:基于词库和自动切分词算法的比较
,7$uh): 具体的安装和使用简介:系统结构介绍和演示
6!PX!
UkF Hacking Lucene:简化的查询分析器,删除的实现,定制的排序,应用接口的扩展
bIl0rx[` 从Lucene我们还可以学到什么
]]QCJf@p 基于Java的全文索引/检索引擎——Lucene
{_N(S]Z -#z'A Lucene不是一个完整的全文索引应用,而是是一个用Java写的全文索引引擎工具包,它可以方便的嵌入到各种应用中实现针对应用的全文索引/
#UnO~IE.m$ .xQ'^P_q 检索功能。
[B;Ek\ 5W F"? *@L Lucene的作者:Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家,曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的
EC\:uK @{GxQzo 主要开发者,后在Excite担任高级系统架构设计师,目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用
*1]k&#s :h dh$}y 程序加入全文检索功能。
T{xo_u{Q :v ~q Lucene的发展历程:早先发布在作者自己的
www.lucene.com,后来发布在SourceForge,2001年年底成为APACHE基金会jakarta的一个子项目:
.Eyk?"^ @MH]s [{o\ http://jakarta.apache.org/lucene/ &y wY?ox `D4'`Or-U 已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎,比较著名的有:
7027@M?A? *wyLX9{: Jive:WEB论坛系统;
fszeJS}Dw Eyebrows:邮件列表HTML归档/浏览/查询系统,本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”作者就是
]* Ki7h|B "r3s'\ EyeBrows系统的主要开发者之一,而EyeBrows已经成为目前APACHE项目的主要邮件列表归档系统。
3sIM7WD? Cocoon:基于XML的web发布框架,全文检索部分使用了Lucene
&8L\FAY0%9 Eclipse:基于Java的开放开发平台,帮助部分的全文索引使用了Lucene
JJ06f~Iw[ hds4_ 对于中文用户来说,最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene的结构的介绍,你会了解到由于Lucene良好架构设计
q)y8Bv| <T[ui ,对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。
\`5u@Nzx qnV9TeU) 全文检索的实现机制
YQsc(6 BkqW>[\5xm Lucene的API接口设计的比较通用,输入输出结构都很像数据库的表==>记录==>字段,所以很多传统的应用的文件、数据库等都可以比较方便的
()JDjzQT 5!p'n#_ 映射到Lucene的存储结构/接口中。总体上看:可以先把Lucene当成一个支持全文索引的数据库系统。
+>({pHZ<S V2skr_1 比较一下Lucene和数据库:
bncFrzp#o 4u7>NQUDu Lucene 数据库
>7Q7H#~w 索引数据源:doc(field1,field2...) doc(field1,field2...) \ indexer / _____________
<cjTn:w Lxrn#Z eM | Lucene Index| -------------- / searcher \ 结果输出:Hits(doc(field1,field2) doc
ay[*b_f P#oV ^ (field1...))
?"u-@E[m 索引数据源:record(field1,field2...) record(field1..) \ SQL: insert/ _____________
nP5fh_/ E.9k%%X] | DB Index | ------------- / SQL: select \结果输出:results(record(field1,field2..) record
%W@IB8]Vr 8"^TWzg}L (field1...))
g+*[CKO{ 3f8Z?[Bb@ Document:一个需要进行索引的“单元”
uMZf9XUE 一个Document由多个字段组成 Record:记录,包含多个字段
^2@~AD`&h Field:字段 Field:字段
T6#GlO)8) Hits:查询结果集,由匹配的Document组成 RecordSet:查询结果集,由多个Record组成
1ki"UF/ I%xJ)fIK 全文检索 ≠ like "%keyword%"
Dw,f~D$+ic H4jqF~ 通常比较厚的书籍后面常常附关键词索引表(比如:北京:12, 34页,上海:3,77页……),它能够帮助读者比较快地找到相关内容的页码。
S45_-aE Ba~Iy2\x 而数据库索引能够大大提高查询的速度原理也是一样,想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所
WQ`T'k#ESW ?yK\L-ad 以效率高,另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。
%Ski5q B[50{;X 由于数据库索引不是为全文索引设计的,因此,使用like "%keyword%"时,数据库索引是不起作用的,在使用like查询时,搜索过程又变成类
b*fflJ $S{j}74[ 似于一页页翻书的遍历过程了,所以对于含有模糊查询的数据库服务来说,LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹
N4-J !r@#~ g.s oNqt= 配:like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。
#m>mYp8E.5 F{tSfKy2 所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制,将数据源(比如多篇文章)排序顺序存储的同时,有另外
7i/Cax Y?cw9uYB 一个排好序的关键词列表,用于存储关键词==>文章映射关系,利用这样的映射关系索引:[关键词==>出现关键词的文章编号,出现次数(甚至
~yN,F pD nrBitu, 包括位置:起始偏移量,结束偏移量),出现频率],检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大
]+P&Y: w4a7c 提高了多关键词查询的效率,所以,全文检索问题归结到最后是一个排序问题。
ak[)+_k_ -^DB?j+ 由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题,这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特
gG>>ynn ow"Xv 征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制,并提供了扩展接口,以方便针对不同应用的定制。
g!ww;_ UepBXt3) 可以通过一下表格对比一下数据库的模糊查询:
%\0 Y1!Hw lfP|+=^B
Lucene全文索引引擎 数据库
VWa(@A 索引 将数据源中的数据都通过全文索引一一建立反向索引 对于LIKE查询来说,数据传统的索引是根本用不上的。数据需要逐个便利记录进行
z^.0eP8\j |e\%pfZ GREP式的模糊匹配,比有索引的搜索速度要有多个数量级的下降。
#C^m>o~R 匹配效果 通过词元(term)进行匹配,通过语言分析接口的实现,可以实现对中文等非英语的支持。 使用:like "%net%" 会把netherlands也
$!Tw`O %3j5Q 匹配出来,
9K!='u` 多个关键词的模糊匹配:使用like "%com%net%":就不能匹配词序颠倒的xxx.net..xxx.com
@AOiZOH 匹配度 有匹配度算法,将匹配程度(相似度)比较高的结果排在前面。 没有匹配程度的控制:比如有记录中net出现5词和出现1次的,结果是
lDeWs%n k9n93I|Cm 一样的。
_rd{cvdR 结果输出 通过特别的算法,将最匹配度最高的头100条结果输出,结果集是缓冲式的小批量读取的。 返回所有的结果集,在匹配条目非常多的
>Fz$DKr[ Rd)QVEk>SD 时候(比如上万条)需要大量的内存存放这些临时结果集。
nKdLhCN'= 可定制性 通过不同的语言分析接口实现,可以方便的定制出符合应用需要的索引规则(包括对中文的支持) 没有接口或接口复杂,无法定制
v&n&i? 结论 高负载的模糊查询应用,需要负责的模糊查询的规则,索引的资料量比较大 使用率低,模糊匹配规则简单或者需要模糊查询的资料量少
c+=&5=i[3 Sls>
OIc 全文检索和数据库应用最大的不同在于:让最相关的头100条结果满足98%以上用户的需求
+zsya4r zu#o<6E{ Lucene的创新之处:
`Nj|}^A jTnu! H2o 大部分的搜索(数据库)引擎都是用B树结构来维护索引,索引的更新会导致大量的IO操作,Lucene在实现中,对此稍微有所改进:不是维护一
@zbXG_J '#PT C,0UJ 个索引文件,而是在扩展索引的时候不断创建新的索引文件,然后定期的把这些新的小索引文件合并到原先的大索引中(针对不同的更新策略
JFZ p^{ PBmt.yF ,批次的大小可以调整),这样在不影响检索的效率的前提下,提高了索引的效率。
9[`6f8S_$ $Tg$FfD6& Lucene和其他一些全文检索系统/应用的比较:
n[@Ur2&