今天給大家介紹一下基于Java的全文索引引擎Lucene是怎樣的。文章的內(nèi)容小編覺得不錯，現(xiàn)在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著小編的思路一起來閱讀吧。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設(shè)、葉縣網(wǎng)站維護(hù)、網(wǎng)站推廣。

基于Java的全文索引引擎Lucene

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">Hacking Lucene：簡化的查詢分析器，刪除的實(shí)現(xiàn)，定制的排序，應(yīng)用接口的擴(kuò)展

6. 從Lucene我們還可以學(xué)到什么

基于Java的全文索引/檢索引擎——Lucene

Lucene不是一個完整的全文索引應(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è)計(jì)師，目前從事于一些INTE.NET底層架構(gòu)的研究。他貢獻(xiàn)出的Lucene的目標(biāo)是為各種中小型應(yīng)用程序加入全文檢索功能。

Lucene的發(fā)展歷程：早先發(fā)布在作者自己的www.lucene.com，后來發(fā)布在sourceforge.net/projects/lucene/">SourceForge，2001年年底成為apache基金會jakarta的一個子項(xiàng)目：http://jakarta.apache.org/lucene/

已經(jīng)有很多Java項(xiàng)目都使用了Lucene作為其后臺的全文索引引擎，比較著名的有：

• Jive：web論壇系統(tǒng)；

• Eyebrows：郵件列表HTML歸檔/瀏覽/查詢系統(tǒng)，本文的主要參考文檔“The Lucene search engine: Powerful, flexible, and free”作者就是EyeBrows系統(tǒng)的主要開發(fā)者之一，而EyeBrows已經(jīng)成為目前APACHE項(xiàng)目的主要郵件列表歸檔系統(tǒng)。

• XML.apache.org/cocoon/index.html">Cocoon: 基于XML的web發(fā)布框架，全文檢索部分使用了Lucene

• Eclipse.org">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)/接口中?？傮w上看：可以先把Lucene當(dāng)成一個支持全文索引的數(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...))

Document：一個需要進(jìn)行索引的“單元”
一個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ù)據(jù)庫索引不是為全文索引設(shè)計(jì)的，因此，使用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)鍵詞==>文章映射關(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ù)庫 索引 將數(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%"：就不能匹配詞序顛倒的xxx.net..xxx.com 匹配度 有匹配度算法，將匹配程度（相似度）比較高的結(jié)果排在前面。 沒有匹配程度的控制：比如有記錄中net出現(xiàn)5詞和出現(xiàn)1次的，結(jié)果是一樣的。 結(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)致大量的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è)計(jì)用于優(yōu)化批量索引和小批量的增量索引。 很多系統(tǒng)只支持批量的索引，有時數(shù)據(jù)源有一點(diǎn)增加也需要重建索引。 數(shù)據(jù)源 Lucene沒有定義具體的數(shù)據(jù)源，而是一個文檔的結(jié)構(gòu)，因此可以非常靈活的適應(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進(jìn)行索引/檢索
非英文支持：對亞洲語言，阿拉伯語言的索引支持 缺乏通用接口實(shí)現(xiàn) 查詢分析 通過查詢分析接口的實(shí)現(xiàn)，可以定制自己的查詢語法規(guī)則：
比如： 多個關(guān)鍵詞之間的 + - and or關(guān)系等 　 并發(fā)訪問 能夠支持多用戶的使用 　

關(guān)于亞洲語言的的切分詞問題(Word Segment)

對于中文來說，全文索引首先還要解決一個語言分析的問題，對于英文來說，語句中單詞之間是天然通過空格分開的，但亞洲語言的中日韓文語句中的字是一個字挨一個，所有，首先要把語句中按“詞”進(jìn)行索引的話，這個詞如何切分出來就是一個很大的問題。

首先，肯定不能用單個字符作(si-gram)為索引單元，否則查“上海”時，不能讓含有“海上”也匹配。

但一句話：“北京天安門”，計(jì)算機(jī)如何按照中文的語言習(xí)慣進(jìn)行切分呢？
“北京 天安門” 還是“北 京 天安門”？讓計(jì)算機(jī)能夠按照語言習(xí)慣進(jìn)行切分，往往需要機(jī)器有一個比較豐富的詞庫才能夠比較準(zhǔn)確的識別出語句中的單詞。

另外一個解決的辦法是采用自動切分算法：將單詞按照2元語法(bigram)方式切分出來，比如：
"北京天安門" ==> "北京 京天 天安 安門"。

這樣，在查詢的時候，無論是查詢"北京" 還是查詢"天安門"，將查詢詞組按同樣的規(guī)則進(jìn)行切分："北京"，"天安安門"，多個關(guān)鍵詞之間按與"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ù)。
還需要包括詞頻統(tǒng)計(jì)等內(nèi)容 適用領(lǐng)域 嵌入式系統(tǒng)：運(yùn)行環(huán)境資源有限
分布式系統(tǒng)：無詞表同步問題
多語言環(huán)境：無詞表維護(hù)成本 對查詢和存儲效率要求高的專業(yè)搜索引擎

目前比較大的搜索引擎的語言分析算法一般是基于以上2個機(jī)制的結(jié)合。關(guān)于中文的語言分析算法，大家可以在google查關(guān)鍵詞"word segment search"能找到更多相關(guān)的資料。

安裝和使用

下載：http://jakarta.apache.org/lucene/

注意：Lucene中的一些比較復(fù)雜的詞法分析是用JavaCC生成的（JavaCC：Java Compiler Compiler，純Java的詞法分析生成器），所以如果從源代碼編譯或需要修改其中的QueryParser、定制自己的詞法分析器，還需要從http://www.webgain.com/products/java_cc/下載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)

簡單的例子演示一下Lucene的使用方法：

索引過程：從命令行讀取文件名（多個），將文件分路徑(path字段)和內(nèi)容(body字段)2個字段進(jìn)行存儲，并對內(nèi)容進(jìn)行全文索引：索引的單位是Document對象，每個Document對象包含多個字段Field對象，針對不同的字段屬性和數(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(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 = args[0];
IndexWriter writer;
//用指定的語言分析器構(gòu)造一個新的寫索引器（第3個參數(shù)表示是否為追加索引）
writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);

for (int i=1; iSystem.out.println("Indexing file " + args[i]);
InputStream is = new FileInputStream(args[i]);

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

索引過程中可以看到：

• 語言分析器提供了抽象的接口，因此語言分析(Analyser)是可以定制的，雖然lucene缺省提供了2個比較通用的分析器SimpleAnalyser和StandardAnalyser，這2個分析器缺省都不支持中文，所以要加入對中文語言的切分規(guī)則，需要修改這2個分析器。

• Lucene并沒有規(guī)定數(shù)據(jù)源的格式，而只提供了一個通用的結(jié)構(gòu)（Document對象）來接受索引的輸入，因此輸入的數(shù)據(jù)源可以是：數(shù)據(jù)庫，WORD文檔，PDF文檔，HTML文檔……只要能夠設(shè)計(jì)相應(yīng)的解析轉(zhuǎn)換器將數(shù)據(jù)源構(gòu)造成成Docuement對象即可進(jìn)行索引。

• 對于大批量的數(shù)據(jù)索引，還可以通過調(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 = args[0], queryString = args[1];
//指向索引目錄的搜索器
Searcher 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).get("path") + "; Score: " +
hits.score(i));
};
}
}

在整個檢索過程中，語言分析器，查詢分析器，甚至搜索器（Searcher）都是提供了抽象的接口，可以根據(jù)需要進(jìn)行定制。

Hacking Lucene

簡化的查詢分析器

個人感覺lucene成為JAKARTA項(xiàng)目后，畫在了太多的時間用于調(diào)試日趨復(fù)雜QueryParser，而其中大部分是大多數(shù)用戶并不很熟悉的，目前LUCENE支持的語法：

Query ::= ( Clause )*
Clause ::= ["+", "-"] [":"] (| "(" 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)該是沒有問題的，而指定記錄的修改也似乎只能通過記錄的刪除，然后重新加入實(shí)現(xiàn)。如何刪除指定的記錄呢？刪除的方法也很簡單，只是需要在索引時根據(jù)數(shù)據(jù)源中的記錄ID專門另建索引，然后利用IndexReader.delete(Term term)方法通過這個記錄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)致效率非常的低，如果基于其他字段的排序需要在搜索過程中訪問存儲字段，速度回大大降低，因此非常是不可取的。

但這里也有一個折中的解決方法：在搜索過程中能夠影響排序結(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 void collect(int doc, float score) {
if (score > 0.0f && // ignore zeroed buckets
(bits==null || bits.get(doc))) { // skip docs not in bits
totalHits[0]++;
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ù)源索引時已經(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) { // if hit queue overfull
hq.pop(); // remove lowest in hit queue
minScore = ((ScoreDoc)hq.top()).score; // reset minScore
}
}
}
}
}, reader.maxDoc());

更通用的輸入輸出接口

雖然lucene沒有定義一個確定的輸入文檔格式，但越來越多的人想到使用一個標(biāo)準(zhǔn)的中間格式作為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

索引過程優(yōu)化

索引一般分2種情況，一種是小批量的索引擴(kuò)展，一種是大批量的索引重建。在索引過程中，并不是每次新的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面向全文檢索的優(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%以上的檢索需求。

如果首批緩存結(jié)果數(shù)用完后還要讀取更后面的結(jié)果時Searcher會再次檢索并生成一個上次的搜索緩存數(shù)大1倍的緩存，并再重新向后抓取。所以如果構(gòu)造一個Searcher去查1－120條結(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é)果的過程中將匹配度低的結(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é)到更多

Luene的確是一個面對對象設(shè)計(jì)的典范

• 所有的問題都通過一個額外抽象層來方便以后的擴(kuò)展和重用：你可以通過重新實(shí)現(xiàn)來達(dá)到自己的目的，而對其他模塊而不需要；

• 簡單的應(yīng)用入口Searcher, Indexer，并調(diào)用底層一系列組件協(xié)同的完成搜索任務(wù)；

• 所有的對象的任務(wù)都非常專一：比如搜索過程：QueryParser分析將查詢語句轉(zhuǎn)換成一系列的精確查詢的組合(Query), 通過底層的索引讀取結(jié)構(gòu)IndexReader進(jìn)行索引的讀取，并用相應(yīng)的打分器給搜索結(jié)果進(jìn)行打分/排序等。所有的功能模塊原子化程度非常高，因此可以通過重新實(shí)現(xiàn)而不需要修改其他模塊。 

• 除了靈活的應(yīng)用接口設(shè)計(jì)，Lucene還提供了一些適合大多數(shù)應(yīng)用的語言分析器實(shí)現(xiàn)（SimpleAnalyser, StandardAnalyser），這也是新用戶能夠很快上手的重要原因之一。

這些優(yōu)點(diǎn)都是非常值得在以后的開發(fā)中學(xué)習(xí)借鑒的。作為一個通用工具包，Lunece的確給予了需要將全文檢索功能嵌入到應(yīng)用中的開發(fā)者很多的便利。

此外，通過對Lucene的學(xué)習(xí)和使用，我也更深刻地理解了為什么很多數(shù)據(jù)庫優(yōu)化設(shè)計(jì)中要求，比如：

• 盡可能對字段進(jìn)行索引來提高查詢速度，但過多的索引會對數(shù)據(jù)庫表的更新操作變慢，而對結(jié)果過多的排序條件，實(shí)際上往往也是性能的殺手之一。

• 很多商業(yè)數(shù)據(jù)庫對大批量的數(shù)據(jù)插入操作會提供一些優(yōu)化參數(shù)，這個作用和索引器的merge_factor的作用是類似的，

• 20%/80%原則：查的結(jié)果多并不等于質(zhì)量好，尤其對于返回結(jié)果集很大，如何優(yōu)化這頭幾十條結(jié)果的質(zhì)量往往才是最重要的。

• 盡可能讓應(yīng)用從數(shù)據(jù)庫中獲得比較小的結(jié)果集，因?yàn)榧词箤τ诖笮蛿?shù)據(jù)庫，對結(jié)果集的隨機(jī)訪問也是一個非常消耗資源的操作。

以上就是基于Java的全文索引引擎Lucene是怎樣的的全部內(nèi)容了，更多與基于Java的全文索引引擎Lucene是怎樣的相關(guān)的內(nèi)容可以搜索創(chuàng)新互聯(lián)之前的文章或者瀏覽下面的文章進(jìn)行學(xué)習(xí)哈！相信小編會給大家增添更多知識,希望大家能夠支持一下創(chuàng)新互聯(lián)！

當(dāng)前名稱：基于Java的全文索引引擎Lucene是怎樣的
網(wǎng)站地址：http://jinyejixie.com/article34/poscpe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、用戶體驗(yàn)、服務(wù)器托管、網(wǎng)站內(nèi)鏈、手機(jī)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)