Lucene Hack之通过缩小搜索结果集来提升性能(转载,作者佚名)

一、缘起
    Lucene在索引文件上G之后的搜索性能下降很严重,随便跑个搜索就要上0.x秒。如果是单线程搜索那么性能尚可,总可以在0.x秒返回结果,如果是Web式的多线程访问,由于Lucene的内部机制导致数据被大量载入内存,用完后立即丢弃,随之引起JVM频繁GC,性能极其低下,1-10秒的长连接比比皆是。这也是世人为之诟病的Lucene应用瓶颈问题,那么是否有解决方法呢?

二、思路
    我们来观察Google, Baidu的搜索,有一个总体的感觉就是搜索结果多的关键词耗时比较少,结果少的关键词耗时反而多,且结果多的时候会说“约******个结果”。隐士猜测Google, Baidu的算法是找到前n个结果后停止扫描索引,根据前n个结果来推断总共有多少个结果,此猜想可由Google, Baidu翻页限制而得到部分验证。
再看Lucene,其Hits.length()返回的总是精确的结果,如果可以让Lucene也返回模糊的结果,那么索引文件就算是10G也可以轻松应对了。

三、探索
    隐士带着这个问题访名山、觅高人,可惜没有找到前人的成果,可能是隐士走的路不够勤,如有类似的解决方案,隐士不吝赐教。
无奈之下,隐士详细研究了Lucene 2.1.0源码,准备重新发明轮子。
一般来说大多数搜索应用中的Query都会落在BooleanQuery上,隐士就拿它开刀。一路看来,BooleanScorer2里的一个method吸引了隐士,代码如下:

 

代码
  1. public void score(HitCollector hc) throws IOException {   
  2.   if (countingSumScorer == null) {   
  3.     initCountingSumScorer();   
  4.   }   
  5.   while (countingSumScorer.next()) {   
  6.     hc.collect(countingSumScorer.doc(), score());   
  7.   }   
  8. }   
<script type="text/javascript">render_code();</script>

    在while循环里嵌入写日志代码可证结果集有多大,此处就循环了多少次。countingSumScorer.next()的意思是找到下一个符合boolean规则的document,找到后放入HitCollector,这HitCollector后面会换个马甲放在大家熟悉的Hits里面。

    如果可以在这个while循环里嵌一个break,到一定数量就break出来,性能提升将相当明显。这个代码相当简单,果然大幅提高了性能,带来的副作用是结果不太准,这个可以通过调整业务模型、逻辑来修正。毕竟这是一条提升Lucene性能的有效方法。

    细细想来,正是由于这个break会导致结果集大的关键词提前出来,搜索时间少,结果集小的关键词不可避免会走完整个索引,相应的搜索时间会长一点。

四、效果
    由于具体嵌入代码的过程极其繁琐,隐士将在第二回详细讲解。这第一回先来个Big picture。
历尽千辛万苦,隐士终于搞定了这套程序,效果可以从隐士做的视频搜索
http://so.mdbchina.com/video/%E7%BE%8E%E5%A5%B3看出。

    这个关键词“美女”可以找到18万个视频,平均0.5秒返回结果,现在用上了新算法,只要0.06x秒返回结果,而且返回结果足够好了,估算的8.5万个结果虽然离18万有很大差距,不过由于是估算的,差2-3倍应属可以接受的。
由算法的特性可知,while里面的hc.collect总可以在常量时间内完成,循环次数又是<=常量,该算法的时间复杂度只和BooleanQuery的复杂程度相关,和索引文件大小以及命中的Document在索引文件内的分布密度没有关系,因为BooleanQuery的复杂程度决定了countingSumScorer.next()需要经过多少次判断、多少次读取索引文件,countingSumScorer.next()正是整个算法中耗时不定的部分。

    现在这个视频搜索的索引文件接近3G,热门关键词可以在0.0x秒返回结果,隐士相信即使以后索引文件上到10G,依然可以在0.0x秒返回结果。

(注:这个视频搜索实际使用效果会打折扣,因为后台索引也在这台机器上,以后会分服务器,现在暂时在一起。)

=======佐证=======

Q: 如何看到前 1000 个结果以外的其他结果?


A: 针对某一个查询,即使匹配项超过 1000 个,Google 也只提供 1000 个最相关的搜索结果。(由于结果估算方面的差异,我们显示的结果偶尔可能会稍低于 1000。)我们努力为您提供高效的搜索体验,让您无需滚动到前十个列表之后。我们也理解,某些用户想要查看的结果可能不止 1000 个,但这并非普遍情况,而且为每个用户都提供这些结果会极大地增加我们的系统负担。

//这里看出,越少的返回结果对服务器压力越小,而且足够满足99.99%的用户需求,而用户如果没有找到有用的信息,唯一的方法是增加相关的关键字形成查询组合。所以上文的出发是正确的。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值