Lucene 基于java的全文搜索引擎簡(jiǎn)介_(kāi)第1頁(yè)
Lucene 基于java的全文搜索引擎簡(jiǎn)介_(kāi)第2頁(yè)
Lucene 基于java的全文搜索引擎簡(jiǎn)介_(kāi)第3頁(yè)
Lucene 基于java的全文搜索引擎簡(jiǎn)介_(kāi)第4頁(yè)
Lucene 基于java的全文搜索引擎簡(jiǎn)介_(kāi)第5頁(yè)
已閱讀5頁(yè),還剩5頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶(hù)提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

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

2、檢索的支持;基于Java的全文索引/檢索引擎LuceneLucene不是一個(gè)完整的全文索引應(yīng)用,而是是一個(gè)用Java寫(xiě)的全文索引引擎工具包,它可以方便的嵌入到各種應(yīng)用中實(shí)現(xiàn)針對(duì)應(yīng)用的全文索引/檢索功能。Lucene的作者:Lucene的貢獻(xiàn)者Doug Cutting是一位資深全文索引/檢索專(zhuān)家,曾經(jīng)是V-Twin搜索引擎(Apple的Copland操作系統(tǒng)的成就之一)的主要開(kāi)發(fā)者,后在Excite擔(dān)任高級(jí)系統(tǒng)架構(gòu)設(shè)計(jì)師,目前從事于一些INTERNET底層架構(gòu)的研究。他貢獻(xiàn)出的Lucene的目標(biāo)是為各種中小型應(yīng)用程序加入全文檢索功能。Lucene的發(fā)展歷程:早先發(fā)布在作者自己的,后來(lái)發(fā)布在Sou

3、rceForge,2001年年底成為APACHE基金會(huì)jakarta的一個(gè)子項(xiàng)目:已經(jīng)有很多Java項(xiàng)目都使用了Lucene作為其后臺(tái)的全文索引引擎,比較著名的有:· Jive:WEB論壇系統(tǒng);· Eyebrows:郵件列表HTML歸檔/瀏覽/查詢(xún)系統(tǒng),本文的主要參考文檔“TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows系統(tǒng)的主要開(kāi)發(fā)者之一,而EyeBrows已經(jīng)成為目前APACHE項(xiàng)目的主要郵件列表歸檔系統(tǒng)。· Cocoon:基于XML的web發(fā)布框架,全文檢索部分使用了Luce

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

5、庫(kù):Lucene數(shù)據(jù)庫(kù)索引數(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:一個(gè)需要進(jìn)行索引的“單

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

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

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

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

10、結(jié)果輸出通過(guò)特別的算法,將最匹配度最高的頭100條結(jié)果輸出,結(jié)果集是緩沖式的小批量讀取的。返回所有的結(jié)果集,在匹配條目非常多的時(shí)候(比如上萬(wàn)條)需要大量的內(nèi)存存放這些臨時(shí)結(jié)果集??啥ㄖ菩酝ㄟ^(guò)不同的語(yǔ)言分析接口實(shí)現(xiàn),可以方便的定制出符合應(yīng)用需要的索引規(guī)則(包括對(duì)中文的支持)沒(méi)有接口或接口復(fù)雜,無(wú)法定制結(jié)論高負(fù)載的模糊查詢(xún)應(yīng)用,需要負(fù)責(zé)的模糊查詢(xún)的規(guī)則,索引的資料量比較大使用率低,模糊匹配規(guī)則簡(jiǎn)單或者需要模糊查詢(xún)的資料量少全文檢索和數(shù)據(jù)庫(kù)應(yīng)用最大的不同在于:讓最相關(guān)的頭100條結(jié)果滿(mǎn)足98%以上用戶(hù)的需求Lucene的創(chuàng)新之處:大部分的搜索(數(shù)據(jù)庫(kù))引擎都是用B樹(shù)結(jié)構(gòu)來(lái)維護(hù)索引,索引的更新會(huì)導(dǎo)致大

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

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

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

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

15、間按與"and"的關(guān)系組合,同樣能夠正確地映射到相應(yīng)的索引中。這種方式對(duì)于其他亞洲語(yǔ)言:韓文,日文都是通用的?;谧詣?dòng)切分的最大優(yōu)點(diǎn)是沒(méi)有詞表維護(hù)成本,實(shí)現(xiàn)簡(jiǎn)單,缺點(diǎn)是索引效率低,但對(duì)于中小型應(yīng)用來(lái)說(shuō),基于2元語(yǔ)法的切分還是夠用的?;?元切分后的索引一般大小和源文件差不多,而對(duì)于英文,索引文件一般只有原文件的30%-40%不同,自動(dòng)切分詞表切分實(shí)現(xiàn)實(shí)現(xiàn)非常簡(jiǎn)單實(shí)現(xiàn)復(fù)雜查詢(xún)?cè)黾恿瞬樵?xún)分析的復(fù)雜程度,適于實(shí)現(xiàn)比較復(fù)雜的查詢(xún)語(yǔ)法規(guī)則存儲(chǔ)效率索引冗余大,索引幾乎和原文一樣大索引效率高,為原文大小的30左右維護(hù)成本無(wú)詞表維護(hù)成本詞表維護(hù)成本非常高:中日韓等語(yǔ)言需要分別維護(hù)。還需要包

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

17、下載javacc。lucene的組成結(jié)構(gòu):對(duì)于外部應(yīng)用來(lái)說(shuō)索引模塊(index)和檢索模塊(search)是主要的外部應(yīng)用入口org.apache.Lucene.search/搜索入口org.apache.Lucene.index/索引入口org.apache.Lucene.analysis/語(yǔ)言分析器org.apache.Lucene.queryParser/查詢(xún)分析器org.apache.Lucene.document/存儲(chǔ)結(jié)構(gòu)org.apache.Lucene.store/ 底層IO/存儲(chǔ)結(jié)構(gòu)org.apache.Lucene.util/一些公用的數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單的例子演示一下Lu

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

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

20、 throws Exception String indexPath = args0; IndexWriter writer; /用指定的語(yǔ)言分析器構(gòu)造一個(gè)新的寫(xiě)索引器(第3個(gè)參數(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個(gè)字段Field的Document對(duì)象 /一個(gè)是路徑path字段,不索引,只存儲(chǔ) /一個(gè)是內(nèi)容body字段,進(jìn)行全文索引,并存儲(chǔ) Document doc = new Document(); doc.add(Field.UnIndexed("path", argsi); doc.add(Field.Text("body", (Reader) new InputStreamReader(is); /將文檔寫(xiě)入索引 writer.addDocument(doc); is.close(); ; /關(guān)閉寫(xiě)索引器 writer.close();

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

23、索引,還可以通過(guò)調(diào)整IndexerWrite的文件合并頻率屬性(mergeFactor)來(lái)提高批量索引的效率。檢索過(guò)程和結(jié)果顯示:搜索結(jié)果返回的是Hits對(duì)象,可以通過(guò)它再訪問(wèn)Document=>Field中的內(nèi)容。假設(shè)根據(jù)body字段進(jìn)行全文檢索,可以將查詢(xún)結(jié)果的path字段和相應(yīng)查詢(xún)的匹配度(score)打印出來(lái),public class Search public static void main(String args) throws Exception String indexPath = args0, queryString = args1; /指向索引目錄的搜索器 Sear

24、cher searcher = new IndexSearcher(indexPath); /查詢(xún)解析器:使用和索引同樣的語(yǔ)言分析器 Query query = QueryParser.parse(queryString, "body", new SimpleAnalyzer(); /搜索結(jié)果使用Hits存儲(chǔ) Hits hits = searcher.search(query); /通過(guò)hits可以訪問(wèn)到相應(yīng)字段的數(shù)據(jù)和查詢(xún)的匹配度 for (int i=0; i<hits.length(); i+) System.out.println(hits.doc(i).ge

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

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

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

28、在搜索過(guò)程中訪問(wèn)存儲(chǔ)字段,速度回大大降低,因此非常是不可取的。但這里也有一個(gè)折中的解決方法:在搜索過(guò)程中能夠影響排序結(jié)果的只有索引中已經(jīng)存儲(chǔ)的docID和score這2個(gè)參數(shù),所以,基于score以外的排序,其實(shí)可以通過(guò)將數(shù)據(jù)源預(yù)先排好序,然后根據(jù)docID進(jìn)行排序來(lái)實(shí)現(xiàn)。這樣就避免了在LUCENE搜索結(jié)果外對(duì)結(jié)果再次進(jìn)行排序和在搜索過(guò)程中訪問(wèn)不在索引中的某個(gè)字段值。這里需要修改的是IndexSearcher中的HitCollector過(guò)程: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ù)源索引時(shí)

30、已經(jīng)按照某個(gè)字段排好了序,而結(jié)果根據(jù)docID 排序也就實(shí)現(xiàn)了 * 針對(duì)某個(gè)字段的排序,甚至可以實(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沒(méi)有定義一個(gè)確定的輸入文檔格式,但越來(lái)越多的人想到使用一個(gè)標(biāo)準(zhǔn)

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

32、次新的DOC加入進(jìn)去索引都重新進(jìn)行一次索引文件的寫(xiě)入操作(文件I/O是一件非常消耗資源的事情)。Lucene先在內(nèi)存中進(jìn)行索引操作,并根據(jù)一定的批量進(jìn)行文件的寫(xiě)入。這個(gè)批次的間隔越大,文件的寫(xiě)入次數(shù)越少,但占用內(nèi)存會(huì)很多。反之占用內(nèi)存少,但文件IO操作頻繁,索引速度會(huì)很慢。在IndexWriter中有一個(gè)MERGE_FACTOR參數(shù)可以幫助你在構(gòu)造索引器后根據(jù)應(yīng)用環(huán)境的情況充分利用內(nèi)存減少文件的操作。根據(jù)我的使用經(jīng)驗(yàn):缺省Indexer是每20條記錄索引后寫(xiě)入一次,每將MERGE_FACTOR增加50倍,索引速度可以提高1倍左右。搜索過(guò)程優(yōu)化lucene支持內(nèi)存索引:這樣的搜索比基于文件的I/

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

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

35、結(jié)果自動(dòng)過(guò)濾掉了。這也是和數(shù)據(jù)庫(kù)應(yīng)用需要將搜索的結(jié)果全部返回不同之處。我的一些嘗試:· 支持中文的Tokenizer:這里有2個(gè)版本,一個(gè)是通過(guò)JavaCC生成的,對(duì)CJK部分按一個(gè)字符一個(gè)TOKEN索引,另外一個(gè)是從SimpleTokenizer改寫(xiě)的,對(duì)英文支持?jǐn)?shù)字和字母TOKEN,對(duì)中文按迭代索引。· 基于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é)到更多Lu

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶(hù)所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶(hù)上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶(hù)上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶(hù)因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論