Lucene 基于java的全文搜索引擎簡介

1、Lucene：基于Java的全文檢索引擎簡介文章來源Lucene是一個基于Java的全文索引工具包。1. 基于Java的全文索引引擎Lucene簡介：關(guān)于作者和Lucene的歷史2. 全文檢索的實(shí)現(xiàn)：Luene全文索引和數(shù)據(jù)庫索引的比較3. 中文切分詞機(jī)制簡介：基于詞庫和自動切分詞算法的比較4. 具體的安裝和使用簡介：系統(tǒng)結(jié)構(gòu)介紹和演示5. Hacking Lucene：簡化的查詢分析器，刪除的實(shí)現(xiàn)，定制的排序，應(yīng)用接口的擴(kuò)展6. 從Lucene我們還可以學(xué)到什么另外，如果是在選擇全文引擎，現(xiàn)在也許是試試Sphinx的時候了：相比Lucene速度更快，有中文分詞的支持，而且內(nèi)置了對簡單的分布式

2、檢索的支持；基于Java的全文索引/檢索引擎LuceneLucene不是一個完整的全文索引應(yīng)用，而是是一個用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è)計師，目前從事于一些INTERNET底層架構(gòu)的研究。他貢獻(xiàn)出的Lucene的目標(biāo)是為各種中小型應(yīng)用程序加入全文檢索功能。Lucene的發(fā)展歷程：早先發(fā)布在作者自己的，后來發(fā)布在Sou

3、rceForge，2001年年底成為APACHE基金會jakarta的一個子項(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)。· Cocoon:基于XML的web發(fā)布框架，全文檢索部分使用了Luce

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

5、庫：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.)Document：一個需要進(jìn)行索引的“單

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

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

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

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

10、結(jié)果輸出通過特別的算法，將最匹配度最高的頭100條結(jié)果輸出，結(jié)果集是緩沖式的小批量讀取的。返回所有的結(jié)果集，在匹配條目非常多的時候（比如上萬條）需要大量的內(nèi)存存放這些臨時結(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)致大

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

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

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

14、”也匹配。但一句話：“北京天壇”，計算機(jī)如何按照中文的語言習(xí)慣進(jìn)行切分呢？“北京 天壇” 還是“北 京 天壇”？讓計算機(jī)能夠按照語言習(xí)慣進(jìn)行切分，往往需要機(jī)器有一個比較豐富的詞庫才能夠比較準(zhǔn)確的識別出語句中的單詞。另外一個解決的辦法是采用自動切分算法：將單詞按照2元語法(bigram)方式切分出來，比如："北京天壇" => "北京 京天 天壇"。這樣，在查詢的時候，無論是查詢"北京" 還是查詢"天壇"，將查詢詞組按同樣的規(guī)則進(jìn)行切分："北京"，"天安安門"，多個關(guān)鍵詞之

15、間按與"and"的關(guān)系組合，同樣能夠正確地映射到相應(yīng)的索引中。這種方式對于其他亞洲語言：韓文，日文都是通用的?；谧詣忧蟹值淖畲髢?yōu)點(diǎn)是沒有詞表維護(hù)成本，實(shí)現(xiàn)簡單，缺點(diǎn)是索引效率低，但對于中小型應(yīng)用來說，基于2元語法的切分還是夠用的?；?元切分后的索引一般大小和源文件差不多，而對于英文，索引文件一般只有原文件的30%-40%不同，自動切分詞表切分實(shí)現(xiàn)實(shí)現(xiàn)非常簡單實(shí)現(xiàn)復(fù)雜查詢增加了查詢分析的復(fù)雜程度，適于實(shí)現(xiàn)比較復(fù)雜的查詢語法規(guī)則存儲效率索引冗余大，索引幾乎和原文一樣大索引效率高，為原文大小的30左右維護(hù)成本無詞表維護(hù)成本詞表維護(hù)成本非常高：中日韓等語言需要分別維護(hù)。還需要包

16、括詞頻統(tǒng)計等內(nèi)容適用領(lǐng)域嵌入式系統(tǒng)：運(yùn)行環(huán)境資源有限分布式系統(tǒng)：無詞表同步問題多語言環(huán)境：無詞表維護(hù)成本對查詢和存儲效率要求高的專業(yè)搜索引擎目前比較大的搜索引擎的語言分析算法一般是基于以上2個機(jī)制的結(jié)合。關(guān)于中文的語言分析算法，大家可以在Google查關(guān)鍵詞"wordsegment search"能找到更多相關(guān)的資料。安裝和使用下載：注意：Lucene中的一些比較復(fù)雜的詞法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，純Java的詞法分析生成器），所以如果從源代碼編譯或需要修改其中的QueryParser、定制自己的詞法分析器，還需要從

17、下載javacc。lucene的組成結(jié)構(gòu)：對于外部應(yīng)用來說索引模塊(index)和檢索模塊(search)是主要的外部應(yīng)用入口org.apache.Lucene.search/搜索入口org.apache.Lucene.index/索引入口org.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)簡單的例子演示一下Lu

18、cene的使用方法：索引過程：從命令行讀取文件名（多個），將文件分路徑(path字段)和內(nèi)容(body字段)2個字段進(jìn)行存儲，并對內(nèi)容進(jìn)行全文索引：索引的單位是Document對象，每個Document對象包含多個字段Field對象，針對不同的字段屬性和數(shù)據(jù)輸出的需求，對字段還可以選擇不同的索引/存儲字段規(guī)則，列表如下： 方法切詞索引存儲用途Field.Text(String name, String value)YesYesYes切分詞索引并存儲，比如：標(biāo)題，內(nèi)容字段Field.Text(String name, Reader value)YesYesNo切分詞索引不存儲，比如：META信息

19、，不用于返回顯示，但需要進(jìn)行檢索內(nèi)容Field.Keyword(String name, String value)NoYesYes不切分索引并存儲，比如：日期字段Field.UnIndexed(String name, String value)NoNoYes不索引，只存儲，比如：文件路徑Field.UnStored(String name, String value)YesYesNo只全文索引，不存儲public class IndexFiles /使用方法：: IndexFiles 索引輸出目錄 索引的文件列表 . public static void main(String args)

20、 throws Exception String indexPath = args0; IndexWriter writer; /用指定的語言分析器構(gòu)造一個新的寫索引器（第3個參數(shù)表示是否為追加索引） writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false); for (int i=1; i<args.length; i+) System.out.println("Indexing file " + argsi); InputStream is = new FileInputStream(args

21、i); /構(gòu)造包含2個字段Field的Document對象 /一個是路徑path字段，不索引，只存儲 /一個是內(nèi)容body字段，進(jìn)行全文索引，并存儲 Document doc = new Document(); doc.add(Field.UnIndexed("path", argsi); doc.add(Field.Text("body", (Reader) new InputStreamReader(is); /將文檔寫入索引 writer.addDocument(doc); is.close(); ; /關(guān)閉寫索引器 writer.close();

22、 索引過程中可以看到：· 語言分析器提供了抽象的接口，因此語言分析(Analyser)是可以定制的，雖然lucene缺省提供了2個比較通用的分析器SimpleAnalyser和StandardAnalyser，這2個分析器缺省都不支持中文，所以要加入對中文語言的切分規(guī)則，需要修改這2個分析器。· Lucene并沒有規(guī)定數(shù)據(jù)源的格式，而只提供了一個通用的結(jié)構(gòu)（Document對象）來接受索引的輸入，因此輸入的數(shù)據(jù)源可以是：數(shù)據(jù)庫，WORD文檔，PDF文檔，HTML文檔只要能夠設(shè)計相應(yīng)的解析轉(zhuǎn)換器將數(shù)據(jù)源構(gòu)造成成Docuement對象即可進(jìn)行索引。· 對于大批量的數(shù)據(jù)

23、索引，還可以通過調(diào)整IndexerWrite的文件合并頻率屬性（mergeFactor）來提高批量索引的效率。檢索過程和結(jié)果顯示：搜索結(jié)果返回的是Hits對象，可以通過它再訪問Document=>Field中的內(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; /指向索引目錄的搜索器 Sear

24、cher searcher = 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; i<hits.length(); i+) System.out.println(hits.doc(i).ge

25、t("path") + " Score: " + hits.score(i); ; 在整個檢索過程中，語言分析器，查詢分析器，甚至搜索器（Searcher）都是提供了抽象的接口，可以根據(jù)需要進(jìn)行定制。 Hacking Lucene簡化的查詢分析器個人感覺lucene成為JAKARTA項(xiàng)目后，畫在了太多的時間用于調(diào)試日趨復(fù)雜QueryParser，而其中大部分是大多數(shù)用戶并不很熟悉的，目前LUCENE支持的語法：Query := ( Clause )*Clause := "+", "-" <TERM> &

26、quot;:" ( <TERM> | "(" Query ")")中間的邏輯包括：and or + - &&|等符號，而且還有"短語查詢"和針對西文的前綴/模糊查詢等，個人感覺對于一般應(yīng)用來說，這些功能有一些華而不實(shí)，其實(shí)能夠?qū)崿F(xiàn)目前類似于Google的查詢語句分析功能其實(shí)對于大多數(shù)用戶來說已經(jīng)夠了。所以，Lucene早期版本的QueryParser仍是比較好的選擇。添加修改刪除指定記錄（Document）Lucene提供了索引的擴(kuò)展機(jī)制，因此索引的動態(tài)擴(kuò)展應(yīng)該是沒有問題的，而指定記錄的修改也似乎

27、只能通過記錄的刪除，然后重新加入實(shí)現(xiàn)。如何刪除指定的記錄呢？刪除的方法也很簡單，只是需要在索引時根據(jù)數(shù)據(jù)源中的記錄ID專門另建索引，然后利用IndexReader.delete(Termterm)方法通過這個記錄ID刪除相應(yīng)的Document。根據(jù)某個字段值的排序功能lucene缺省是按照自己的相關(guān)度算法（score）進(jìn)行結(jié)果排序的，但能夠根據(jù)其他字段進(jìn)行結(jié)果排序是一個在LUCENE的開發(fā)郵件列表中經(jīng)常提到的問題，很多原先基于數(shù)據(jù)庫應(yīng)用都需要除了基于匹配度（score）以外的排序功能。而從全文檢索的原理我們可以了解到，任何不基于索引的搜索過程效率都會導(dǎo)致效率非常的低，如果基于其他字段的排序需要

28、在搜索過程中訪問存儲字段，速度回大大降低，因此非常是不可取的。但這里也有一個折中的解決方法：在搜索過程中能夠影響排序結(jié)果的只有索引中已經(jīng)存儲的docID和score這2個參數(shù)，所以，基于score以外的排序，其實(shí)可以通過將數(shù)據(jù)源預(yù)先排好序，然后根據(jù)docID進(jìn)行排序來實(shí)現(xiàn)。這樣就避免了在LUCENE搜索結(jié)果外對結(jié)果再次進(jìn)行排序和在搜索過程中訪問不在索引中的某個字段值。這里需要修改的是IndexSearcher中的HitCollector過程：scorer.score(new HitCollector() private float minScore = 0.0f;public final vo

29、id collect(int doc, float score) if (score > 0.0f &&(bits=null | bits.get(doc) / skip docs not in bits totalHits0+; if (score >= minScore) /* 原先：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ù)源索引時

30、已經(jīng)按照某個字段排好了序，而結(jié)果根據(jù)docID 排序也就實(shí)現(xiàn)了 * 針對某個字段的排序，甚至可以實(shí)現(xiàn)更復(fù)雜的score和docID的擬合。 */ hq.put(new ScoreDoc(doc, (float) 1/doc ); if (hq.size() > nDocs) hq.pop(); / remove lowest in hit queueminScore = (ScoreDoc)hq.top().score; / reset minScore , reader.maxDoc();更通用的輸入輸出接口雖然lucene沒有定義一個確定的輸入文檔格式，但越來越多的人想到使用一個標(biāo)準(zhǔn)

31、的中間格式作為Lucene的數(shù)據(jù)導(dǎo)入接口，然后其他數(shù)據(jù)，比如PDF只需要通過解析器轉(zhuǎn)換成標(biāo)準(zhǔn)的中間格式就可以進(jìn)行數(shù)據(jù)索引了。這個中間格式主要以XML為主，類似實(shí)現(xiàn)已經(jīng)不下4，5個：數(shù)據(jù)源: WORD PDF HTML DB other | | | / XML中間格式 | Lucene INDEX目前還沒有針對MSWord文檔的解析器，因?yàn)閃ord文檔和基于ASCII的RTF文檔不同，需要使用COM對象機(jī)制解析。這個是我在Google上查的相關(guān)資料：另外一個辦法就是把Word文檔轉(zhuǎn)換成text：索引過程優(yōu)化索引一般分2種情況，一種是小批量的索引擴(kuò)展，一種是大批量的索引重建。在索引過程中，并不是每

32、次新的DOC加入進(jìn)去索引都重新進(jìn)行一次索引文件的寫入操作（文件I/O是一件非常消耗資源的事情）。Lucene先在內(nèi)存中進(jìn)行索引操作，并根據(jù)一定的批量進(jìn)行文件的寫入。這個批次的間隔越大，文件的寫入次數(shù)越少，但占用內(nèi)存會很多。反之占用內(nèi)存少，但文件IO操作頻繁，索引速度會很慢。在IndexWriter中有一個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/

33、O有數(shù)量級的速度提升。而盡可能減少IndexSearcher的創(chuàng)建和對搜索結(jié)果的前臺的緩存也是必要的。Lucene面向全文檢索的優(yōu)化在于首次索引檢索后，并不把所有的記錄（Document）具體內(nèi)容讀取出來，而起只將所有結(jié)果中匹配度最高的頭100條結(jié)果（TopDocs）的ID放到結(jié)果集緩存中并返回，這里可以比較一下數(shù)據(jù)庫檢索：如果是一個10,000條的數(shù)據(jù)庫檢索結(jié)果集，數(shù)據(jù)庫是一定要把所有記錄內(nèi)容都取得以后再開始返回給應(yīng)用結(jié)果集的。所以即使檢索匹配總數(shù)很多，Lucene的結(jié)果集占用的內(nèi)存空間也不會很多。對于一般的模糊檢索應(yīng)用是用不到這么多的結(jié)果的，頭100條已經(jīng)可以滿足90%以上的檢索需求。如果

34、首批緩存結(jié)果數(shù)用完后還要讀取更后面的結(jié)果時Searcher會再次檢索并生成一個上次的搜索緩存數(shù)大1倍的緩存，并再重新向后抓取。所以如果構(gòu)造一個Searcher去查1120條結(jié)果，Searcher其實(shí)是進(jìn)行了2次搜索過程：頭100條取完后，緩存結(jié)果用完，Searcher重新檢索再構(gòu)造一個200條的結(jié)果緩存，依此類推，400條緩存，800條緩存。由于每次Searcher對象消失后，這些緩存也訪問那不到了，你有可能想將結(jié)果記錄緩存下來，緩存數(shù)盡量保證在100以下以充分利用首次的結(jié)果緩存，不讓Lucene浪費(fèi)多次檢索，而且可以分級進(jìn)行結(jié)果緩存。Lucene的另外一個特點(diǎn)是在收集結(jié)果的過程中將匹配度低的

35、結(jié)果自動過濾掉了。這也是和數(shù)據(jù)庫應(yīng)用需要將搜索的結(jié)果全部返回不同之處。我的一些嘗試：· 支持中文的Tokenizer：這里有2個版本，一個是通過JavaCC生成的，對CJK部分按一個字符一個TOKEN索引，另外一個是從SimpleTokenizer改寫的，對英文支持?jǐn)?shù)字和字母TOKEN，對中文按迭代索引。· 基于XML數(shù)據(jù)源的索引器：XMLIndexer，因此所有數(shù)據(jù)源只要能夠按照DTD轉(zhuǎn)換成指定的XML，就可以用XMLIndxer進(jìn)行索引了。· 根據(jù)某個字段排序：按記錄索引順序排序結(jié)果的搜索器：IndexOrderSearcher，因此如果需要讓搜索結(jié)果根據(jù)某個字段排序，可以讓數(shù)據(jù)源先按某個字段排好序（比如：PriceField），這樣索引后，然后在利用這個按記錄的ID順序檢索的搜索器，結(jié)果就是相當(dāng)于是那個字段排序的結(jié)果了。從Lucene學(xué)到更多Lu