版權(quán)聲明：可以任意轉(zhuǎn)載，轉(zhuǎn)載時(shí)請(qǐng)務(wù)必以超鏈接形式標(biāo)明文章原始出處和作者信息及本聲明
http://www.chedong.com/tech/weblucene.html

內(nèi)容摘要：
為Lucene做一個(gè)通用XML接口一直是我最大的心愿：更方便的在WEB應(yīng)用中嵌入全文檢索功能

提供了XML的數(shù)據(jù)輸入接口：適合將原有基于各種數(shù)據(jù)庫的數(shù)據(jù)源導(dǎo)入到全文索引中，保證了數(shù)據(jù)源的平臺(tái)無關(guān)性；
通過了基于XML的搜索結(jié)果輸出：方便了通過XSLT進(jìn)行前臺(tái)的結(jié)果顯示；
MySQL / / JSP Oracle - DB - ==> XML ==> (Lucene Index) ==> XML - ASP MSSQL / - PHP MS Word / / / XHTML PDF / =XSLT=> - TEXT / XML /_________WebLucene__________/ 使用過程如下：
將數(shù)據(jù)用腳本導(dǎo)出成XML格式；
將XML數(shù)據(jù)源導(dǎo)入LUCENE索引；
從WEB界面得到XML結(jié)果輸出，并通過XSLT生成HTML頁面

站內(nèi)全文檢索的必要性
雖然大型搜索引擎的功能已經(jīng)越來越強(qiáng)大了，很多站點(diǎn)都使用了Google的站內(nèi)檢索site:domain.com代替了自己的站內(nèi)數(shù)據(jù)庫“全文”檢索。但依靠GOOGLE這樣的大型搜索引擎做站內(nèi)檢索會(huì)有以下弊端：

數(shù)量有限：搜索引擎并不會(huì)深度遍歷一個(gè)網(wǎng)站，而將網(wǎng)站所有的內(nèi)容都索引進(jìn)去，比如Google就喜歡靜態(tài)網(wǎng)頁，而且是最新更新的，而不喜歡帶?的動(dòng)態(tài)網(wǎng)頁，Google甚至?xí)ㄆ趯⑷鄙偃肟诘木W(wǎng)站內(nèi)容逐漸拋棄；
更新慢：搜索引擎針對(duì)站點(diǎn)的更新頻率也是有一定周期的，很多內(nèi)容需要一定時(shí)間后才能進(jìn)入GOOGLE的索引：目前Google Dance的周期是21天左右；
內(nèi)容不精確：搜索引擎需要通過頁面內(nèi)容提取技術(shù)將導(dǎo)航條，頁頭頁尾等內(nèi)容過濾掉，反而不如直接從后臺(tái)數(shù)據(jù)庫提取數(shù)據(jù)來得直接，這種摘要和排重機(jī)制是很難實(shí)現(xiàn)的；
無法控制輸出：也許有更多的輸出需求，按時(shí)間排序，按價(jià)格，按點(diǎn)擊量，按類目過濾等
系統(tǒng)的搭建
下載：
http://sourceforge.net/projects/weblucene/

XML數(shù)據(jù)源的導(dǎo)入：

只要數(shù)據(jù)源可以導(dǎo)出成3層的XML結(jié)構(gòu)，就都可以用IndexRunner這個(gè)命令行工具導(dǎo)入：

比如從數(shù)據(jù)庫導(dǎo)出：news_dump.xml
<?xml version="1.0" encoding="GB2312"?>
<Table>
<Record>
<Title>標(biāo)題</Title>
<Author>作者</Author>
<Content>內(nèi)容</Content>
<PubTime>2003-06-29</PubTime>
</Record>
<Record>
<Title>My Title</Title>
<Author>chedong</Author>
<Content>abc</Content>
<PubTime>2003-06-30</PubTime>
</Record>
...
</Table>

IndexRunner -i news_dump.xml -o c:/index -t Title,Content -n Author
-i news_dump.xml: 以news_dump.xml為數(shù)據(jù)源
-o c:/index 索引庫建立在c:/index目錄下
索引建立Title Author Content PubTime這幾個(gè)字段外，按以下規(guī)則建立索引：
-t Title,Content 一個(gè)進(jìn)行分詞的全文索引TokenIndex：數(shù)據(jù)是Title Content這2個(gè)字段
-n Author 一個(gè)不分詞的索引：NoTokenIndex：數(shù)據(jù)源是Author這個(gè)字段。

對(duì)于RSS數(shù)據(jù)源：
<?xml version="1.0"?>
<rss version="0.92">
<channel>
<title>Amazon: Books Arts &amp; Photography</title>
<link>http://www.lockergnome.com/</link>
<description>Amazon RSS Feed</description>
<lastBuildDate>Sun, 29 Jun 2003 01:05:01 GMT</lastBuildDate>
<docs>http://www.lockergnome.com/</docs>
<webMaster>amazonfeed@lockergnome.com (Lockergnome RSS Generator)</webMaster>
<item>
<title>The Artist's Way: A Spiritual Path to Higher Creativity - 11.17</title>
<link>http://www.amazon.com/exec/obidos/ASIN/1585421464/lockergnomedigit/?ref=nosim&amp;dev-it=D34HUVGKB34YFX</link>
<description>http://www.lockergnome.com/ </description>
</item>
...
</channel>

IndexRunner -i http://www.example.com/rss.xml -o c:/index -t title,description -n link -l 4
-l 4 表示拿第4層節(jié)點(diǎn)作為字段映射，

IndexRunner還提供了-a -m這兩個(gè)選項(xiàng)：用于增量索引和批量索引優(yōu)化。
-a 增量索引，表示在原有索引的基礎(chǔ)上擴(kuò)展
-m mergeFactor 在Lucene中mergeFactor是一個(gè)針對(duì)批量索引的優(yōu)化參數(shù)，控制多少條處理完多少條記錄（Document）后，寫入一次索引，寫入頻率越高，內(nèi)存使用越少，但索引速度越慢，所以在大批量數(shù)據(jù)導(dǎo)入時(shí)需要增大文件寫入的間隔，多讓索引在內(nèi)存中操作。

搜索結(jié)果輸出：

以下是系統(tǒng)設(shè)計(jì)過程中一些設(shè)計(jì)的思路：

做為工業(yè)標(biāo)準(zhǔn)的XML
記得以前有關(guān)于肯德基的炸薯?xiàng)l斷頓的報(bào)道。從這個(gè)事件報(bào)道中我們可以看到一種更高效的管理體系：對(duì)于快餐店這樣全球性的企業(yè)來說，要保證各地提供的薯?xiàng)l品質(zhì)，成本最低的方法肯定是依靠機(jī)器而不是廚師，如果要求薯?xiàng)l機(jī)能夠處理各種形狀不一的土豆，機(jī)器的復(fù)雜程度和維護(hù)成本都會(huì)很高。所以土豆必須嚴(yán)格符合工業(yè)標(biāo)準(zhǔn)才能讓結(jié)構(gòu)比較簡單的薯?xiàng)l機(jī)生產(chǎn)出符合標(biāo)準(zhǔn)的薯?xiàng)l，因此，薯?xiàng)l的加工機(jī)械會(huì)嚴(yán)格按照土豆協(xié)會(huì)的土豆工業(yè)標(biāo)準(zhǔn)設(shè)計(jì)。高質(zhì)量的原料可以大大降低后期加工設(shè)備的成本，因此從總體成本上講還是合算的。
對(duì)于軟件應(yīng)用開發(fā)者來說：應(yīng)用和應(yīng)用之間，企業(yè)和企業(yè)之間交換的數(shù)據(jù)好比就是土豆，白菜，按照嚴(yán)格的XML標(biāo)準(zhǔn)設(shè)計(jì)的接口作為企業(yè)之間后臺(tái)數(shù)據(jù)交換的工業(yè)標(biāo)準(zhǔn)，雖然不如簡單的CSV格式高效，但缺能大大簡化下游工序的后期加工成本。

不難想象為什么處理HTML的瀏覽器：IE和Mozilla等瀏覽器軟件大小都在10M以上，但一般處理XML的解析器一般都在幾百K。除了沒有界面外，HTML瀏覽器需要為太多不規(guī)范的HTML代碼提供大量容錯(cuò)處理也是一個(gè)很重要的原因，而語法嚴(yán)格，規(guī)則簡單的XML處理器就可以做的很簡短，高效，體積越“小”就意味著適應(yīng)性越廣：這點(diǎn)在手機(jī)這樣的硬件配置比較低的設(shè)備環(huán)境中顯得尤其重要。

雖然XML在后臺(tái)數(shù)據(jù)交換方面，有著巨大的潛力。在前臺(tái)表現(xiàn)方面，XML并不會(huì)馬上代替HTML，很多通過XSLT輸出的HTML仍然需要結(jié)合CSS來進(jìn)行表現(xiàn)。XML ==XSLT==> HTML + CSS。但是由于太多的網(wǎng)頁都是用HTML做的，相信XML沒有必要馬上代替這些已有的機(jī)制。

此外在應(yīng)用的國際化支持方面XML和Java簡直是絕配：XML數(shù)據(jù)源用Java解析后是UNICODE，這樣無論是日文，繁體中文還是德文的內(nèi)容我們都可以在一個(gè)索引庫中同時(shí)進(jìn)行搜索。這樣針對(duì)其他語言的支持只是設(shè)計(jì)各種語言界面的問題了。

GBK / / BIG5 BIG5 - UNICODE ====> Unicode - GB2312 SJIS - (XML) (XML) - SJIS ISO-8859-1 / / ISO-8859-1
使用XML的另外一個(gè)額外好處在于：開發(fā)人員一般都沒有仔細(xì)理解Java的字符集（其實(shí)上是JVM的缺省file.encoding屬性）受系統(tǒng)本地化設(shè)置的影響，基于XML的輸入使得數(shù)據(jù)的字符解碼過程變得透明：不用再和用戶解釋需要如何解碼，編碼數(shù)據(jù)源。不過，XML的學(xué)習(xí)成本還是比較高的，假設(shè)你HTML的學(xué)習(xí)成本是1，XML則可能為10，而XSLT的學(xué)習(xí)成本則可能高達(dá)100。

傳統(tǒng)數(shù)據(jù)庫應(yīng)用的全文檢索加速
讓數(shù)據(jù)庫負(fù)責(zé)精確匹配，將模糊匹配用獨(dú)立的系統(tǒng)實(shí)現(xiàn)
一個(gè)站點(diǎn)內(nèi)容積累在萬級(jí)以上，站內(nèi)全文檢索就會(huì)是用戶定位最主要的手段，而關(guān)鍵詞檢索是用戶最熟悉的方法。因此基于數(shù)據(jù)庫的傳統(tǒng)WEB應(yīng)用在全文檢索需求還是很大的。

但是可怕的%like%數(shù)據(jù)庫操作可能會(huì)吃掉數(shù)據(jù)庫服務(wù)器90%以上的CPU。Oracle MSSQL等數(shù)據(jù)庫服務(wù)器中數(shù)據(jù)庫內(nèi)置的全文檢索基本上都不太適合WEB應(yīng)用。而數(shù)據(jù)庫另外一個(gè)的弊端在于對(duì)于條件簡單的查詢返回結(jié)果集非常大：數(shù)據(jù)庫并不知道如何面向用戶最關(guān)心的的頭100條結(jié)果進(jìn)行優(yōu)化。根據(jù)以前的統(tǒng)計(jì)：頭100條結(jié)果往往已經(jīng)可以滿足95％以上用戶需求。

需要緩存設(shè)計(jì)：根據(jù)我們的經(jīng)驗(yàn)，在應(yīng)用設(shè)計(jì)中沒有必要進(jìn)行內(nèi)置的結(jié)果緩存設(shè)計(jì)：讓前臺(tái)的應(yīng)用服務(wù)器內(nèi)置的緩存機(jī)制或者反相代理緩存服務(wù)器進(jìn)行緩存就夠了。

數(shù)據(jù)同步策略
總體上講，全文檢索和數(shù)據(jù)庫其實(shí)是2種根本不同的應(yīng)用模式，全文檢索系統(tǒng)其實(shí)往往也沒有必要和數(shù)據(jù)庫那么高的實(shí)時(shí)同步機(jī)制，如果按照：低更新，高緩存的模式進(jìn)行設(shè)計(jì)：數(shù)據(jù)庫數(shù)據(jù)到全文索引的同步過程一般都可以通過腳本定期將數(shù)據(jù)庫的數(shù)據(jù)導(dǎo)出成XML，然后進(jìn)入Lucene的全文索引。而針對(duì)原有數(shù)據(jù)記錄的更新和刪除，其實(shí)一般可以通過定期的重建索引解決。WebLucene其中索引部分是一個(gè)IndexRunner的命令行程序?qū)崿F(xiàn)的。

結(jié)果排序策略
站內(nèi)全文索引另外一個(gè)很重要的需求是可定制的排序：按時(shí)間，按價(jià)格，按點(diǎn)擊量……Lucene全文索引缺省只提供了根據(jù)關(guān)鍵詞在原文中的匹配度排序，而任何根據(jù)某個(gè)字段的值進(jìn)行排序的都無法避免再次遍歷數(shù)據(jù)，從而導(dǎo)致性能有數(shù)量級(jí)的下降（等于又是做%Like%檢索），而在索引中，除了匹配度SCORE外，唯一能用來排序的就是索引記錄的ID，所以一個(gè)比較高效率實(shí)現(xiàn)定制排序的方法時(shí)：在索引時(shí)，讓進(jìn)入Lucene全文的順序?qū)?yīng)著一定規(guī)則：比如時(shí)間，然后在搜索時(shí)，讓搜索結(jié)果按照索引記錄的ID進(jìn)行排序（或倒排）。

搜索結(jié)果關(guān)鍵詞標(biāo)引的實(shí)現(xiàn)
搜索結(jié)果中關(guān)鍵詞通過紅色或者黑體字標(biāo)記出來，為了能夠更恰當(dāng)?shù)娘@示相關(guān)上下文的問題，標(biāo)引是通過限制了一個(gè)掃描范圍，然后根據(jù)一個(gè)分析器將指定的詞流式的讀取出來，然后

全文檢索和其他應(yīng)用的集成
其實(shí)核心的是一個(gè)Lucene的XML接口：SAX方式的數(shù)據(jù)導(dǎo)入和DOM方式的結(jié)果輸出。

XML的數(shù)據(jù)源定義：
只要是能夠映射成表＝》記錄＝》字段這樣層次結(jié)構(gòu)的都可以。因此WebLucene索引的設(shè)計(jì)比較靈活，甚至可以直接用來索引RSS。

XML結(jié)果定義：參考了Google的XML接口的設(shè)計(jì)

如果沒有SERVLET界面，提供XML輸出的DOMSearcher也可以很方便集成到各種應(yīng)用系統(tǒng)中。

參考資料：

系統(tǒng)設(shè)計(jì)中使用的一些模塊：
Jakarta Lucene:
http://jakarta.apache.org/lucene/

Xerces / Xalan
http://xml.apache.org/

Log4j
http://jakarta.apache.org/log4j/

Google的XML接口定義：
http://www.google.com/google.dtd