|
一、緣起
Lucene在索引文件上G之后的搜索性能下降很嚴(yán)重，隨便跑個(gè)搜索就要上0.x秒。如果是單線程搜索那么性能尚可，總可以在0.x秒返回結(jié)果，如果是Web式的多線程訪問，由于Lucene的內(nèi)部機(jī)制導(dǎo)致數(shù)據(jù)被大量載入內(nèi)存，用完后立即丟棄，隨之引起JVM頻繁GC，性能極其低下，1-10秒的長(zhǎng)連接比比皆是。這也是世人為之詬病的Lucene應(yīng)用瓶頸問題，那么是否有解決方法呢？
二、思路
我們來觀察Google, Baidu的搜索，有一個(gè)總體的感覺就是搜索結(jié)果多的關(guān)鍵詞耗時(shí)比較少，結(jié)果少的關(guān)鍵詞耗時(shí)反而多，且結(jié)果多的時(shí)候會(huì)說“約******個(gè)結(jié)果”。隱士猜測(cè)Google, Baidu的算法是找到前n個(gè)結(jié)果后停止掃描索引，根據(jù)前n個(gè)結(jié)果來推斷總共有多少個(gè)結(jié)果，此猜想可由Google, Baidu翻頁(yè)限制而得到部分驗(yàn)證。
再看Lucene，其Hits.length()返回的總是精確的結(jié)果，如果可以讓Lucene也返回模糊的結(jié)果，那么索引文件就算是10G也可以輕松應(yīng)對(duì)了。
三、探索
隱士帶著這個(gè)問題訪名山、覓高人，可惜沒有找到前人的成果，可能是隱士走的路不夠勤，如有類似的解決方案，隱士不吝賜教。
無奈之下，隱士詳細(xì)研究了Lucene 2.1.0源碼，準(zhǔn)備重新發(fā)明輪子。
一般來說大多數(shù)搜索應(yīng)用中的Query都會(huì)落在BooleanQuery上，隱士就拿它開刀。一路看來，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)里嵌入寫日志代碼可證結(jié)果集有多大，此處就循環(huán)了多少次。countingSumScorer.next()的意思是找到下一個(gè)符合boolean規(guī)則的document，找到后放入HitCollector，這HitCollector后面會(huì)換個(gè)馬甲放在大家熟悉的Hits里面。
如果可以在這個(gè)while循環(huán)里嵌一個(gè)break，到一定數(shù)量就break出來，性能提升將相當(dāng)明顯。這個(gè)代碼相當(dāng)簡(jiǎn)單，果然大幅提高了性能，帶來的副作用是結(jié)果不太準(zhǔn)，這個(gè)可以通過調(diào)整業(yè)務(wù)模型、邏輯來修正。畢竟這是一條提升Lucene性能的有效方法。
細(xì)細(xì)想來，正是由于這個(gè)break會(huì)導(dǎo)致結(jié)果集大的關(guān)鍵詞提前出來，搜索時(shí)間少，結(jié)果集小的關(guān)鍵詞不可避免會(huì)走完整個(gè)索引，相應(yīng)的搜索時(shí)間會(huì)長(zhǎng)一點(diǎn)。
四、效果
由于具體嵌入代碼的過程極其繁瑣，隱士將在第二回詳細(xì)講解。這第一回先來個(gè)Big picture。
歷盡千辛萬苦，隱士終于搞定了這套程序，效果可以從隱士做的視頻搜索http://so.mdbchina.com/video/%E7%BE%8E%E5%A5%B3看出。
這個(gè)關(guān)鍵詞“美女”可以找到18萬個(gè)視頻，平均0.5秒返回結(jié)果，現(xiàn)在用上了新算法，只要0.06x秒返回結(jié)果，而且返回結(jié)果足夠好了，估算的8.5萬個(gè)結(jié)果雖然離18萬有很大差距，不過由于是估算的，差2-3倍應(yīng)屬可以接受的。
由算法的特性可知，while里面的hc.collect總可以在常量時(shí)間內(nèi)完成，循環(huán)次數(shù)又是<=常量，該算法的時(shí)間復(fù)雜度只和BooleanQuery的復(fù)雜程度相關(guān)，和索引文件大小以及命中的Document在索引文件內(nèi)的分布密度沒有關(guān)系，因?yàn)锽ooleanQuery的復(fù)雜程度決定了countingSumScorer.next()需要經(jīng)過多少次判斷、多少次讀取索引文件，countingSumScorer.next()正是整個(gè)算法中耗時(shí)不定的部分。
現(xiàn)在這個(gè)視頻搜索的索引文件接近3G，熱門關(guān)鍵詞可以在0.0x秒返回結(jié)果，隱士相信即使以后索引文件上到10G，依然可以在0.0x秒返回結(jié)果。 | 
