版權聲明：可以任意轉載，轉載時(shí)請務(wù)必以超鏈接形式標明文章原始出處和作者信息及本聲明
http://www.chedong.com/tech/weblucene.html
關(guān)鍵詞：Lucene xml xslt web site search engine
內容摘要：
為L(cháng)ucene做一個(gè)通用XML接口一直是我最大的心愿：更方便的在WEB應用中嵌入全文檢索功能
- 提供了XML的數據輸入接口：適合將原有基于各種數據庫的數據源導入到全文索引中，保證了數據源的平臺無(wú)關(guān)性；
- 通過(guò)了基于XML的搜索結果輸出：方便了通過(guò)XSLT進(jìn)行前臺的結果顯示；
MySQL \ / JSP
Oracle - DB - ==> XML ==> (Lucene Index) ==> XML - ASP
MSSQL / - PHP
MS Word / \ / XHTML
PDF / =XSLT=> - TEXT
\ XML
\_________WebLucene__________/
使用過(guò)程如下：
- 將數據用腳本導出成XML格式；
- 將XML數據源導入LUCENE索引；
- 從WEB界面得到XML結果輸出，并通過(guò)XSLT生成HTML頁(yè)面
站內全文檢索的必要性
雖然大型搜索引擎的功能已經(jīng)越來(lái)越強大了，很多站點(diǎn)都使用了
Google的站內檢索site:domain.com代替了自己的站內數據庫“全文”檢索。但依靠GOOGLE這樣的大型搜索引擎做站內檢索會(huì )有以下弊端：
- 數量有限：搜索引擎并不會(huì )深度遍歷一個(gè)網(wǎng)站，而將網(wǎng)站所有的內容都索引進(jìn)去，比如Google就喜歡靜態(tài)網(wǎng)頁(yè)，而且是最新更新的，而不喜歡帶?的動(dòng)態(tài)網(wǎng)頁(yè)，Google甚至會(huì )定期將缺少入口的網(wǎng)站內容逐漸拋棄；
- 更新慢：搜索引擎針對站點(diǎn)的更新頻率也是有一定周期的，很多內容需要一定時(shí)間后才能進(jìn)入GOOGLE的索引：目前Google Dance的周期是21天左右；
- 內容不精確：搜索引擎需要通過(guò)頁(yè)面內容提取技術(shù)將導航條，頁(yè)頭頁(yè)尾等內容過(guò)濾掉，反而不如直接從后臺數據庫提取數據來(lái)得直接，這種摘要和排重機制是很難實(shí)現的；
- 無(wú)法控制輸出：也許有更多的輸出需求，按時(shí)間排序，按價(jià)格，按點(diǎn)擊量，按類(lèi)目過(guò)濾等
系統的搭建
下載：
http://sourceforge.net/projects/weblucene/XML數據源的導入：
只要數據源可以導出成3層的XML結構，就都可以用IndexRunner這個(gè)命令行工具導入：
比如從數據庫導出：news_dump.xml
<?xml version="1.0" encoding="GB2312"?>
<Table>
<Record>
<Title>標題</Title>
<Author>作者</Author>
<Content>內容</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為數據源
-o c:\index 索引庫建立在c:\index目錄下
索引建立Title Author Content PubTime這幾個(gè)字段外，按以下規則建立索引：
-t Title,Content 一個(gè)進(jìn)行分詞的全文索引TokenIndex：數據是Title Content這2個(gè)字段
-n Author 一個(gè)不分詞的索引：NoTokenIndex：數據源是Author這個(gè)字段。
對于RSS數據源：
<?xml version="1.0"?>
<rss version="0.92">
<channel>
<title>Amazon: Books Arts & 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&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層節點(diǎn)作為字段映射，
IndexRunner還提供了-a -m這兩個(gè)選項：用于增量索引和批量索引優(yōu)化。
-a 增量索引，表示在原有索引的基礎上擴展
-m mergeFactor 在Lucene中mergeFactor是一個(gè)針對批量索引的優(yōu)化參數，控制多少條處理完多少條記錄（Document）后，寫(xiě)入一次索引，寫(xiě)入頻率越高，內存使用越少，但索引速度越慢，所以在大批量數據導入時(shí)需要增大文件寫(xiě)入的間隔，多讓索引在內存中操作。
搜索結果輸出：
以下是系統設計過(guò)程中一些設計的思路：
做為工業(yè)標準的XML
記得以前有關(guān)于肯德基的炸薯條斷頓的報道。從這個(gè)事件報道中我們可以看到一種更高效的管理體系：對于快餐店這樣全球性的企業(yè)來(lái)說(shuō)，要保證各地提供的薯條品質(zhì)，成本最低的方法肯定是依靠機器而不是廚師，如果要求薯條機能夠處理各種形狀不一的土豆，機器的復雜程度和維護成本都會(huì )很高。所以土豆必須嚴格符合工業(yè)標準才能讓結構比較簡(jiǎn)單的薯條機生產(chǎn)出符合標準的薯條，因此，薯條的加工機械會(huì )嚴格按照土豆協(xié)會(huì )的土豆工業(yè)標準設計。高質(zhì)量的原料可以大大降低后期加工設備的成本，因此從總體成本上講還是合算的。
對于軟件應用開(kāi)發(fā)者來(lái)說(shuō)：應用和應用之間，企業(yè)和企業(yè)之間交換的數據好比就是土豆，白菜，按照嚴格的XML標準設計的接口作為企業(yè)之間后臺數據交換的工業(yè)標準，雖然不如簡(jiǎn)單的CSV格式高效，但缺能大大簡(jiǎn)化下游工序的后期加工成本。
不難想象為什么處理HTML的瀏覽器：IE和Mozilla等瀏覽器軟件大小都在10M以上，但一般處理XML的解析器一般都在幾百K。除了沒(méi)有界面外，HTML瀏覽器需要為太多不規范的HTML代碼提供大量容錯處理也是一個(gè)很重要的原因，而語(yǔ)法嚴格，規則簡(jiǎn)單的XML處理器就可以做的很簡(jiǎn)短，高效，體積越“小”就意味著(zhù)適應性越廣：這點(diǎn)在手機這樣的硬件配置比較低的設備環(huán)境中顯得尤其重要。
雖然XML在后臺數據交換方面，有著(zhù)巨大的潛力。在前臺表現方面，XML并不會(huì )馬上代替HTML，很多通過(guò)XSLT輸出的HTML仍然需要結合CSS來(lái)進(jìn)行表現。XML ==XSLT==> HTML + CSS。但是由于太多的網(wǎng)頁(yè)都是用HTML做的，相信XML沒(méi)有必要馬上代替這些已有的機制。
此外在應用的國際化支持方面XML和Java簡(jiǎn)直是絕配：XML數據源用Java解析后是UNICODE，這樣無(wú)論是日文，繁體中文還是德文的內容我們都可以在一個(gè)索引庫中同時(shí)進(jìn)行搜索。這樣針對其他語(yǔ)言的支持只是設計各種語(yǔ)言界面的問(wèn)題了。
GBK \ / BIG5
BIG5 - UNICODE ====> Unicode - GB2312
SJIS - (XML) (XML) - SJIS
ISO-8859-1 / \ ISO-8859-1
使用XML的另外一個(gè)額外好處在于：開(kāi)發(fā)人員一般都沒(méi)有仔細理解Java的字符集（其實(shí)上是JVM的缺省file.encoding屬性）受系統本地化設置的影響，基于XML的輸入使得數據的字符解碼過(guò)程變得透明：不用再和用戶(hù)解釋需要如何解碼，編碼數據源。不過(guò)，XML的學(xué)習成本還是比較高的，假設你HTML的學(xué)習成本是1，XML則可能為10，而XSLT的學(xué)習成本則可能高達100。
傳統數據庫應用的全文檢索加速
讓數據庫負責精確匹配，將模糊匹配用獨立的系統實(shí)現
一個(gè)站點(diǎn)內容積累在萬(wàn)級以上，站內全文檢索就會(huì )是用戶(hù)定位最主要的手段，而關(guān)鍵詞檢索是用戶(hù)最熟悉的方法。因此基于數據庫的傳統WEB應用在全文檢索需求還是很大的。
但是可怕的%like%數據庫操作可能會(huì )吃掉數據庫服務(wù)器90%以上的CPU。Oracle MSSQL等數據庫服務(wù)器中數據庫內置的全文檢索基本上都不太適合WEB應用。而數據庫另外一個(gè)的弊端在于對于條件簡(jiǎn)單的查詢(xún)返回結果集非常大：數據庫并不知道如何面向用戶(hù)最關(guān)心的的頭100條結果進(jìn)行優(yōu)化。根據以前的統計：頭100條結果往往已經(jīng)可以滿(mǎn)足95％以上用戶(hù)需求。
需要緩存設計：根據我們的經(jīng)驗，在應用設計中沒(méi)有必要進(jìn)行內置的結果緩存設計：讓前臺的應用服務(wù)器內置的緩存機制或者反相代理緩存服務(wù)器進(jìn)行緩存就夠了。
數據同步策略
總體上講，全文檢索和數據庫其實(shí)是2種根本不同的應用模式，全文檢索系統其實(shí)往往也沒(méi)有必要和數據庫那么高的實(shí)時(shí)同步機制，如果按照：低更新，高緩存的模式進(jìn)行設計：數據庫數據到全文索引的同步過(guò)程一般都可以通過(guò)腳本定期將數據庫的數據導出成XML，然后進(jìn)入Lucene的全文索引。而針對原有數據記錄的更新和刪除，其實(shí)一般可以通過(guò)定期的重建索引解決。WebLucene其中索引部分是一個(gè)IndexRunner的命令行程序實(shí)現的。
結果排序策略
站內全文索引另外一個(gè)很重要的需求是可定制的排序：按時(shí)間，按價(jià)格，按點(diǎn)擊量……Lucene全文索引缺省只提供了根據關(guān)鍵詞在原文中的匹配度排序，而任何根據某個(gè)字段的值進(jìn)行排序的都無(wú)法避免再次遍歷數據，從而導致性能有數量級的下降（等于又是做%Like%檢索），而在索引中，除了匹配度SCORE外，唯一能用來(lái)排序的就是索引記錄的ID，所以一個(gè)比較高效率實(shí)現定制排序的方法時(shí)：在索引時(shí)，讓進(jìn)入Lucene全文的順序對應著(zhù)一定規則：比如時(shí)間，然后在搜索時(shí)，讓搜索結果按照索引記錄的ID進(jìn)行排序（或倒排）。
搜索結果關(guān)鍵詞標引的實(shí)現
搜索結果中關(guān)鍵詞通過(guò)紅色或者黑體字標記出來(lái)，為了能夠更恰當的顯示相關(guān)上下文的問(wèn)題，標引是通過(guò)限制了一個(gè)掃描范圍，然后根據一個(gè)分析器將指定的詞流式的讀取出來(lái)，然后
全文檢索和其他應用的集成
其實(shí)核心的是一個(gè)Lucene的XML接口：SAX方式的數據導入和DOM方式的結果輸出。
XML的數據源定義：
只要是能夠映射成表＝》記錄＝》字段這樣層次結構的都可以。因此WebLucene索引的設計比較靈活，甚至可以直接用來(lái)索引RSS。
XML結果定義：參考了
Google的XML接口的設計如果沒(méi)有SERVLET界面，提供XML輸出的DOMSearcher也可以很方便集成到各種應用系統中。
參考資料：
系統設計中使用的一些模塊：
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
