Lucene(發(fā)音為 ['lusen] )是一個非常優(yōu)秀的開源的全文搜索引擎,我們可以在它的上面開發(fā)出各種全文搜索的應(yīng)用來。Lucene在國外有很高的知名度，現(xiàn)在已經(jīng)是Apache的頂級項目，在國內(nèi)，Lucene的應(yīng)用也越來越多。

Lucene的算法原理：

　　Lucene是一個高性能的java全文檢索工具包，它使用的是倒排文件索引結(jié)構(gòu)。該結(jié)構(gòu)及相應(yīng)的生成算法如下：

　0）設(shè)有兩篇文章1和2
　　 文章1的內(nèi)容為：Tom lives in Guangzhou,I live in Guangzhou too.
　　 文章2的內(nèi)容為：He once lived in Shanghai.

　1)全文分析：由于lucene是基于關(guān)鍵詞索引和查詢的，首先我們要取得這兩篇文章的關(guān)鍵詞，通常我們需要如下處理措施
　　a.我們現(xiàn)在有的是文章內(nèi)容，即一個字符串，我們先要找出字符串中的所有單詞，即分詞。英文單詞由于用空格分隔，比較好處理。中文單詞間是連在一起的需要特殊的分詞處理。
　　b.文章中的”in”, “once” “too”等詞沒有什么實際意義，中文中的“的”“是”等字通常也無具體含義，這些不代表概念的詞可以過濾掉
　　c.用戶通常希望查“He”時能把含“he”，“HE”的文章也找出來，所以所有單詞需要統(tǒng)一大小寫。
　　d.用戶通常希望查“live”時能把含“lives”，“lived”的文章也找出來，所以需要把“lives”，“lived”還原成“live”
　　e.文章中的標點符號通常不表示某種概念，也可以過濾掉
　在lucene中以上措施由Analyzer類完成

　經(jīng)過上面處理后
　　文章1的所有關(guān)鍵詞為：[tom] [live] [guangzhou] [i] [live] [guangzhou]
　　文章2的所有關(guān)鍵詞為：[he] [live] [shanghai]

　2) 倒排索引：有了關(guān)鍵詞后，我們就可以建立倒排索引了。上面的對應(yīng)關(guān)系是：“文章號”對“文章中所有關(guān)鍵詞”。倒排索引把這個關(guān)系倒過來，變成：“關(guān)鍵詞”對“擁有該關(guān)鍵詞的所有文章號”。文章1，2經(jīng)過倒排后變成
關(guān)鍵詞 文章號
　　guangzhou 1
　　he 2
　　i 1
　　live 1,2
　　shanghai 2
　　tom 1

　　通常僅知道關(guān)鍵詞在哪些文章中出現(xiàn)還不夠，我們還需要知道關(guān)鍵詞在文章中出現(xiàn)次數(shù)和出現(xiàn)的位置，通常有兩種位置：a)字符位置，即記錄該詞是文章中第幾個字符（優(yōu)點是關(guān)鍵詞亮顯時定位快）；b)關(guān)鍵詞位置，即記錄該詞是文章中第幾個關(guān)鍵詞（優(yōu)點是節(jié)約索引空間、詞組（phase）查詢快），lucene中記錄的就是這種位置。

加上“出現(xiàn)頻率”和“出現(xiàn)位置”信息后，我們的索引結(jié)構(gòu)變?yōu)椋?nbsp;

　　以live 這行為例我們說明一下該結(jié)構(gòu)：live在文章1中出現(xiàn)了2次，文章2中出現(xiàn)了一次，它的出現(xiàn)位置為“2,5,2”這表示什么呢？我們需要結(jié)合文章號和出現(xiàn)頻率來分析，文章1中出現(xiàn)了2次，那么“2,5”就表示live在文章1中出現(xiàn)的兩個位置，文章2中出現(xiàn)了一次，剩下的“2”就表示live是文章2中第 2個關(guān)鍵字。
　　以上就是lucene索引結(jié)構(gòu)中最核心的部分。我們注意到關(guān)鍵字是按字符順序排列的（lucene沒有使用B樹結(jié)構(gòu)），因此lucene可以用二元搜索算法快速定位關(guān)鍵詞。
　　實現(xiàn)時 lucene將上面三列分別作為詞典文件（Term Dictionary）、頻率文件(frequencies)、位置文件 (positions)保存。其中詞典文件不僅保存有每個關(guān)鍵詞，還保留了指向頻率文件和位置文件的指針，通過指針可以找到該關(guān)鍵字的頻率信息和位置信息。

　　Lucene中使用了field的概念，用于表達信息所在位置（如標題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個關(guān)鍵詞都有一個field信息(因為每個關(guān)鍵字一定屬于一個或多個field)。
　　為了減小索引文件的大小，Lucene對索引還使用了壓縮技術(shù)。首先，對詞典文件中的關(guān)鍵詞進行了壓縮，關(guān)鍵詞壓縮為<前綴長度，后綴>，例如：當前詞為“阿拉伯語”，上一個詞為“阿拉伯”，那么“阿拉伯語”壓縮為<3，語>。其次大量用到的是對數(shù)字的壓縮，數(shù)字只保存與上一個值的差值（這樣可以減小數(shù)字的長度，進而減少保存該數(shù)字需要的字節(jié)數(shù)）。例如當前文章號是16389（不壓縮要用3個字節(jié)保存），上一文章號是16382，壓縮后保存7（只用一個字節(jié)）。 注意是“上一個詞”。由于詞典是按順序排列的，這種壓縮方法的效果會非常顯著。

　　下面我們可以通過對該索引的查詢來解釋一下為什么要建立索引。
假設(shè)要查詢單詞 “live”，lucene先對詞典二元查找、找到該詞，通過指向頻率文件的指針讀出所有文章號，然后返回結(jié)果。詞典通常非常小，因而，整個過程的時間是毫秒級的。
而用普通的順序匹配算法，不建索引，而是對所有文章的內(nèi)容進行字符串匹配，這個過程將會相當緩慢，當文章數(shù)目很大時，時間往往是無法忍受的。

全文檢索框架的實現(xiàn)機制：

　　Lucene的API接口設(shè)計的比較通用，輸入輸出結(jié)構(gòu)都很像數(shù)據(jù)庫的表==>記錄==>字段，所以很多傳統(tǒng)的應(yīng)用的文件、數(shù)據(jù)庫等都可以比較方便的映射到Lucene的存儲結(jié)構(gòu)/接口中。總體上看：可以先把Lucene當成一個支持全文索引的數(shù)據(jù)庫系統(tǒng)。

比較一下Lucene和數(shù)據(jù)庫：

全文檢索 ≠ like "%keyword%"

　　由于數(shù)據(jù)庫索引不是為全文索引設(shè)計的，因此，使用like "%keyword%"時，數(shù)據(jù)庫索引是不起作用的，在使用like查詢時，搜索過程又變成類似于一頁頁翻書的遍歷過程了，所以對于含有模糊查詢的數(shù)據(jù)庫服務(wù)來說，LIKE對性能的危害是極大的。如果是需要對多個關(guān)鍵詞進行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。

　　通常比較厚的書籍后面常常附關(guān)鍵詞索引表（比如：北京：12, 34頁，上海：3,77頁……），它能夠幫助讀者比較快地找到相關(guān)內(nèi)容的頁碼。而數(shù)據(jù)庫索引能夠大大提高查詢的速度原理也是一樣，想像一下通過書后面的索引查找的速度要比一頁一頁地翻內(nèi)容高多少倍……而索引之所以效率高，另外一個原因是它是排好序的。對于檢索系統(tǒng)來說核心是一個排序問題。

　　所以建立一個高效檢索系統(tǒng)的關(guān)鍵是建立一個類似于科技索引一樣的反向索引機制，將數(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ù)庫的精確查詢是一個非常不確定的問題，這也是大部分數(shù)據(jù)庫對全文檢索支持有限的原因。Lucene最核心的特征是通過特殊的索引結(jié)構(gòu)實現(xiàn)了傳統(tǒng)數(shù)據(jù)庫不擅長的全文索引機制，并提供了擴展接口，以方便針對不同應(yīng)用的定制。

　　可以通過一下表格對比一下數(shù)據(jù)庫的模糊查詢：

全文檢索和數(shù)據(jù)庫應(yīng)用最大的不同在于：讓最相關(guān)的 頭100條結(jié)果滿足98%以上用戶的需求。
Lucene的創(chuàng)新之處：

　　大部分的搜索（數(shù)據(jù)庫）引擎都是用B樹結(jié)構(gòu)來維護索引，索引的更新會導(dǎo)致大量的IO操作，Lucene在實現(xiàn)中，對此稍微有所改進：不是維護一個索引文件，而是在擴展索引的時候不斷創(chuàng)建新的索引文件，然后定期的把這些新的小索引文件合并到原先的大索引中（針對不同的更新策略，批次的大小可以調(diào)整），這樣在不影響檢索的效率的前提下，提高了索引的效率。

Lucene和其他一些全文檢索系統(tǒng)/應(yīng)用的比較：

關(guān)于亞洲語言的的切分詞問題(Word Segment)
　　對于中文來說，全文索引首先還要解決一個語言分析的問題，對于英文來說，語句中單詞之間是天然通過空格分開的，但亞洲語言的中日韓文語句中的字是一個字挨一個，所有，首先要把語句中按“詞”進行索引的話，這個詞如何切分出來就是一個很大的問題。
　　首先，肯定不能用單個字符作(si-gram)為索引單元，否則查“上海”時，不能讓含有“海上”也匹配。
但一句話：“北京天安門”，計算機如何按照中文的語言習慣進行切分呢？
　　“北京 天安門” 還是“北 京 天安門”？讓計算機能夠按照語言習慣進行切分，往往需要機器有一個比較豐富的詞庫才能夠比較準確的識別出語句中的單詞。
　　另外一個解決的辦法是采用自動切分算法：將單詞按照2元語法(bigram)方式切分出來，比如：
　　　　"北京天安門" ==> "北京 京天 天安 安門"。
這樣，在查詢的時候，無論是查詢"北京" 還是查詢"天安門"，將查詢詞組按同樣的規(guī)則進行切分："北京"，"天安安門"，多個關(guān)鍵詞之間按與"and"的關(guān)系組合，同樣能夠正確地映射到相應(yīng)的索引中。這種方式對于其他亞洲語言：韓文，日文都是通用的。
　　基于自動切分的最大優(yōu)點是沒有詞表維護成本，實現(xiàn)簡單，缺點是索引效率低，但對于中小型應(yīng)用來說，基于2元語法的切分還是夠用的。基于2元切分后的索引一般大小和源文件差不多，而對于英文，索引文件一般只有原文件的30%-40%不同。

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

Lucene的結(jié)構(gòu)框架：
　　注意：Lucene中的一些比較復(fù)雜的詞法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，純Java的詞法分析生成器），所以如果從源代碼編譯或需要修改其中的QueryParser、定制自己的詞法分析器，還需要從https://javacc.dev.java.net/下載javacc。
　　lucene的組成結(jié)構(gòu)：對于外部應(yīng)用來說索引模塊(index)和檢索模塊(search)是主要的外部應(yīng)用入口。

從Lucene學(xué)到更多：
　　Luene的確是一個面對對象設(shè)計的典范。

1. 所有的問題都通過一個額外抽象層來方便以后的擴展和重用：你可以通過重新實現(xiàn)來達到自己的目的，而對其他模塊而不需要；
2. 簡單的應(yīng)用入口Searcher, Indexer，并調(diào)用底層一系列組件協(xié)同的完成搜索任務(wù)；
3. 所有的對象的任務(wù)都非常專一：比如搜索過程：QueryParser分析將查詢語句轉(zhuǎn)換成一系列的精確查詢的組合(Query),通過底層的索引讀取結(jié)構(gòu)IndexReader進行索引的讀取，并用相應(yīng)的打分器給搜索結(jié)果進行打分/排序等。所有的功能模塊原子化程度非常高，因此可以通過重新實現(xiàn)而不需要修改其他模塊。 
4. 除了靈活的應(yīng)用接口設(shè)計，Lucene還提供了一些適合大多數(shù)應(yīng)用的語言分析器實現(xiàn)（SimpleAnalyser,StandardAnalyser），這也是新用戶能夠很快上手的重要原因之一。

這些優(yōu)點都是非常值得在以后的開發(fā)中學(xué)習借鑒的。作為一個通用工具包，Lunece的確給予了需要將全文檢索功能嵌入到應(yīng)用中的開發(fā)者很多的便利。
　　此外，通過對Lucene的學(xué)習和使用，我也更深刻地理解了為什么很多數(shù)據(jù)庫優(yōu)化設(shè)計中要求，比如：

1. 盡可能對字段進行索引來提高查詢速度，但過多的索引會對數(shù)據(jù)庫表的更新操作變慢，而對結(jié)果過多的排序條件，實際上往往也是性能的殺手之一。
2. 很多商業(yè)數(shù)據(jù)庫對大批量的數(shù)據(jù)插入操作會提供一些優(yōu)化參數(shù)，這個作用和索引器的merge_factor的作用是類似的。
3. 20%/80%原則：查的結(jié)果多并不等于質(zhì)量好，尤其對于返回結(jié)果集很大，如何優(yōu)化這頭幾十條結(jié)果的質(zhì)量往往才是最重要的。
4. 盡可能讓應(yīng)用從數(shù)據(jù)庫中獲得比較小的結(jié)果集，因為即使對于大型數(shù)據(jù)庫，對結(jié)果集的隨機訪問也是一個非常消耗資源的操作。

本文轉(zhuǎn)自：http://www.chedong.com/tech/lucene.html