lucene理论—Lucene的搜索过程(转)
二:Lucene的搜索过程
1:Lucene搜索过程:
大的分为:关键字解析,获取docid(除去删除的docid),获取内容,飘红缩短。
2:关键词解析:
大概原理是:就是把输入的关键词和要搜索的域进行格式化。把应用请求的语义解释成lucene能懂的语法。
1:其实一般的架构就是把这块分离,把应用和搜索分层。
|
应用层 |
|
格式化数据 |
|
获取docid 获取document |
|
存储 |
|
Socket/ICE |
1:看看baidu和google,他们的关键字一般都是会分词的
2:但是lucene默认的对搜索关键词不分词
3:主要了解与或非,lucene里面其实做了3层or/and/not处理。一个是关键词组本身自带的逻辑,一个是分词后的逻辑,一个是域逻辑。
实例演示来说明这3个关系。
4:其实要把应用为主要功能的格式化关键词完全放在应用层,存在一个问题,就是分词,一般不把分词剥离,也是为了节约内存,也是为了部署单一分词,比如有的分词按照服务器收费等,所以这是分层的一个主要原因。
5:程序大概过程:MultiFieldQueryParser =〉BooleanQuery =〉 QueryParser(这是个关键的类,也是逻辑复杂类之一)。
ReInit(进行了关键词自身分词)=〉 Query类构造函数(Conjunction方法获取前面分词的or/and/not关系;Modifiers获取field的or/and/not关系;Clause 对前面分次后的每个词进行or/and/not处理;addClause格式化整合处理) =〉格式化分词处理完毕。
Clause =〉 Term =〉 getFieldQuery(分词) =〉 severalTokensAtSamePosition这个设置为true,里面的MultiPhraseQuery换成BooleanQuery;(加上全局的operator值改为and)最终实现搜索框直接输入短语,自动分词,自动and搜索。
6:这块功能值得注意的一个大问题就是分词,分词的缓存是非常的必要,效率影响非常明显。
7:如果优化,可以考虑对这块也是个优化。
3:获取docid:
1:IndexSearcher的search方法;
程序大概过程:返回值是Hits对象。经过构造调用到Hits的构造:在这个构造中weight等计算,我们当时也修改过这个参数,最后结果是效果不大;在这个构造也调用了getMoreDocs,有一个返回100个命中的参数在这里修改。
搜索的信息内容都放在了hits对象中,当然关键的Docid就在里面。
getMoreDocs中主要调用了searcher.search,并且把返回的TopDocs压入hitDocs中
searcher.search通过抽象的实现,在IndexSearcher中实现
2:这里面有几个值得注意的问题就是缓存问题:
1:倒排表以及缓存问题
2:搜索过一次了,是否缓存了已经返回docid对应的内容?因为接下来要取内容啊。Docid里面有没有内容,但是有指针和偏移量,那么缓存了这些吗?缓存了。
4:获取内容:
1:获取内容提供的方法很多,比如有只拿着docid取内容的,还有通过返回的hits对象取内容的,等等很多方法。
2:分析hits取内容过程:
调用hits中的doc方法,里面的hitDoc获取缓存中的document信息
remove中是个典型的双链表结构,删除缓存,addToFront添加缓存
if (hitDoc.doc == null) {一般走这里面,一般没有缓存,为了下面获取内容准备,也就是对field进行缓存。这儿有个很绕,比较复杂的过程。调用了searcher.Doc,它是IndexSearcher里面的reader.document(i); reader又是调用的IndexReader.open,这个过程就和索引的开始过程一摸一样了。这是lucene唯一一个大模块很明显的结构耦合地方。
浙公网安备 33010602011771号