偏移量,结束偏移量),出现频率],检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率,所以,全文检索问题归结到最后是一个排序问题。
由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题,这也是大部分数据库对全文检索支持有限的原因。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的文档是由多个字段组成的,甚至可以控制那些字段需要进行索引,那些字段不需要索引,近一步索引的字段也分为需要分词和不需要分词的类型: 需要进行分词的索引,比如:标题,文章内容字段 不需要进行分词的索引,比如:作者/日期字段 |
缺乏通用性,往往将文档整个索引了 |
语言分析 |
通过语言分析器的不同扩展实现: 可以过滤掉不需要的词:an the of 等, 西文语法分析:将jumps jumped jumper都归结成jump进行索引/检索 非英文支持:对亚洲语言,阿拉伯语言的索引支持 |
缺乏通用接口实现 |
查询分析 |
通过查询分析接口的实现,可以定制自己的查询语法规则: 比如: 多个关键词之间的 + - and or关系等 |
|
并发访问 |
能够支持多用户的使用 |
|
|