一、Lucene點滴

　　 (發(fā)音為['lusen])，我經(jīng)常就讀鹿神，是頭活蹦亂跳的好鹿，研究它吧，保證感覺它很神！Lucene是一個非常優(yōu)秀的開源的全文搜索引擎，我們可以在它的上面開發(fā)出各種全文搜索的應用來。Lucene在國外有很高的知名度，現(xiàn)在已經(jīng)是Apache的頂級項目。

二、倒排索引原理簡述

　　Lucene是一個高性能的Java全文檢索工具包，它使用的是倒排文件索引結(jié)構(gòu)。具體解釋算法理論就不講了，直接用例子來說明吧，如果你認真仔細的讀懂例子，真正領會了其中的思想，你肯定就明白了Lucene索引的基本原理！記住：理解！把例子用你自己的語言表述出來，就是翻譯成你自己的東西，以后你想自己寫，也就是換成計算機語言再翻譯一次！！
Lucene結(jié)構(gòu)及相應的生成算法如下：
我們設有兩篇文章1和2
　　 文章1的內(nèi)容為：Tom lives in Guangzhou,I live in Guangzhou too.
　　 文章2的內(nèi)容為：He once lived in Shanghai.

　　1)全文分析：

　　由于Lucene是基于關鍵詞索引和查詢的，首先我們要取得這兩篇文章的關鍵詞，通常我們需要如下處理措施
　　a. 我們現(xiàn)在有的是文章內(nèi)容，即一大串字符串，我們先要找出全文字符串中的所有單詞，即分詞。英文單詞由于用空格分隔，比較好處理。中文單詞間是連在一起的需要特殊的分詞處理。（中文通常用詞典的方式比較準確）
　　b. 文章中的”in”, “once” “too”等詞沒有什么實際意義，中文中的“的”“是”等字通常也無具體含義，這些不代表概念的詞可以過濾掉，即分詞解析中的過濾
　　c. 用戶通常希望查“He”時能把含“he”，“HE”的文章也找出來，所以所有單詞需要統(tǒng)一大小寫。即解析過程中的額外處理（用戶可以根據(jù)自己需要增加多重處理）。
　　d. 用戶通常希望查“live”時能把含“lives”，“lived”的文章也找出來，所以需要把“lives”，“lived”還原成“live”即進一步優(yōu)化處理（可以更人性更友好）
　　e. 文章中的標點符號通常不表示某種概念，也可以過濾掉
　　所有上面描述的步驟在lucene中都由Analyzer類完成！你了解了過程，你就可以根據(jù)自己的興趣或者需要去關心特點的步驟相關代碼，或者自己進一步添磚加瓦擴展功能。

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

　　2) 倒排索引：

　　有了關鍵詞后，我們就可以建立倒排索引了。
　　上面經(jīng)過解析后的對應關系是：“文章號”對“文章中所有關鍵詞”。
　　這種對應比較符合我們正常的思維習慣，反過來對應的話，就要顛倒思維，所以這種算法叫做倒排！ 倒排索引把這個關系倒過來，變成：“關鍵詞”對“擁有該關鍵詞的所有文章號”。文章1，2經(jīng)過倒排后變成
　　關鍵詞 文章號
　　guangzhou 1
　　he 2
　　i 1
　　live 1,2
　　shanghai 2
　　tom 1
　　進一步擴展上述基本倒排索引，通常我們僅知道關鍵詞在哪些文章中出現(xiàn)還不夠，我們還需要知道關鍵詞在文章中出現(xiàn)次數(shù)和出現(xiàn)的位置，通常有兩種位置：a)字符位置，即記錄該詞是文章中第幾個字符（優(yōu)點是關鍵詞亮顯時定位快）；b)關鍵詞位置，即記錄該詞是文章中第幾個關鍵詞（優(yōu)點是節(jié)約索引空間、詞組（phase）查詢快），lucene 中記錄的就是這種位置。

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

　　以第4行的 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個關鍵字。
　　以上就是lucene索引結(jié)構(gòu)中最核心的部分。是不是描述起來很簡單，沒錯，其實也就是這么簡單！算法都是人想出來的，毛主席說過辦法總比困難多，計算機算法也不例外，你何必恐懼它呢，本來就是很容易的事情！！！

　　【進一步深入探索，如果你不想深入，完全可以略過不看】 

　　如果你對計算機算法和數(shù)據(jù)結(jié)構(gòu)稍有研究，你就很容易發(fā)現(xiàn)，我們上面生成的倒排索引關鍵字是按字母字符順序排列的（Lucene沒有使用B樹結(jié)構(gòu)），因此Lucene可以用二元搜索算法快速定位關鍵詞。

　　具體實現(xiàn)時Lucene將上面三列分別作為詞典文件（Term Dictionary）、頻率文件(frequencies)、位置文件(positions)保存。其中詞典文件不僅保存有每個關鍵詞，還保留了指向頻率文件和位置文件的指針，通過指針可以找到該關鍵字的頻率信息和位置信息。

　　Lucene中使用了field的概念，用于表達信息所在位置（如標題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個關鍵詞都有一個field信息(因為每個關鍵字一定屬于一個或多個field)。

　　為了減小索引文件的大小，Lucene對索引還使用了壓縮技術。首先，對詞典文件中的關鍵詞進行了壓縮，關鍵詞壓縮為<前綴長度，后綴>，例如：當前詞為“阿拉伯語”，上一個詞為“阿拉伯”，那么“阿拉伯語”壓縮為<3，語>。其次大量用到的是對數(shù)字的壓縮，數(shù)字只保存與上一個值的差值（這樣可以減小數(shù)字的長度，進而減少保存該數(shù)字需要的字節(jié)數(shù)）。例如當前文章號是16389（不壓縮要用3個字節(jié)保存），上一文章號是16382，壓縮后保存7（只用一個字節(jié)）。注意是“上一個詞”。由于詞典是按順序排列的，這種壓縮方法的效果會非常顯著。

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

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

　　比較一下Lucene數(shù)據(jù)存儲和傳統(tǒng)的關系數(shù)據(jù)庫之間的區(qū)別：

　　請一定記住：全文檢索 ≠ 數(shù)據(jù)庫SQL語句中的 like "%keyword%"

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

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

　　所以建立一個高效檢索系統(tǒng)的關鍵是建立一個類似于科技索引一樣的反向索引機制，將數(shù)據(jù)源（比如多篇文章）排序順序存儲的同時，有另外一個排好序的關鍵詞列表，用于存儲關鍵詞==>文章映射關系，利用這樣的映射關系索引：[關鍵詞==>出現(xiàn)關鍵詞的文章編號，出現(xiàn)次數(shù)（甚至包括位置：起始偏移量，結(jié)束偏移量），出現(xiàn)頻率]，檢索過程就是把模糊查詢變成多個可以利用索引的精確查詢的邏輯組合的過程。從而大大提高了多關鍵詞查詢的效率，所以，全文檢索問題歸結(jié)到最后是一個排序問題。

　　由此可以看出模糊查詢相對數(shù)據(jù)庫的精確查詢是一個非常不確定的問題，這也是大部分數(shù)據(jù)庫對全文檢索支持有限的原因。

　　Lucene最核心的特征是通過特殊的索引結(jié)構(gòu)實現(xiàn)了傳統(tǒng)數(shù)據(jù)庫不擅長的全文索引機制，并提供了擴展接口，以方便針對不同應用的定制。

　　我們對比一下Lucene全文索引和關系數(shù)據(jù)庫模糊查詢 算法區(qū)別：

　　全文檢索和數(shù)據(jù)庫應用最大的不同在于：讓最相關的頭100條結(jié)果滿足98%以上用戶的需求。

　　Lucene的創(chuàng)新之處：

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

四、關于亞洲語言的的切分詞問題(Word Segment)

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

　　首先，肯定不能用單個字符作(si-gram)為索引單元，否則查“上海”時，不能讓含有“海上”也匹配。但一句話：“北京天安門”，計算機如何按照中文的語言習慣進行切分呢？“北京 天安門” 還是“北 京 天安門”？讓計算機能夠按照語言習慣進行切分，往往需要機器有一個比較豐富的詞庫才能夠比較準確的識別出語句中的單詞。

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

　　"北京天安門" ==> "北京 京天 天安 安門"。

　　這樣，在查詢的時候，無論是查詢"北京" 還是查詢"天安門"，將查詢詞組按同樣的規(guī)則進行切分："北京"，"天安安門"，多個關鍵詞之間按與"and"的關系組合，同樣能夠正確地映射到相應的索引中。這種方式對于其他亞洲語言：韓文，日文都是通用的。

　　基于自動切分的最大優(yōu)點是沒有詞表維護成本，實現(xiàn)簡單，缺點是索引效率低，但對于中小型應用來說，基于2元語法的切分還是夠用的。基于2元切分后的索引一般大小和源文件差不多，而對于英文，索引文件一般只有原文件的30%-40%不同。

目前比較大的搜索引擎的語言分析算法一般是基于以上2個機制的結(jié)合。

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

六、從Lucene學到更多：

　　Luene的確是一個面對對象設計的典范。如果你要學習面向?qū)ο缶幊蹋阋獙W習Java，建議你學習Lucene吧，玩一個實實在在的項目，而且是有名的基礎項目，在無形之中你既可以學習這個項目的使用，又可以學習Java語法，又可以學習大師們的代碼技巧，還可以以后為Lucene做點什么，真的你可以一舉多得！！！何樂不為呢？！

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

NET技術：Lucene.Net學習心得，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。