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