一、緣起
Lucene在索引文件上G之后的搜索性能下降很?chē)?yán)重，隨便跑個(gè)搜索就要上0.x秒。如果是單線(xiàn)程搜索那么性能尚可，總可以在0.x秒返回結(jié)果，如果是Web式的多線(xiàn)程訪(fǎng)問(wèn)，由于Lucene的內(nèi)部機(jī)制導(dǎo)致數(shù)據(jù)被大量載入內(nèi)存，用完后立即丟棄，隨之引起JVM頻繁GC，性能極其低下，1-10秒的長(zhǎng)連接比比皆是。這也是世人為之詬病的Lucene應(yīng)用瓶頸問(wèn)題，那么是否有解決方法呢？

二、思路
我們來(lái)觀(guān)察Google, Baidu的搜索，有一個(gè)總體的感覺(jué)就是搜索結(jié)果多的關(guān)鍵詞耗時(shí)比較少，結(jié)果少的關(guān)鍵詞耗時(shí)反而多，且結(jié)果多的時(shí)候會(huì)說(shuō)“約******個(gè)結(jié)果”。隱士猜測(cè)Google, Baidu的算法是找到前n個(gè)結(jié)果后停止掃描索引，根據(jù)前n個(gè)結(jié)果來(lái)推斷總共有多少個(gè)結(jié)果，此猜想可由Google, Baidu翻頁(yè)限制而得到部分驗(yàn)證。
再看Lucene，其Hits.length()返回的總是精確的結(jié)果，如果可以讓Lucene也返回模糊的結(jié)果，那么索引文件就算是10G也可以輕松應(yīng)對(duì)了。

三、探索
隱士帶著這個(gè)問(wèn)題訪(fǎng)名山、覓高人，可惜沒(méi)有找到前人的成果，可能是隱士走的路不夠勤，如有類(lèi)似的解決方案，隱士不吝賜教。
無(wú)奈之下，隱士詳細(xì)研究了Lucene 2.1.0源碼，準(zhǔn)備重新發(fā)明輪子。
一般來(lái)說(shuō)大多數(shù)搜索應(yīng)用中的Query都會(huì)落在BooleanQuery上，隱士就拿它開(kāi)刀。一路看來(lái)，BooleanScorer2里的一個(gè)method吸引了隱士，代碼如下：

  public void score(HitCollector hc) throws IOException {
    if (countingSumScorer == null) {
      initCountingSumScorer();
    }
    while (countingSumScorer.next()) {
      hc.collect(countingSumScorer.doc(), score());
    }
  }

在while循環(huán)里嵌入寫(xiě)日志代碼可證結(jié)果集有多大，此處就循環(huán)了多少次。countingSumScorer.next()的意思是找到下一個(gè)符合boolean規(guī)則的document，找到后放入HitCollector，這HitCollector后面會(huì)換個(gè)馬甲放在大家熟悉的Hits里面。
如果可以在這個(gè)while循環(huán)里嵌一個(gè)break，到一定數(shù)量就break出來(lái)，性能提升將相當(dāng)明顯。這個(gè)代碼相當(dāng)簡(jiǎn)單，果然大幅提高了性能，帶來(lái)的副作用是結(jié)果不太準(zhǔn)，這個(gè)可以通過(guò)調(diào)整業(yè)務(wù)模型、邏輯來(lái)修正。畢竟這是一條提升Lucene性能的有效方法。
細(xì)細(xì)想來(lái)，正是由于這個(gè)break會(huì)導(dǎo)致結(jié)果集大的關(guān)鍵詞提前出來(lái)，搜索時(shí)間少，結(jié)果集小的關(guān)鍵詞不可避免會(huì)走完整個(gè)索引，相應(yīng)的搜索時(shí)間會(huì)長(zhǎng)一點(diǎn)。

四、效果
由于具體嵌入代碼的過(guò)程極其繁瑣，隱士將在第二回詳細(xì)講解。這第一回先來(lái)個(gè)Big picture。
歷盡千辛萬(wàn)苦，隱士終于搞定了這套程序，效果可以從隱士做的視頻搜索http://so.mdbchina.com/video/%E7%BE%8E%E5%A5%B3看出。
這個(gè)關(guān)鍵詞“美女”可以找到18萬(wàn)個(gè)視頻，平均0.5秒返回結(jié)果，現(xiàn)在用上了新算法，只要0.06x秒返回結(jié)果，而且返回結(jié)果足夠好了，估算的8.5萬(wàn)個(gè)結(jié)果雖然離18萬(wàn)有很大差距，不過(guò)由于是估算的，差2-3倍應(yīng)屬可以接受的。
由算法的特性可知，while里面的hc.collect總可以在常量時(shí)間內(nèi)完成，循環(huán)次數(shù)又是<=常量，該算法的時(shí)間復(fù)雜度只和BooleanQuery的復(fù)雜程度相關(guān)，和索引文件大小以及命中的Document在索引文件內(nèi)的分布密度沒(méi)有關(guān)系，因?yàn)锽ooleanQuery的復(fù)雜程度決定了countingSumScorer.next()需要經(jīng)過(guò)多少次判斷、多少次讀取索引文件，countingSumScorer.next()正是整個(gè)算法中耗時(shí)不定的部分。
現(xiàn)在這個(gè)視頻搜索的索引文件接近3G，熱門(mén)關(guān)鍵詞可以在0.0x秒返回結(jié)果，隱士相信即使以后索引文件上到10G，依然可以在0.0x秒返回結(jié)果。

(注：這個(gè)視頻搜索實(shí)際使用效果會(huì)打折扣，因?yàn)楹笈_(tái)索引也在這臺(tái)機(jī)器上，以后會(huì)分服務(wù)器，現(xiàn)在暫時(shí)在一起。)

安徽新華電腦學(xué)校專(zhuān)業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線(xiàn)咨詢(xún)】