【導讀】Lucene是一個開源的用于制作搜索引擎的框架。目前第二代搜索引擎的設計思路為利用。索結果，對搜索的結果進行篩選和排序，把最終的結果展示給用戶。Lucene良好的架構使得我們可以定義自己的分詞類，而Lucene豐富的功能也。本文介紹了搜索引擎的相關知識，分析了Lucene源碼，并對搜索引擎的未。本文詳細介紹了自己編寫的一款在上開發(fā)的基于Lucene的新聞搜。一些與Lucene無關的環(huán)節(jié)的實現(xiàn)思路。最后對實際項目進行了測試，并分析了測試結果。

　　

【正文】 一個數(shù)據(jù)源中的字段，我們需要選擇一個合適的索引方式， 需要設置這個字段是否需要索引，是否需要儲存，是否需要分詞。 顯然，所有的字段都需要我們索引和儲 存。但是需要進行分詞的只有 title 字段和content字段。因為無論 media 字段， url字段還是 showtime 字段都是作為一個整體操作的。 索引的建立與 優(yōu)化 萬事俱備之后便可以建立索引， 索引建立好了之后便需要對索引進行優(yōu)化。索引的優(yōu)化需要花費大量的時間，大約是 1個小時左右。所以，索引的優(yōu)化不能放在白天，這樣用戶查看的數(shù)據(jù)便會有 1個小時左右的延遲，這是相當嚴重的。我把索引的優(yōu)化定在每天的凌晨 1 點，那時候新聞更新的已經很少了，并且既 便 是索引優(yōu)化花費了 4～ 5 個小時，這樣也不能影響到第二天用戶對于最新數(shù)據(jù)的瀏 覽。 索引的 管理 索引的管理 包括文件的增加，刪除和修改，也包括索引的重建，索引的階段修復。為了對索引進行系統(tǒng)的管理 ，我設計了很多的索引管理工具。 歷史數(shù)據(jù)索引生成器 這個索引工具的功能是遍歷歷史數(shù)據(jù)文件，然后 生成索引。歷史文件的文件夾結構雖然和最近文件文件夾結構相似，但是歷史文件的文件結構卻和最近文件的結構相差很大，并且歷史文件是 html 格式，而最近文件是 xml 格式，所以為了創(chuàng)建歷史數(shù)據(jù)的索引，單獨建立了一套索引工具。 歷史數(shù)據(jù)索引生成輔助工具 這個索引工具是為了單獨 刪除 一個歷史數(shù)據(jù)文件而建 立的。顯然， 對于至少一年以前的數(shù)據(jù)，不會有什么修改和添加，但是對于歷史悠久的數(shù)據(jù)，時間久了就可以刪除了，因為完全不會有用。由于歷史數(shù)據(jù)文件結構的特殊性，只有單獨創(chuàng)建一個工具來實現(xiàn)。刪除歷史文件索引通過輸入文件的完整路徑名來實現(xiàn)。 索引管理工具 索引的管理工具是用來維護最近數(shù)據(jù)的，需要對文件索引進行批量刪除，或者 需要修改文件， 或者需要添加文件， 或者是重建當天數(shù)據(jù)，或者是重建所有 最近數(shù)據(jù)，或者重建某一天之前的數(shù)據(jù)文件。使用這個工具都可以時間。這個工具有簡單的圖形界面，可以很好的幫助我們管理索引。 索引自動更新服務 這個服務是用來自動更新當天的索引和執(zhí)行每天的優(yōu)化的。 這個服務每 5分鐘便檢查一下存放當天數(shù)據(jù)的文件夾中是否有新的數(shù)據(jù)。檢查是通 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 14 頁 共 20 頁 過查找文件的 ID 是否在索引中存在，然后檢查文件的最近修改時間是否和上次一致。如果 ID 存在，但是最近修改時間和上次不一致，則說明是經過修改的文件；如果 ID不存在，則說明是新文件。 對于新文件，就添加進入索引；對于修改過的文件，就先刪除原文件，然后在添加修改后的文件。 這個服務也會在每天的一點 啟動索引優(yōu)化，并且通過程序設置用戶服務程序所引用的索引數(shù)據(jù)源。 搜索的實現(xiàn) 概述 文中的搜索主要采用 BooleanQuery 來進行，可以選擇按照標題搜索或者按照正文搜索。另外，自己定義了一套布爾邏輯的實現(xiàn)規(guī)則。也提供了按照時間搜索的可能性。 另外，我定義了一個高級搜索頁面。 用戶可以選擇在一定的時間域搜索，可以選擇布爾邏輯搜索，可以選擇不同的 按標題或者正文搜索，也可以選擇按時間排序或者按照相關性排序。 布爾邏輯的實現(xiàn) 首先對字符串進行了過濾，字符串中只可以包括，中文，英文，數(shù)字，“ ” ,“（”，“ ） ”和空格，對于其它的字符一律替換成為空格。 然后 按照空格把字符串分成一個個的子串。對于“ ”開頭的字符串，添加到 BooleanQuery 時的添加條件為 MUST_NOT，也就是“非”；對于以“ (”開頭，以“ )”結尾的字符串，添加到 BooleanQuery 時的添加條件為 SHOULD，也就是“或”；其余字符串，添加到 BooleanQuery 時的添加條件為 MUST，也就是“與”。 另外，對于每一個子串，我還以“ ”，“ (”，“ )”和空格作為分隔符再次進行分割，對 AND， OR， NOT 進行了過濾，這樣最終便使得 Query 中只包含中文，英文和數(shù)字，而且不包含 AND， OR， NOT 等 Lucene 停用字。 時間的搜索 對于時間的搜索，我采用 Filter來實現(xiàn)，在不給予時間參數(shù)的情況下， 默認不采用 Filter，而當有時間參數(shù)的情況下，便采用 Filter對搜索結果進行過濾。 時間搜索采用了 Filter，因為如果用 RangeQuery，對于 10 年的時間跨度的搜索，會產生 3650個搜索匹配，搜索效率太低。 Filter雖然在原理上與 RangeQuery相當，但是在效率上會快一些。界面上 讓用戶最多選擇 2 個月的時間跨度就是基于效率的考慮，而且一般來說新聞的實效性很強，兩個月前的數(shù)據(jù)也沒 有太大的意義。 排序的實現(xiàn) 按照索引創(chuàng)建的時間排序 如下的代碼段則表示按照創(chuàng)建的時間排序 ： new Sort(new SortField(null, , true)) 按照相關性排序 Lucene 的默認排序就是按照相關性排序，無需多余的設置，由于新聞中時間因素尤為重要，在一開始的時候便應該設置 showtime 這個域的權重值為 2. 緩存系統(tǒng) 緩存系統(tǒng)對于刷新，同一關鍵詞的點擊都進行了設置，利用 session data儲存了一個歷史文件，其中儲存了上一次的搜索結果，時間 信息，關鍵詞信息，過濾器信息等。在遇 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 15 頁 共 20 頁 到刷新或者同一詞搜索時，便打開緩存，把緩存結果直接反饋給用戶。 翻頁的實現(xiàn) 翻頁是按照每頁 10 篇文章，每次取 10 篇文章來顯示的方式。這樣做節(jié)約了一定的數(shù)據(jù)載入時間。 翻頁系統(tǒng)是通過一個 Page字段實現(xiàn)的，首先搜索引擎獲取這個字段。由于在獲得的 Hits中， Lucene 事先把 前 3000 條記錄存入了緩存，所以對于 前 3000 條數(shù)據(jù)的訪問速度是很快的。 現(xiàn)在每頁顯示的是 10條數(shù)據(jù)，那么當需要獲取 “ 第 N頁 ” 的信息時，只需要取出 Hits中 10*(N1)到 10*N之間的數(shù)據(jù)。 對于翻頁系 統(tǒng)的實現(xiàn)，最初有兩種方案，一種是儲存每一頁的數(shù)據(jù)，在翻頁是重新讀取 Hits，另一種是直接讀取 10 頁的數(shù)據(jù)，對于 10 頁之間的翻轉，就可以做到瞬間做到。但是考慮到用戶往往對于第一頁的搜索數(shù)據(jù)更加感興趣，也不會在意第二頁，第三頁的速度，所以最終采用了第一種方案。 日志 維護 系統(tǒng) 對于 可能出錯的地方，我都會設計一個日志輸出 ，從而讓我快速的獲取信息。采用log4技術，可以輸出各種級別的錯誤日志。 歷史文件索引生成工具的日志是每生成一個文件夾的索引 生成一條記錄 歷史文件索引生成輔助工具的 日志是每操作一個文件生成一條 記錄。 文件管理工具是 每進行一次相關的操作生成一條記錄。 文件的定時更新服務是每 5分鐘生成當前服務運行情況的一條記錄。 用戶搜索服務系統(tǒng)是每天生成一個文件，對于每個錯誤級別以上的情況生成一條記錄。 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 16 頁 共 20 頁 第七章 測試 概述 到今天為止 ， 總共創(chuàng)建的索引 的文件個數(shù)為 1336521 個文件，大小總計 ，每天增加 1500 篇新文章，高峰期每 5分鐘增加 50 篇文章，索引大小約為 ， 每天的點擊量在10萬以上。 索引創(chuàng)建測試 索引的創(chuàng)建，對于歷史數(shù)據(jù)的創(chuàng)建有速度記載，創(chuàng)建 1202000篇文章總計花費了 12個小時， 也就是每小時能夠創(chuàng)建 10萬篇的數(shù)據(jù)。 索引管理測試 對于單個文件的添加，刪除和修改都可以在瞬間完成。 5 分鐘內完成 50篇的數(shù)據(jù)創(chuàng)建也綽綽有余。當天文件的 重建 一般在 1 分鐘 內就可以完成 。 重建 三個月的數(shù)據(jù)總計耗時 1小時 10分鐘左右。 搜索速度測試 搜索常用字“的”，“我”等字詞，系統(tǒng)的搜索時間在 ； 對于 非 常用字，最終文章搜索結果不多的字詞，如“東方財富”等字詞，系統(tǒng)的搜索時間在 。 搜索準確度測試 在一篇文章中任意截取一個文字片段進行搜索，都能搜索到該篇文章 ，說明很準確。對于一個字詞的搜索結 果，采用 Windows 在內容中查找的功能進行對比，發(fā)現(xiàn)總的文件數(shù)和搜索結果總數(shù)一致 ，說明沒有遺漏。 搜索系統(tǒng)的穩(wěn)定性 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 17 頁 共 20 頁 自從搜索系統(tǒng)面向用戶以來 2 天之后，系統(tǒng)就趨于穩(wěn)定，到目前為止大約兩個月的時間，總計出現(xiàn)了 4 行錯誤日志記錄 ，且都已經被維護處理 ，并且該錯誤源于網絡攻擊造成的記錄 與正常用戶無關。 上圖為用戶搜索服務器日志。 系統(tǒng)運行穩(wěn)定， 索引定時更新服務和用戶搜索 服務器未曾出現(xiàn)死掉的狀況。 上圖為索引定時更新服務程序日志。 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 18 頁 共 20 頁 第八章 結論 這個搜索引擎總的來說還是比較滿意的。從需求上來看已經完全滿足了，另 外自己還主動實現(xiàn)了高級搜索 。但是這個搜索引擎還有很多不足，第一就是功能太簡單，由于公司沒有這方面的需求，也不提供進行這方面需求實現(xiàn)的數(shù)據(jù)。比如提取文章中的股票，文章關鍵字提取等功能暫時無法實現(xiàn)，這不能不說是一種遺憾。 但是考慮到程序的效率和邏輯性都很高，所以總的來說還算是合格，畢竟搜索引擎是一個巨大的項目，通過自己一個人搭建起這樣一個平臺也算不容易。 在搜索引擎的制作中，我深入學習的分詞技術，相關性排序技術，對于全文搜索有了很好的了解。通過這些的學習，自己所做的臟字過濾工具，關鍵詞提取工具，文章自動分類工具都 有很好的效果。最重要的是，自己對搜索引擎這個領域有了很深的理解，并且對于互聯(lián)網有了更深的理解。 我雖然只是實現(xiàn)了一個新聞搜索引擎，但是看著 Google的退出，百度進軍電子書市場，在看看當今的各個新聞搜索系統(tǒng)，我也開始期待互聯(lián)網的新時代的到來。 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 19 頁 共 20 頁 參考文獻 [1] 基于 Lucene 的站內新聞搜索引擎的設計與實現(xiàn) 第 20 頁 共 20 頁 致謝 首先我要感謝公司，在剛進公司的時候，我只是想象著在里邊做一些接口，幫別人完成某個函數(shù)的實現(xiàn)?？墒窃谶M入公司不久之后，公司便把一個對外開放的整個的系統(tǒng)交給我來做，對我來說這份信任是不可想象的。 然后要感謝我的企業(yè)導師，導師雖然沒有幫助我 實際的編碼工作，卻在環(huán)境的搭配，上線的布置等工作上給了我很大的幫助，并且?guī)椭液芎玫睦斫庑枨?，也時常給我減輕壓力。 再次要感謝我的學校導師，沈老師真的是太負責了，郵件的回復速度極快，并且對于文檔的修改非常的仔細，是我遇到的最負責的導師 。 然后要感謝學校，是學校給我和公司之間搭建了這個橋梁，為我的人生發(fā)展起到了很大的推動作用。 再次要感謝我的父母，是他們在我剛搬出學校居住時給與我關心和愛護。 最后要感謝我的姐姐，妹妹和最好的朋友，在我心情不好或者不順的時候，是你們陪著我，慢慢的開導我，讓我在很沮喪的情況下重新 振作起來。