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