注（2007-5-22）：最新一次更新的時(shí)候，我再次研究了一下Lucene，讀完了Lucene In Action，并且實(shí)際的使用Lucene構(gòu)建了一個(gè)小型的搜索系統(tǒng)之后，我感覺(jué)到很慚愧，因?yàn)槲乙恢睂?duì)Lucene有不滿(mǎn)的心理，認(rèn)為它做的不好（可能受了國(guó)內(nèi)的某些使用Lucene構(gòu)建搜索引擎的網(wǎng)站的影響，因?yàn)樗麄儤?gòu)建的都很差，現(xiàn)在想來(lái)，可能是他們和我一樣沒(méi)有真正深入理解Lucene）?，F(xiàn)在我才發(fā)現(xiàn)，Lucene的作者在大方向上考慮問(wèn)題的全面比我要好很多（雖然有些功能我不知道是否真的有用）。現(xiàn)在我的感受是：
1）Lucene對(duì)查詢(xún)的理解十分深入，幾乎什么樣的查詢(xún)需求它都考慮到了。而對(duì)于普通的商業(yè)搜索引擎來(lái)說(shuō)（比如，百度），它們只是考慮到了布爾查詢(xún)模式，遠(yuǎn)不及Lucene里面的查詢(xún)方式多；
2）Lucene對(duì)過(guò)濾和排序的處理已經(jīng)能夠滿(mǎn)足90%的要求了。過(guò)濾可以把不需要的結(jié)果刪除，而排序則可以根據(jù)某個(gè)域的值來(lái)進(jìn)行結(jié)果排序?；镜拇怪彼阉饕?，是必須這些功能的，因?yàn)檫@些功能能夠縮小查詢(xún)的結(jié)果集，提高用戶(hù)體驗(yàn)。而百度等商業(yè)搜索引擎顯然是不需要（或者沒(méi)有提供）這些功能的。
3）Lucene的分值計(jì)算效果不錯(cuò)。拋開(kāi)基本的IR的那些標(biāo)準(zhǔn)的分值計(jì)算算法不說(shuō)（誰(shuí)都知道總體上Lucene使用了簡(jiǎn)化的向量模型，但實(shí)際上Lucene在布爾模型查詢(xún)上面也使用了簡(jiǎn)化的擴(kuò)展布爾模型分值計(jì)算公式），Lucene支持了大部分額外的基于經(jīng)驗(yàn)的分值計(jì)算。舉例來(lái)說(shuō)，查詢(xún)“中國(guó)北京”的時(shí)候，以下是幾個(gè)文檔的實(shí)際排序（直接解析這個(gè)查詢(xún)短語(yǔ)是得不到這個(gè)結(jié)果的，見(jiàn)第4點(diǎn)）：
中國(guó)北京
北京中國(guó)
中國(guó)可愛(ài)北京
北京屬于中國(guó)
4）Lucene不提供真正的查詢(xún)串解析?；谖姆ǖ牟樵?xún)串解析，一個(gè)嚴(yán)重的結(jié)果就是容錯(cuò)太差，所以，我們幾乎可以認(rèn)為L(zhǎng)ucene并不提供實(shí)際有用的查詢(xún)串解析。所以呢，上面我們說(shuō)的“中國(guó)北京”需要您自己把它解析為：
PhraseQuery query = new PhraseQuery();
query.add(new Term("name","中國(guó)"));
query.add(new Term("name","北京"));
query.setSlop(1000);
然后才會(huì)有上面的那個(gè)結(jié)果。所以，使用Lucene的第一步是提供您自己的查詢(xún)串解析器。
5）理解Lucene的算法限制。Doug Cutting不是神仙，他也無(wú)法解決算法的問(wèn)題，所以呢，幾乎所有算法的限制都會(huì)在Lucene里面出現(xiàn)，比如，RangeQuery查詢(xún)速度極慢，Sort排序需要很大的內(nèi)存來(lái)緩沖Field的值。這些并不是Doug Cutting的錯(cuò)，而是算法的限制，我想應(yīng)該沒(méi)有人能夠解決這類(lèi)問(wèn)題吧？（雖然從IR中我們知道RangeQuery可以使用B+樹(shù)等結(jié)構(gòu)來(lái)加快查詢(xún)，不過(guò)，我們似乎不能夠責(zé)怪Lucene，因?yàn)長(zhǎng)ucene使用的是緊湊的文件結(jié)構(gòu)，難以支持B+樹(shù)結(jié)構(gòu)） 如果您真的需要考慮這些問(wèn)題的話(huà)，您可以自己修改Lucene的代碼或者提供額外的擴(kuò)展。
6）理解Lucene的其他限制。在實(shí)際應(yīng)用的過(guò)程中，您會(huì)發(fā)現(xiàn)Lucene有各種各樣的限制，在這里，我想提醒您2個(gè)問(wèn)題：a)緩沖同步；b)寫(xiě)/讀同步。Lucene的緩沖做的不好，您可以根據(jù)實(shí)際情況自己擴(kuò)展，在擴(kuò)展的時(shí)候，請(qǐng)時(shí)刻注意緩沖和實(shí)際數(shù)據(jù)同步的問(wèn)題。寫(xiě)/讀同步其實(shí)是Lucene自己的問(wèn)題，在同時(shí)讀寫(xiě)一個(gè)Directory的時(shí)候，寫(xiě)的數(shù)據(jù)并不會(huì)馬上表現(xiàn)到讀上面，所以呢，要么關(guān)閉寫(xiě)，要么自己緩沖寫(xiě)結(jié)果。
Lucene是一個(gè)開(kāi)源的基于java的搜索引擎，它只包含IR(Information Retrieve)部分。它即不是唯一的也不是最好的一個(gè)開(kāi)源搜索引擎，更好的比如egothor，但是它是文檔最全面和受到關(guān)注最多的一個(gè)。Nutch是基于Lucene并加入了分布式和Crawler部分的搜索引擎。在本文中，作者試圖從掌握的知識(shí)范圍談?wù)撘幌滤鼈兪褂玫募夹g(shù)和一般商業(yè)文本搜索引擎使用的技術(shù)之間的距離。因?yàn)樽髡咚接邢?，僅僅擁有2年不到的搜索研究和實(shí)踐經(jīng)驗(yàn)，不足之處請(qǐng)大家多多指教。謝謝。
1 網(wǎng)絡(luò)搜索引擎的構(gòu)架
一個(gè)專(zhuān)業(yè)的網(wǎng)絡(luò)搜索引擎至少包含3部分，即抓取、處理和搜索。下面是它們的一般功能：
抓?。鹤ト。ㄖ┲搿⑴老x(chóng)、crawler、spider等）程序負(fù)責(zé)爬行特定網(wǎng)絡(luò)（也可能是整個(gè)網(wǎng)絡(luò)），把網(wǎng)絡(luò)上的頁(yè)面和其它需要的文件下載到本地來(lái)。目前的難點(diǎn)是web2.0的普及導(dǎo)致的js分析和身份認(rèn)證等問(wèn)題。
處理：處理（分類(lèi)、信息抽取、數(shù)據(jù)挖掘、classify、information extraction、data mining等）程序?qū)ψセ貋?lái)的頁(yè)面進(jìn)行分析，比如，對(duì)網(wǎng)站的內(nèi)容進(jìn)行分類(lèi)、對(duì)新聞頁(yè)面的攣判畔⒔ 刑崛?、页面模皨?傘⒍愿鞲鐾 局 淶墓叵到 屑撲愕鵲取?/span>
搜索：搜索（information retrieve）程序負(fù)責(zé)把文檔填充到數(shù)據(jù)庫(kù)，然后根據(jù)查詢(xún)字符串到數(shù)據(jù)庫(kù)中尋找最相關(guān)的文檔展現(xiàn)給用戶(hù)。
僅僅從搜索引擎的構(gòu)架來(lái)看，Lucene(Nutch)缺失的一環(huán)是信息的處理。信息的處理恰恰是整個(gè)搜索引擎中最核心的技術(shù)。
2 信息抓取
網(wǎng)絡(luò)信息抓取包含了網(wǎng)頁(yè)抓取、文本文件抓取和其它文件抓取。對(duì)于使用http(還有https)等協(xié)議的網(wǎng)站來(lái)說(shuō)，信息抓取的主要過(guò)程是：
根據(jù)指定uri地址，進(jìn)入第一個(gè)頁(yè)面；
分析頁(yè)面構(gòu)成，得到超鏈接地址，把地址加入到待下載鏈接中去；
當(dāng)還有未下載的鏈接時(shí)，下載對(duì)應(yīng)頁(yè)面，保存頁(yè)面，并返回到第2步；
所有鏈接都下載完畢，退出。
普通的信息抓取一般可以被稱(chēng)為Spider，它利用基本的html頁(yè)面分析器（比如，HtmlParser、NeckoHtml、JTidy等）來(lái)解析html頁(yè)面，得到頁(yè)面中的超鏈接。一般的說(shuō)，一個(gè)Spider由以下2部分組成：
http下載器。給定一個(gè)uri地址，http下載器負(fù)責(zé)把這個(gè)地址的數(shù)據(jù)下載回來(lái)?；蛟S大家會(huì)認(rèn)為這個(gè)很容易，其實(shí)不然。網(wǎng)絡(luò)中的頁(yè)面，除了http協(xié)議以外，https安全協(xié)議也是十分常用的一種協(xié)議。當(dāng)你要下載的數(shù)據(jù)需要認(rèn)證的時(shí)候，你還需要讓你的下載器支持認(rèn)證。當(dāng)你下載的數(shù)據(jù)需要登錄的時(shí)候，你還需要讓你的下載器支持Cookie。所以，你的下載器僅僅支持http還是遠(yuǎn)遠(yuǎn)不夠的。在這點(diǎn)上，Nutch還差得遠(yuǎn)。
html頁(yè)面解析器。html頁(yè)面解析器并不是支持html頁(yè)面就萬(wàn)事大吉了的，現(xiàn)在的很多頁(yè)面其實(shí)使用的是xml的構(gòu)建方法，雖然html和xml很像，但是，它們的tag名字顯然有很大差別。除此以外，wap手機(jī)類(lèi)頁(yè)面也是你可能需要支持的頁(yè)面。Nutch使用的是NeckoHtml或者JTidy。實(shí)際應(yīng)用表明JTidy比較一般，但是NeckoHtml具有不錯(cuò)的效果。在開(kāi)源的軟件中，它應(yīng)該算是最好的一個(gè)html頁(yè)面解析器。然而，它和IE或者M(jìn)ozilla這些瀏覽器的html parser比較起來(lái)，還是有一段距離的。除此以外，這類(lèi)Spider僅僅只是把頁(yè)面分析成了DOM樹(shù)，它并不能夠?qū)赼jax技術(shù)的web2.0頁(yè)面進(jìn)行有效處理。要想處理那些大量使用ajax技術(shù)或者大量運(yùn)用js代碼的頁(yè)面數(shù)據(jù)，Spider需要的仍然是js處理能力。當(dāng)然了，關(guān)于js的處理也可以被劃分到數(shù)據(jù)處理部分去。
3 信息處理
似乎在Lucene(Nutch)面前談?wù)撔畔⑻幚盹@得有點(diǎn)不專(zhuān)業(yè)，因?yàn)樗鼈儔焊筒恢С?。但是，信息處理部分你還是可以自己編寫(xiě)后嵌入到Lucene(Nutch)里面去的。信息處理話(huà)題太大，作者沒(méi)有這個(gè)膽量和水平對(duì)此妄加談?wù)?，雖然這個(gè)是作者一直研究的主要方向。
唯一可以肯定的就是，信息處理需要的知識(shí)至少有2點(diǎn)：1，機(jī)器學(xué)習(xí)(ML)；2，自然語(yǔ)言理解(NLP)。前者典型的包括SVM、HMM等，后者包括HNC、知網(wǎng)等。筆者自信對(duì)ML有一定的理解，但是，對(duì)NLP的理解不太深入，還沒(méi)有形成一個(gè)完整的解決方案。
4 信息獲取
對(duì)信息獲取的研究已經(jīng)好多好多年了，多到那個(gè)時(shí)候作者都未出生。這部分主要分為2個(gè)步驟，第一個(gè)步驟是把文檔填入到數(shù)據(jù)庫(kù)（也就是所謂的構(gòu)建索引）；第二個(gè)部分就是根據(jù)用戶(hù)輸入得到一系列最相關(guān)文檔（即所謂的搜索）。得到最相關(guān)文檔無(wú)外乎就是比較2個(gè)文檔的相似度。當(dāng)用戶(hù)輸入一個(gè)字符串（即一個(gè)文檔）之后，搜索引擎根據(jù)這個(gè)文檔到數(shù)據(jù)庫(kù)中尋找和它最相關(guān)的文檔，然后返回給用戶(hù)。實(shí)際搜索引擎必須考慮速度的問(wèn)題，不可能像理論上說(shuō)的那樣去做。搜索的時(shí)候，一般有如下3步：
查詢(xún)字串解析。查詢(xún)的組織方式有很多種，比如布爾查詢(xún)等。一般商業(yè)文本搜索引擎支持的查詢(xún)大約這樣：“北京黃河 AND tom cat(OR 美麗 -祖國(guó))jerry + mouse”。即支持AND(+)、OR(|)、-、括號(hào)和引號(hào)的復(fù)合表達(dá)式。光解析還不行啊，你還得進(jìn)行額外的優(yōu)化，比如，對(duì)于“北京北京北京北京”這個(gè)串來(lái)說(shuō)，它和“北京”的效果是一樣的吧？Lucene在這個(gè)方面做了不少工作，只是，你仍然需要自己寫(xiě)一個(gè)更接近中文和商業(yè)搜索引擎的查詢(xún)字串解析器。你可以根據(jù)需要，決定是把表達(dá)式優(yōu)化為適合并行計(jì)算還是最小計(jì)算量的形式。
說(shuō)到布爾查詢(xún)，本人之所以認(rèn)為L(zhǎng)ucene距離實(shí)用還有一段距離的原因也部分基于此。為什么？因?yàn)長(zhǎng)ucence使用了java版本的Yacc來(lái)自動(dòng)構(gòu)建了布爾表達(dá)式的解析器，然而，它的文法過(guò)于正規(guī)，無(wú)法處理下面的字符串：
我們 AND AND AND 他們
作為一個(gè)追求完美的人，作者實(shí)在無(wú)法接受這樣無(wú)法忍受的“錯(cuò)誤”。
查詢(xún)。查詢(xún)的部分沒(méi)有什么太多可以說(shuō)的。有一點(diǎn)是，算法該優(yōu)化的都沒(méi)有優(yōu)化。不過(guò)，對(duì)于一個(gè)處于初級(jí)開(kāi)發(fā)中，并且開(kāi)發(fā)人員缺乏的Project來(lái)說(shuō)，這樣就足夠了。
結(jié)果排序。Lucene使用的分值計(jì)算方法在比較接近于IR理論上使用的一些計(jì)算方法。可是，實(shí)際中的分值計(jì)算卻比這個(gè)要麻煩很多。一個(gè)例子就是Lucene使用的方法沒(méi)有考慮到查詢(xún)?cè)~語(yǔ)之間的緊密位置。比如，對(duì)于“北京商店”和“北京 商店”來(lái)說(shuō)，得到的前幾個(gè)結(jié)果顯然應(yīng)該差別很大，這是因?yàn)榍罢吒鼉A向于“北京”和“商店”這2個(gè)詞語(yǔ)在一起的情況。要Lucene做到這一點(diǎn)其實(shí)也容易，只是，它會(huì)嚴(yán)重的降低搜索速度（幾倍）。
實(shí)際應(yīng)用中，還常常需要計(jì)算某些屬性的值的權(quán)重。比如，新聞搜索里面，今天的新聞是不是應(yīng)該比昨天的新聞權(quán)重大一點(diǎn)呢？Lucene未能支持這點(diǎn)。
5 速度第一
對(duì)于搜索引擎來(lái)說(shuō)，速度絕對(duì)是第一個(gè)需要考慮的問(wèn)題。信息抓取的速度顯然不在軟件能夠解決的范圍內(nèi)，它只能通過(guò)增加帶寬和多級(jí)更新策略來(lái)提高了。信息處理的速度不在本文的討論之列。信息獲取的時(shí)候，有2個(gè)地方需要考慮到速度：
索引速度。索引速度包含索引的構(gòu)建速度、文檔的修改速度和文檔的刪除速度。在粗粒度上說(shuō)，Nutch采用的基于MapReduce策略的分布式索引構(gòu)建方法是一個(gè)不錯(cuò)的構(gòu)架。在細(xì)粒度上說(shuō)，Lucene使用的內(nèi)存緩沖和磁盤(pán)小索引合并的方法也是一個(gè)很好的構(gòu)架。它們?cè)跇?gòu)建索引上的表現(xiàn)都是令人稱(chēng)道的。在文檔的刪除上，Lucene使用的標(biāo)記后再刪除的方法是無(wú)可厚非的。在文檔的修改和文檔的追加上面，Lucene做的還差強(qiáng)人意。文檔在修改的時(shí)候，唯一的辦法就只能是先刪除然后再追加。這點(diǎn)顯然是不能令人滿(mǎn)意的。
查詢(xún)速度。Lucene(Nutch)認(rèn)為分布式的查詢(xún)是不可取的，因?yàn)樗俣雀?。其?shí)并不是速度慢，而是分布式查詢(xún)需要一個(gè)快速的構(gòu)架，這個(gè)構(gòu)架涉及到搜索引擎的所有方面。暫時(shí)不是Nutch能夠達(dá)到的。所以，Lucene(Nutch)的查詢(xún)都是在一臺(tái)機(jī)器上運(yùn)行的。另外，Lucene因?yàn)樗捎玫姆种涤?jì)算方法的緣故，它不需要加載詞語(yǔ)在文檔中的位置信息，所以，它表面上看起來(lái)比其它搜索引擎快速了。其實(shí)是犧牲精度獲得速度，另外，它自己使用的文件結(jié)構(gòu)嚴(yán)重的制約了它的速度。
沒(méi)有引入緩沖是Lucene(Nutch)的另外一個(gè)嚴(yán)重失誤。在這個(gè)構(gòu)架里面，你可以自己 構(gòu)建一個(gè)查詢(xún)結(jié)果緩沖（一級(jí)緩沖），但是，你很難構(gòu)建一個(gè)基于詞語(yǔ)的索引緩沖 （二級(jí)緩沖）。這對(duì)于一個(gè)大搜索量的系統(tǒng)來(lái)說(shuō)，是不可想象的。更何況普通商業(yè)搜 索引擎還會(huì)有第三級(jí)緩沖。
6 精度第二
如果僅僅從Lucene(Nutch)支持的查詢(xún)方式和分值計(jì)算來(lái)看，Lucene(Nutch)不存在精度的問(wèn)題，因?yàn)樗鼈兌际怯?jì)算了全部數(shù)據(jù)的。商業(yè)搜索引擎因?yàn)閿?shù)據(jù)量過(guò)大的緣故，不得不使用一些估計(jì)的算法來(lái)減少磁盤(pán)數(shù)據(jù)的讀取，這會(huì)導(dǎo)致精度的略微丟失。反過(guò)來(lái)說(shuō)，Lucene無(wú)法支持大規(guī)模數(shù)據(jù)。
7 效率第三
這里說(shuō)的效率主要是空間效率。比如，程序的內(nèi)存占用和磁盤(pán)占用。Lucene使用了zlib壓縮技術(shù)來(lái)壓縮文檔內(nèi)容，還有使用了簡(jiǎn)單的壓縮整數(shù)的方法。但是，它使用的壓縮方法還是太少了，它少用壓縮的結(jié)果是：1）文件結(jié)構(gòu)和代碼簡(jiǎn)單；2）查詢(xún)速度變慢；3）索引segment合并快速；4）磁盤(pán)占用增加。同時(shí)，它幾乎不用壓縮也和它放棄緩沖有很大聯(lián)系，因?yàn)閴嚎s過(guò)的索引很容易放到內(nèi)存里面，這點(diǎn)十分滿(mǎn)足緩沖的空間需求。