没有合适的资源?快使用搜索试试~ 我知道了~
Lucene:基于Java的全文检索引擎简介
需积分: 0 1 下载量 2 浏览量
2011-03-30
11:32:35
上传
评论
收藏 42KB DOCX 举报
温馨提示
试读
13页
Lucene:基于Java的全文检索引擎简介
资源详情
资源评论
资源推荐
:基于 的全文检索引擎简介
是一个基于 的全文索引工具包。
基于
的全文索引引擎
简介:关于作者和
的历史
全文检索的实现:
全文索引和数据库索引的比较
中文切分词机制简介:基于词库和自动切分词算法的比较
具体的安装和使用简介:系统结构介绍和演示
:简化的查询分析器,删除的实现,定制的排序,应用接口的
扩展
从
我们还可以学到什么
另外,如果是在选择全文引擎,现在也许是试试
的时候了:相比 速度更
快,有中文分词的支持,而且内置了对简单的分布式检索的支持;
基于 Java 的全文索引/检索引擎——Lucene
不是一个完整的全文索引应用,而是是一个用 写的全文索引引擎工具包,它
可以方便的嵌入到各种应用中实现针对应用的全文索引检索功能。
的作者: 的贡献者
是一位资深全文索引检索专家,曾经
是 ! 搜索引擎"#$ 的 $% 操作系统的成就之一&的主要开发者,后在 '
担任高级系统架构设计师,目前从事于一些 () '*)' 底层架构的研究。他贡献出的
的目标是为各种中小型应用程序加入全文检索功能。
的发展历程:早先发布在作者自己的 !!!$+,后来发布在
,-,,.. 年年底成为 #/#' 基金会 0, 的一个子项目:1
0,,$
已经有很多 项目都使用了 作为其后台的全文索引引擎,比较著名的有:
:2'3 论坛系统;
'45,!6 :邮件列表 7 归档浏览查询系统,本文的主要参考文档
“ 6,1/!,8$9:5$9%8,;作者就是
'43,!6 系统的主要开发者之一,而 '43,!6 已经成为目前 #/#' 项目
的主要邮件列表归档系统。
1基于 <7 的 !5 发布框架,全文检索部分使用了
'$6 1基于 的开放开发平台,帮助部分的全文索引使用了
对于中文用户来说,最关心的问题是其是否支持中文的全文检索。但通过后面对于
的结构的介绍,你会了解到由于 良好架构设计,对中文的支持只需对其
语言词法分析接口进行扩展就能实现对中文检索的支持。
全文检索的实现机制
的 #/( 接口设计的比较通用,输入输出结构都很像数据库的表==>记录==>字
段,所以很多传统的应用的文件、数据库等都可以比较方便的映射到 的存储结构
接口中。总体上看:可以先把 Lucene 当成一个支持全文索引的数据库系统。
比较一下 和数据库:
数据库
索引数据源:%"?$%9?$%&
%"?$%9?$%&
@%,
AAAAAAAAAAAAA
B(%B
6,,@
结果输出:6"%"?$%9?$%&
%"?$%&&
索引数据源:
,,%"?$%9?$%&
,,%"?$%&
@C16,
AAAAAAAAAAAAA
B3(%B
C16$@
结果输出:
,6$6",,%"?$%9?$%&
,,%"?$%&&
+:一个需要进行索引的“单元”
一个 + 由多个字段组成
*,%:记录,包含多个字段
-$%:字段 -$%:字段
6:查询结果集,由匹配的 + 组
成
*,%:查询结果集,由多个 *,%
组成
全文检索 ≠ like "%keyword%"
通常比较厚的书籍后面常常附关键词索引表(比如:北京:9 页, 上海:9DD 页…
…),它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的
速度原理也是一样,想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少
倍……而索引之所以效率高,另外一个原因是它是排好序的。对于检索系统来说核心是一
个排序问题。
由于数据库索引不是为全文索引设计的,因此,使用 like "%keyword%"时,数据库索
引是不起作用的,在使用 $ 查询时,搜索过程又变成类似于一页页翻书的遍历过程了,
所以对于含有模糊查询的数据库服务来说,(E' 对性能的危害是极大的。如果是需要对多
个关键词进行模糊匹配:$FG4!,%GF%$FG4!,%GF其效率也就
可想而知了。
所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制,将数
据源(比如多篇文章)排序顺序存储的同时,有另外一个排好序的关键词列表,用于存储
关键词==>文章映射关系,利用这样的映射关系索引:H关键词==>出现关键词的文章编
号,出现次数(甚至包括位置:起始偏移量,结束偏移量),出现频率I,检索过程就是把
模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词
查询的效率,所以,全文检索问题归结到最后是一个排序问题。
由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题,这也是大部分数
据库对全文检索支持有限的原因。 最核心的特征是通过特殊的索引结构实现了传
统数据库不擅长的全文索引机制,并提供了扩展接口,以方便针对不同应用的定制。
可以通过一下表格对比一下数据库的模糊查询:
全文索引引擎 数据库
索引
将数据源中的数据都通过全文索引一一建立
反向索引
对于 (E' 查询来说,数据传统的索
引是根本用不上的。数据需要逐个便
利记录进行 J*'/ 式的模糊匹配,比
有索引的搜索速度要有多个数量级的
下降。
匹配效
果
通过词元",+&进行匹配,通过语言分析
接口的实现,可以实现对中文等非英语的支
持。
使用:$FGGF会把
,$%6 也匹配出来,
多个关键词的模糊匹配:使用 $
FG+GGF:就不能匹配词序
颠倒的 +
匹配度
有匹配度算法,将匹配程度(相似度)比较
高的结果排在前面。
没有匹配程度的控制:比如有记录中
出现 词和出现 次的,结果是
一样的。
结果输
出
通过特别的算法,将最匹配度最高的头
.. 条结果输出,结果集是缓冲式的小批
量读取的。
返回所有的结果集,在匹配条目非常
多的时候(比如上万条)需要大量的
内存存放这些临时结果集。
可定制
性
通过不同的语言分析接口实现,可以方便的
定制出符合应用需要的索引规则(包括对中
文的支持)
没有接口或接口复杂,无法定制
结论
高负载的模糊查询应用,需要负责的模糊查
询的规则,索引的资料量比较大
使用率低,模糊匹配规则简单或者需
要模糊查询的资料量少
全文检索和数据库应用最大的不同在于:让最相关的头 100 条结果满足 98%以上用户的
需求
的创新之处:
大部分的搜索(数据库)引擎都是用 3 树结构来维护索引,索引的更新会导致大量的 (K
操作, 在实现中,对此稍微有所改进:不是维护一个索引文件,而是在扩展索引
的时候不断创建新的索引文件,然后定期的把这些新的小索引文件合并到原先的大索引中
(针对不同的更新策略,批次的大小可以调整),这样在不影响检索的效率的前提下,提
高了索引的效率。
和其他一些全文检索系统应用的比较:
其他开源全文检索系统
剩余12页未读,继续阅读
songbobj
- 粉丝: 0
- 资源: 8
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0