一、緣起
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吸引了隱士，代碼如下：

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

在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秒返回結果。

(注：這個視頻搜索實際使用效果會打折扣，因為后臺索引也在這臺機器上，以后會分服務器，現在暫時在一起。)

安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】