Lucene：基于Java的全文檢索引擎簡介VIP

1、Lucene：基于Java的全文檢索引擎簡介.txt28生活是一位睿智的長者，生活是一位博學(xué)的老師，它常常春風(fēng)化雨，潤物無聲地為我們指點(diǎn)迷津，給我們?nèi)松膯⒌?。不要吝惜自己的愛，敞開自己的胸懷，多多給予，你會發(fā)現(xiàn)，你也已經(jīng)沐浴在了愛河里。版權(quán)聲明：可以任意轉(zhuǎn)載，轉(zhuǎn)載時(shí)請務(wù)必以超鏈接形式標(biāo)明文章原始出處和作者信息及本聲明。-Lucene是一個(gè)基于Java的全文索引工具包。基于Java的全文索引引擎Lucene簡介：關(guān)于作者和Lucene的歷史 全文檢索的實(shí)現(xiàn)：Luene全文索引和數(shù)據(jù)庫索引的比較 中文切分詞機(jī)制簡介：基于詞庫和自動切分詞算法的比較 具體的安裝和使用簡介：系統(tǒng)結(jié)構(gòu)介紹和演示 Hac

2、king Lucene：簡化的查詢分析器，刪除的實(shí)現(xiàn)，定制的排序，應(yīng)用接口的擴(kuò)展 從Lucene我們還可以學(xué)到什么 基于Java的全文索引/檢索引擎LuceneLucene不是一個(gè)完整的全文索引應(yīng)用，而是是一個(gè)用Java寫的全文索引引擎工具包，它可以方便的嵌入到各種應(yīng)用中實(shí)現(xiàn)針對應(yīng)用的全文索引/檢索功能。Lucene的作者：Lucene的貢獻(xiàn)者Doug Cutting是一位資深全文索引/檢索專家，曾經(jīng)是V-Twin搜索引擎(Apple的Copland操作系統(tǒng)的成就之一)的主要開發(fā)者，后在Excite擔(dān)任高級系統(tǒng)架構(gòu)設(shè)計(jì)師，目前從事于一些INTERNET底層架構(gòu)的研究。他貢獻(xiàn)出的Lucene的目

3、標(biāo)是為各種中小型應(yīng)用程序加入全文檢索功能。Lucene的發(fā)展歷程：早先發(fā)布在作者自己的，后來發(fā)布在SourceForge，2001年年底成為APACHE基金會jakarta的一個(gè)子項(xiàng)目：已經(jīng)有很多Java項(xiàng)目都使用了Lucene作為其后臺的全文索引引擎，比較著名的有：Jive：WEB論壇系統(tǒng)； Eyebrows：郵件列表HTML歸檔/瀏覽/查詢系統(tǒng)，本文的主要參考文檔“TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows系統(tǒng)的主要開發(fā)者之一，而EyeBrows已經(jīng)成為目前APACHE項(xiàng)目的主要郵件列表歸檔系統(tǒng)。 C

4、ocoon:基于XML的web發(fā)布框架，全文檢索部分使用了Lucene Eclipse:基于Java的開放開發(fā)平臺，幫助部分的全文索引使用了Lucene對于中文用戶來說，最關(guān)心的問題是其是否支持中文的全文檢索。但通過后面對于Lucene的結(jié)構(gòu)的介紹，你會了解到由于Lucene良好架構(gòu)設(shè)計(jì)，對中文的支持只需對其語言詞法分析接口進(jìn)行擴(kuò)展就能實(shí)現(xiàn)對中文檢索的支持。全文檢索的實(shí)現(xiàn)機(jī)制Lucene的API接口設(shè)計(jì)的比較通用，輸入輸出結(jié)構(gòu)都很像數(shù)據(jù)庫的表=記錄=字段，所以很多傳統(tǒng)的應(yīng)用的文件、數(shù)據(jù)庫等都可以比較方便的映射到Lucene的存儲結(jié)構(gòu)/接口中。總體上看：可以先把Lucene當(dāng)成一個(gè)支持全文索引的

5、數(shù)據(jù)庫系統(tǒng)。比較一下Lucene和數(shù)據(jù)庫：Lucene 數(shù)據(jù)庫 索引數(shù)據(jù)源：doc(field1,field2.) doc(field1,field2.) indexer / _ | Lucene Index| - / searcher 結(jié)果輸出：Hits(doc(field1,field2) doc(field1.) 索引數(shù)據(jù)源：record(field1,field2.) record(field1.) SQL: insert/ _ | DB Index | - / SQL: select 結(jié)果輸出：results(record(field1,field2.) record(field1.

6、) Document：一個(gè)需要進(jìn)行索引的“單元”一個(gè)Document由多個(gè)字段組成 Record：記錄，包含多個(gè)字段 Field：字段 Field：字段 Hits：查詢結(jié)果集，由匹配的Document組成 RecordSet：查詢結(jié)果集，由多個(gè)Record組成 全文檢索 like %keyword%通常比較厚的書籍后面常常附關(guān)鍵詞索引表（比如：北京：12, 34頁，上海：3,77頁），它能夠幫助讀者比較快地找到相關(guān)內(nèi)容的頁碼。而數(shù)據(jù)庫索引能夠大大提高查詢的速度原理也是一樣，想像一下通過書后面的索引查找的速度要比一頁一頁地翻內(nèi)容高多少倍而索引之所以效率高，另外一個(gè)原因是它是排好序的。對于檢索系統(tǒng)

7、來說核心是一個(gè)排序問題。由于數(shù)據(jù)庫索引不是為全文索引設(shè)計(jì)的，因此，使用like %keyword%時(shí)，數(shù)據(jù)庫索引是不起作用的，在使用like查詢時(shí)，搜索過程又變成類似于一頁頁翻書的遍歷過程了，所以對于含有模糊查詢的數(shù)據(jù)庫服務(wù)來說，LIKE對性能的危害是極大的。如果是需要對多個(gè)關(guān)鍵詞進(jìn)行模糊匹配：like%keyword1% and like %keyword2% .其效率也就可想而知了。所以建立一個(gè)高效檢索系統(tǒng)的關(guān)鍵是建立一個(gè)類似于科技索引一樣的反向索引機(jī)制，將數(shù)據(jù)源（比如多篇文章）排序順序存儲的同時(shí)，有另外一個(gè)排好序的關(guān)鍵詞列表，用于存儲關(guān)鍵詞=文章映射關(guān)系，利用這樣的映射關(guān)系索引：關(guān)鍵詞=

8、出現(xiàn)關(guān)鍵詞的文章編號，出現(xiàn)次數(shù)（甚至包括位置：起始偏移量，結(jié)束偏移量），出現(xiàn)頻率，檢索過程就是把模糊查詢變成多個(gè)可以利用索引的精確查詢的邏輯組合的過程。從而大大提高了多關(guān)鍵詞查詢的效率，所以，全文檢索問題歸結(jié)到最后是一個(gè)排序問題。由此可以看出模糊查詢相對數(shù)據(jù)庫的精確查詢是一個(gè)非常不確定的問題，這也是大部分?jǐn)?shù)據(jù)庫對全文檢索支持有限的原因。Lucene最核心的特征是通過特殊的索引結(jié)構(gòu)實(shí)現(xiàn)了傳統(tǒng)數(shù)據(jù)庫不擅長的全文索引機(jī)制，并提供了擴(kuò)展接口，以方便針對不同應(yīng)用的定制?？梢酝ㄟ^一下表格對比一下數(shù)據(jù)庫的模糊查詢： Lucene全文索引引擎 數(shù)據(jù)庫 索引 將數(shù)據(jù)源中的數(shù)據(jù)都通過全文索引一一建立反向索引 對于

9、LIKE查詢來說，數(shù)據(jù)傳統(tǒng)的索引是根本用不上的。數(shù)據(jù)需要逐個(gè)便利記錄進(jìn)行GREP式的模糊匹配，比有索引的搜索速度要有多個(gè)數(shù)量級的下降。 匹配效果 通過詞元(term)進(jìn)行匹配，通過語言分析接口的實(shí)現(xiàn)，可以實(shí)現(xiàn)對中文等非英語的支持。 使用：like %net% 會把netherlands也匹配出來，多個(gè)關(guān)鍵詞的模糊匹配：使用like %com%net%：就不能匹配詞序顛倒的 匹配度 有匹配度算法，將匹配程度（相似度）比較高的結(jié)果排在前面。 沒有匹配程度的控制：比如有記錄中net出現(xiàn)5詞和出現(xiàn)1次的，結(jié)果是一樣的。 結(jié)果輸出 通過特別的算法，將最匹配度最高的頭100條結(jié)果輸出，結(jié)果集是緩沖式的小批

10、量讀取的。 返回所有的結(jié)果集，在匹配條目非常多的時(shí)候（比如上萬條）需要大量的內(nèi)存存放這些臨時(shí)結(jié)果集。 可定制性 通過不同的語言分析接口實(shí)現(xiàn)，可以方便的定制出符合應(yīng)用需要的索引規(guī)則（包括對中文的支持） 沒有接口或接口復(fù)雜，無法定制 結(jié)論 高負(fù)載的模糊查詢應(yīng)用，需要負(fù)責(zé)的模糊查詢的規(guī)則，索引的資料量比較大 使用率低，模糊匹配規(guī)則簡單或者需要模糊查詢的資料量少 全文檢索和數(shù)據(jù)庫應(yīng)用最大的不同在于：讓最相關(guān)的頭100條結(jié)果滿足98%以上用戶的需求Lucene的創(chuàng)新之處：大部分的搜索（數(shù)據(jù)庫）引擎都是用B樹結(jié)構(gòu)來維護(hù)索引，索引的更新會導(dǎo)致大量的IO操作，Lucene在實(shí)現(xiàn)中，對此稍微有所改進(jìn)：不是維護(hù)一

11、個(gè)索引文件，而是在擴(kuò)展索引的時(shí)候不斷創(chuàng)建新的索引文件，然后定期的把這些新的小索引文件合并到原先的大索引中（針對不同的更新策略，批次的大小可以調(diào)整），這樣在不影響檢索的效率的前提下，提高了索引的效率。Lucene和其他一些全文檢索系統(tǒng)/應(yīng)用的比較： Lucene 其他開源全文檢索系統(tǒng) 增量索引和批量索引 可以進(jìn)行增量的索引(Append)，可以對于大量數(shù)據(jù)進(jìn)行批量索引，并且接口設(shè)計(jì)用于優(yōu)化批量索引和小批量的增量索引。 很多系統(tǒng)只支持批量的索引，有時(shí)數(shù)據(jù)源有一點(diǎn)增加也需要重建索引。 數(shù)據(jù)源 Lucene沒有定義具體的數(shù)據(jù)源，而是一個(gè)文檔的結(jié)構(gòu)，因此可以非常靈活的適應(yīng)各種應(yīng)用（只要前端有合適的轉(zhuǎn)換器

12、把數(shù)據(jù)源轉(zhuǎn)換成相應(yīng)結(jié)構(gòu)）， 很多系統(tǒng)只針對網(wǎng)頁，缺乏其他格式文檔的靈活性。 索引內(nèi)容抓取 Lucene的文檔是由多個(gè)字段組成的，甚至可以控制那些字段需要進(jìn)行索引，那些字段不需要索引，近一步索引的字段也分為需要分詞和不需要分詞的類型： 需要進(jìn)行分詞的索引，比如：標(biāo)題，文章內(nèi)容字段 不需要進(jìn)行分詞的索引，比如：作者/日期字段 缺乏通用性，往往將文檔整個(gè)索引了 語言分析 通過語言分析器的不同擴(kuò)展實(shí)現(xiàn)：可以過濾掉不需要的詞：an the of 等，西文語法分析：將jumps jumped jumper都?xì)w結(jié)成jump進(jìn)行索引/檢索非英文支持：對亞洲語言，阿拉伯語言的索引支持 缺乏通用接口實(shí)現(xiàn) 查詢分析

13、 通過查詢分析接口的實(shí)現(xiàn)，可以定制自己的查詢語法規(guī)則：比如： 多個(gè)關(guān)鍵詞之間的 + - and or關(guān)系等 并發(fā)訪問 能夠支持多用戶的使用 關(guān)于亞洲語言的的切分詞問題(Word Segment)對于中文來說，全文索引首先還要解決一個(gè)語言分析的問題，對于英文來說，語句中單詞之間是天然通過空格分開的，但亞洲語言的中日韓文語句中的字是一個(gè)字挨一個(gè)，所有，首先要把語句中按“詞”進(jìn)行索引的話，這個(gè)詞如何切分出來就是一個(gè)很大的問題。首先，肯定不能用單個(gè)字符作(si-gram)為索引單元，否則查“上?！睍r(shí)，不能讓含有“海上”也匹配。但一句話：“北京天安門”，計(jì)算機(jī)如何按照中文的語言習(xí)慣進(jìn)行切分呢？“北京 天

14、安門” 還是“北 京 天安門”？讓計(jì)算機(jī)能夠按照語言習(xí)慣進(jìn)行切分，往往需要機(jī)器有一個(gè)比較豐富的詞庫才能夠比較準(zhǔn)確的識別出語句中的單詞。另外一個(gè)解決的辦法是采用自動切分算法：將單詞按照2元語法(bigram)方式切分出來，比如：北京天安門 = 北京 京天 天安 安門。這樣，在查詢的時(shí)候，無論是查詢北京 還是查詢天安門，將查詢詞組按同樣的規(guī)則進(jìn)行切分：北京，天安安門，多個(gè)關(guān)鍵詞之間按與and的關(guān)系組合，同樣能夠正確地映射到相應(yīng)的索引中。這種方式對于其他亞洲語言：韓文，日文都是通用的?；谧詣忧蟹值淖畲髢?yōu)點(diǎn)是沒有詞表維護(hù)成本，實(shí)現(xiàn)簡單，缺點(diǎn)是索引效率低，但對于中小型應(yīng)用來說，基于2元語法的切分還是夠

15、用的?；?元切分后的索引一般大小和源文件差不多，而對于英文，索引文件一般只有原文件的30%-40%不同， 自動切分 詞表切分 實(shí)現(xiàn) 實(shí)現(xiàn)非常簡單 實(shí)現(xiàn)復(fù)雜 查詢 增加了查詢分析的復(fù)雜程度， 適于實(shí)現(xiàn)比較復(fù)雜的查詢語法規(guī)則 存儲效率 索引冗余大，索引幾乎和原文一樣大 索引效率高，為原文大小的30左右 維護(hù)成本 無詞表維護(hù)成本 詞表維護(hù)成本非常高：中日韓等語言需要分別維護(hù)。還需要包括詞頻統(tǒng)計(jì)等內(nèi)容 適用領(lǐng)域 嵌入式系統(tǒng)：運(yùn)行環(huán)境資源有限分布式系統(tǒng)：無詞表同步問題多語言環(huán)境：無詞表維護(hù)成本 對查詢和存儲效率要求高的專業(yè)搜索引擎 目前比較大的搜索引擎的語言分析算法一般是基于以上2個(gè)機(jī)制的結(jié)合。關(guān)于中

16、文的語言分析算法，大家可以在Google查關(guān)鍵詞wordsegment search能找到更多相關(guān)的資料。安裝和使用下載：注意：Lucene中的一些比較復(fù)雜的詞法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，純Java的詞法分析生成器），所以如果從源代碼編譯或需要修改其中的QueryParser、定制自己的詞法分析器，還需要從。lucene的組成結(jié)構(gòu)：對于外部應(yīng)用來說索引模塊(index)和檢索模塊(search)是主要的外部應(yīng)用入口org.apache.Lucene.search/ 搜索入口 org.apache.Lucene.index/ 索引入口 o

17、rg.apache.Lucene.analysis/ 語言分析器 org.apache.Lucene.queryParser/ 查詢分析器 org.apache.Lucene.document/ 存儲結(jié)構(gòu) org.apache.Lucene.store/ 底層IO/存儲結(jié)構(gòu) org.apache.Lucene.util/ 一些公用的數(shù)據(jù)結(jié)構(gòu) 簡單的例子演示一下Lucene的使用方法：索引過程：從命令行讀取文件名（多個(gè)），將文件分路徑(path字段)和內(nèi)容(body字段)2個(gè)字段進(jìn)行存儲，并對內(nèi)容進(jìn)行全文索引：索引的單位是Document對象，每個(gè)Document對象包含多個(gè)字段Field對象，

18、針對不同的字段屬性和數(shù)據(jù)輸出的需求，對字段還可以選擇不同的索引/存儲字段規(guī)則，列表如下： 方法 切詞 索引 存儲 用途 Field.Text(String name, String value) Yes Yes Yes 切分詞索引并存儲，比如：標(biāo)題，內(nèi)容字段 Field.Text(String name, Reader value) Yes Yes No 切分詞索引不存儲，比如：META信息，不用于返回顯示，但需要進(jìn)行檢索內(nèi)容 Field.Keyword(String name, String value) No Yes Yes 不切分索引并存儲，比如：日期字段 Field.UnIndexed

19、(String name, String value) No No Yes 不索引，只存儲，比如：文件路徑 Field.UnStored(String name, String value) Yes Yes No 只全文索引，不存儲 public class IndexFiles /使用方法：: IndexFiles 索引輸出目錄 索引的文件列表 . public static void main(String args) throws Exception String indexPath = args0; IndexWriter writer; /用指定的語言分析器構(gòu)造一個(gè)新的寫索引器（第3

20、個(gè)參數(shù)表示是否為追加索引） writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false); for (int i=1; iField中的內(nèi)容。假設(shè)根據(jù)body字段進(jìn)行全文檢索，可以將查詢結(jié)果的path字段和相應(yīng)查詢的匹配度(score)打印出來，public class Search public static void main(String args) throws Exception String indexPath = args0, queryString = args1; /指向索引目錄的搜索器 Searcher s

21、earcher = new IndexSearcher(indexPath); /查詢解析器：使用和索引同樣的語言分析器 Query query = QueryParser.parse(queryString, body, new SimpleAnalyzer(); /搜索結(jié)果使用Hits存儲 Hits hits = searcher.search(query); /通過hits可以訪問到相應(yīng)字段的數(shù)據(jù)和查詢的匹配度 for (int i=0; ihits.length(); i+) System.out.println(hits.doc(i).get(path) + ; Score: + h

22、its.score(i); ; 在整個(gè)檢索過程中，語言分析器，查詢分析器，甚至搜索器（Searcher）都是提供了抽象的接口，可以根據(jù)需要進(jìn)行定制。 Hacking Lucene簡化的查詢分析器個(gè)人感覺lucene成為JAKARTA項(xiàng)目后，畫在了太多的時(shí)間用于調(diào)試日趨復(fù)雜QueryParser，而其中大部分是大多數(shù)用戶并不很熟悉的，目前LUCENE支持的語法：Query := ( Clause )*Clause := +, - : ( | ( Query )中間的邏輯包括：and or + - &|等符號，而且還有短語查詢和針對西文的前綴/模糊查詢等，個(gè)人感覺對于一般應(yīng)用來說，這些功能有一些華

23、而不實(shí)，其實(shí)能夠?qū)崿F(xiàn)目前類似于Google的查詢語句分析功能其實(shí)對于大多數(shù)用戶來說已經(jīng)夠了。所以，Lucene早期版本的QueryParser仍是比較好的選擇。添加修改刪除指定記錄（Document）Lucene提供了索引的擴(kuò)展機(jī)制，因此索引的動態(tài)擴(kuò)展應(yīng)該是沒有問題的，而指定記錄的修改也似乎只能通過記錄的刪除，然后重新加入實(shí)現(xiàn)。如何刪除指定的記錄呢？刪除的方法也很簡單，只是需要在索引時(shí)根據(jù)數(shù)據(jù)源中的記錄ID專門另建索引，然后利用IndexReader.delete(Termterm)方法通過這個(gè)記錄ID刪除相應(yīng)的Document。根據(jù)某個(gè)字段值的排序功能lucene缺省是按照自己的相關(guān)度算法（

24、score）進(jìn)行結(jié)果排序的，但能夠根據(jù)其他字段進(jìn)行結(jié)果排序是一個(gè)在LUCENE的開發(fā)郵件列表中經(jīng)常提到的問題，很多原先基于數(shù)據(jù)庫應(yīng)用都需要除了基于匹配度（score）以外的排序功能。而從全文檢索的原理我們可以了解到，任何不基于索引的搜索過程效率都會導(dǎo)致效率非常的低，如果基于其他字段的排序需要在搜索過程中訪問存儲字段，速度回大大降低，因此非常是不可取的。但這里也有一個(gè)折中的解決方法：在搜索過程中能夠影響排序結(jié)果的只有索引中已經(jīng)存儲的docID和score這2個(gè)參數(shù)，所以，基于score以外的排序，其實(shí)可以通過將數(shù)據(jù)源預(yù)先排好序，然后根據(jù)docID進(jìn)行排序來實(shí)現(xiàn)。這樣就避免了在LUCENE搜索結(jié)果

25、外對結(jié)果再次進(jìn)行排序和在搜索過程中訪問不在索引中的某個(gè)字段值。這里需要修改的是IndexSearcher中的HitCollector過程：.scorer.score(new HitCollector() private float minScore = 0.0f;public final void collect(int doc, float score) if (score 0.0f & / ignore zeroed buckets (bits=null | bits.get(doc) / skip docs not in bits totalHits0+; if (score = min

26、Score) /* 原先：Lucene將docID和相應(yīng)的匹配度score例入結(jié)果命中列表中： * hq.put(new ScoreDoc(doc, score); / update hit queue * 如果用doc 或 1/doc 代替 score，就實(shí)現(xiàn)了根據(jù)docID順排或逆排 * 假設(shè)數(shù)據(jù)源索引時(shí)已經(jīng)按照某個(gè)字段排好了序，而結(jié)果根據(jù)docID排序也就實(shí)現(xiàn)了 * 針對某個(gè)字段的排序，甚至可以實(shí)現(xiàn)更復(fù)雜的score和docID的擬合。 */ hq.put(new ScoreDoc(doc, (float) 1/doc ); if (hq.size() nDocs) / if hit q

27、ueue overfullhq.pop(); / remove lowest in hit queueminScore = (ScoreDoc)hq.top().score; / reset minScore , reader.maxDoc();更通用的輸入輸出接口雖然lucene沒有定義一個(gè)確定的輸入文檔格式，但越來越多的人想到使用一個(gè)標(biāo)準(zhǔn)的中間格式作為Lucene的數(shù)據(jù)導(dǎo)入接口，然后其他數(shù)據(jù)，比如PDF只需要通過解析器轉(zhuǎn)換成標(biāo)準(zhǔn)的中間格式就可以進(jìn)行數(shù)據(jù)索引了。這個(gè)中間格式主要以XML為主，類似實(shí)現(xiàn)已經(jīng)不下4，5個(gè)：數(shù)據(jù)源: WORD PDF HTML DB other | | | / XM

28、L中間格式 | Lucene INDEX目前還沒有針對MSWord文檔的解析器，因?yàn)閃ord文檔和基于ASCII的RTF文檔不同，需要使用COM對象機(jī)制解析。這個(gè)是我在Google上查的相關(guān)資料：另外一個(gè)辦法就是把Word文檔轉(zhuǎn)換成text：索引過程優(yōu)化索引一般分2種情況，一種是小批量的索引擴(kuò)展，一種是大批量的索引重建。在索引過程中，并不是每次新的DOC加入進(jìn)去索引都重新進(jìn)行一次索引文件的寫入操作（文件I/O是一件非常消耗資源的事情）。Lucene先在內(nèi)存中進(jìn)行索引操作，并根據(jù)一定的批量進(jìn)行文件的寫入。這個(gè)批次的間隔越大，文件的寫入次數(shù)越少，但占用內(nèi)存會很多。反之占用內(nèi)存少，但文件IO操作頻繁

29、，索引速度會很慢。在IndexWriter中有一個(gè)MERGE_FACTOR參數(shù)可以幫助你在構(gòu)造索引器后根據(jù)應(yīng)用環(huán)境的情況充分利用內(nèi)存減少文件的操作。根據(jù)我的使用經(jīng)驗(yàn)：缺省Indexer是每20條記錄索引后寫入一次，每將MERGE_FACTOR增加50倍，索引速度可以提高1倍左右。搜索過程優(yōu)化lucene支持內(nèi)存索引：這樣的搜索比基于文件的I/O有數(shù)量級的速度提升。而盡可能減少IndexSearcher的創(chuàng)建和對搜索結(jié)果的前臺的緩存也是必要的。Lucene面向全文檢索的優(yōu)化在于首次索引檢索后，并不把所有的記錄（Document）具體內(nèi)容讀取出來，而起只將所有結(jié)果中匹配度最高的頭100條結(jié)果（To

30、pDocs）的ID放到結(jié)果集緩存中并返回，這里可以比較一下數(shù)據(jù)庫檢索：如果是一個(gè)10,000條的數(shù)據(jù)庫檢索結(jié)果集，數(shù)據(jù)庫是一定要把所有記錄內(nèi)容都取得以后再開始返回給應(yīng)用結(jié)果集的。所以即使檢索匹配總數(shù)很多，Lucene的結(jié)果集占用的內(nèi)存空間也不會很多。對于一般的模糊檢索應(yīng)用是用不到這么多的結(jié)果的，頭100條已經(jīng)可以滿足90%以上的檢索需求。如果首批緩存結(jié)果數(shù)用完后還要讀取更后面的結(jié)果時(shí)Searcher會再次檢索并生成一個(gè)上次的搜索緩存數(shù)大1倍的緩存，并再重新向后抓取。所以如果構(gòu)造一個(gè)Searcher去查1120條結(jié)果，Searcher其實(shí)是進(jìn)行了2次搜索過程：頭100條取完后，緩存結(jié)果用完，Se

31、archer重新檢索再構(gòu)造一個(gè)200條的結(jié)果緩存，依此類推，400條緩存，800條緩存。由于每次Searcher對象消失后，這些緩存也訪問那不到了，你有可能想將結(jié)果記錄緩存下來，緩存數(shù)盡量保證在100以下以充分利用首次的結(jié)果緩存，不讓Lucene浪費(fèi)多次檢索，而且可以分級進(jìn)行結(jié)果緩存。Lucene的另外一個(gè)特點(diǎn)是在收集結(jié)果的過程中將匹配度低的結(jié)果自動過濾掉了。這也是和數(shù)據(jù)庫應(yīng)用需要將搜索的結(jié)果全部返回不同之處。我的一些嘗試：支持中文的Tokenizer：這里有2個(gè)版本，一個(gè)是通過JavaCC生成的，對CJK部分按一個(gè)字符一個(gè)TOKEN索引，另外一個(gè)是從SimpleTokenizer改寫的，對英文支持?jǐn)?shù)字和字母TOKEN，對中文按迭代索引。 基于XML數(shù)據(jù)源的索引器：XMLIndexer，因此所有數(shù)據(jù)源只要能夠按照DTD轉(zhuǎn)換成指定的XML，就可以用XMLIndxer進(jìn)行索引了。 根據(jù)某個(gè)字段排序：按記錄索引順序排序結(jié)果的搜索器：IndexOrderSearcher，因此如果需要讓搜索結(jié)果根據(jù)某個(gè)字段排序，可以讓數(shù)據(jù)源先按某個(gè)字段排好序（比如：PriceField），這樣索引后，然后在利用這個(gè)按記錄的ID順序檢索的搜索器，結(jié)果就是相當(dāng)于是那個(gè)字段排序的結(jié)果了。 從Lucene學(xué)到更多Luene的確是一個(gè)面對對象設(shè)計(jì)的典范所有的問題都通過一個(gè)額外抽象層來方便以后的擴(kuò)展和重用：