【正文】 所以建立一個(gè)高效檢索系統(tǒng)的關(guān)鍵是建立一個(gè)類似于科技索引一樣的反向索引機(jī)制，將數(shù)據(jù)源（比如多篇文章）排序順序存儲(chǔ)的同時(shí)，有另外一個(gè)排好序的關(guān)鍵詞列表，用于存儲(chǔ)關(guān)鍵詞 。 由于數(shù)據(jù)庫索引不是為全文索引設(shè)計(jì)的，因此，使用 like %keyword%時(shí)，數(shù)據(jù)庫索引是不起作用的，在使用 like 查詢時(shí)，搜索過程又變成類似于一頁頁翻書的遍歷過程了，所以對于含有模糊查詢的數(shù)據(jù)庫服務(wù)來說， LIKE 對性能的危害是極大的。而數(shù)據(jù)庫索引能夠大大提高查詢的速度原理也是一樣，想像一下通過書后面的索引查找的速度要比一頁一頁地翻內(nèi)容高多少倍 ?? 而索引之所以效率高，另外一個(gè)原因是它是排好序的?；?2元切分后的索引一般大小和源文件差不多，而對于英文，索引文件一般只有原文件的 30%40%不同， 自動(dòng)切分 詞表切分 實(shí)現(xiàn) 實(shí)現(xiàn)非常簡單 實(shí)現(xiàn)復(fù)雜 查詢 增加了查詢分析的復(fù)雜程度 適于實(shí)現(xiàn)比較復(fù)雜的查詢語法規(guī)則 存儲(chǔ)效率 索引冗余大，索引幾乎和原文一樣大 索引效率高，為原文大小的 30％左右 維護(hù)成本 無詞表維護(hù)成本 詞表維護(hù)成本非常高：中日韓等語言需要分別維護(hù)。這種方式對于其他亞洲語言：韓文，日文都是通用的。另外一個(gè)解決的辦法是采用自動(dòng)切分算法：將單詞按照 2 元語法 (bigram)方式切分出來，比如： 北京天安門 == 北京 京天 天安 安門 。 首先，肯定不能用單個(gè)字符作 (sigram)為索引單元，否則查 “ 上海 ” 時(shí)，不能讓含有 “ 海上 ” 也匹配。 分詞結(jié)果為： 此外 巴黎 市政府 所在地 和 巴黎 兩座 體育場 會(huì) 掛出 寫有 相同 話語 的 巨幅 標(biāo)語 這 兩座 體育場 還 安裝 了 巨大 屏幕 以 方便 巴黎 市民 和 游客 觀看 決賽 提示 這個(gè) lucene 分詞器還比較脆弱，要想將其用于某類項(xiàng)目中您還需要做一些工作，不過我想這里的 lucene 分詞器會(huì) 成為您很好的起點(diǎn)。 } catch (IOException e) { ()。 } if (!((0, 3).intern())) { ((0, 3).intern(), 2)。 if (() == 3) { if (!((0, 2).intern())) { ((0, 2).intern(), 2)。amp。 String word = null。 try { InputStream words = new FileInputStream()。 //裝載詞庫，您必須明白它的邏輯和之所以這樣做的目的，這樣您才能理解正向最大匹配法是如何實(shí)現(xiàn)的 public void loadWords() { if (simWords != null)return。 (0)。 break。 if ((temp)) { (c)。 if (() == 0) { (c)。amp。 ub = (c)。 } else { break。 bufferIndex = 0。 ub。 StringBuffer currentWord = new StringBuffer()。 public CJKTokenizer(Reader input) { = input。 private final char[] ioBuffer = new char[IO_BUFFER_SIZE]。 private int bufferIndex = 0。 /** * author solo L * */ public class CJKTokenizer extends Tokenizer { //這個(gè) TreeMap 用來緩存詞庫 private static TreeMap simWords = null。 import 。 import 。 import 。 import 。 } } package 。 public CJKAnalyzer() { stopTable = (STOP_WORDS)。 /** * author solo L * */ public class CJKAnalyzer extends Analyzer {//實(shí)現(xiàn)了 Analyzer 接口，這是 lucene的要求 public final static String[] STOP_WORDS = {}。 import 。 import 。常用的幾種機(jī)械分詞方法如下： 正向最大匹配法（由左 到右的方向） 逆向最大匹配法（由右到左的方向） 分詞器實(shí)現(xiàn) 這個(gè)實(shí)現(xiàn)了機(jī)械分詞中正向最大匹配法的 Lucene 分詞器包括兩個(gè)類， CJKAnalyzer和 CJKTokenizer，他們的源代碼如下： package 。若在詞庫中找到某個(gè)字符串則匹配成功（識(shí)別出一個(gè)詞）。 中文分詞技術(shù) 現(xiàn)有的分詞技術(shù)可分為三類： 基于字符串匹配的分詞 基于理解的分詞 基于統(tǒng)計(jì)的分詞 這篇文章中使用的是基于字符串匹配的分詞技術(shù)，這種技術(shù)也被稱為機(jī)械分詞。把中文的漢字序列切分成有意義的詞，就是中文分詞，有些人也稱為切詞。例如，英文句子 I am a student，用中文則為：“我是一個(gè)學(xué)生”。 StandardAnalyzer 類是使用一個(gè) English 的 stop words 列表來進(jìn)行 tokenize 分解出文本中 word，使用 StandardTokenizer 類分解詞，再加上 StandardFilter 以及LowerCaseFilter以及 StopFilter這些過濾器進(jìn)行處理的這樣一個(gè) Analyzer類的實(shí)現(xiàn)。然后一個(gè)或更多的 TokenFilters可以 應(yīng)用在這個(gè) Tokenizer 的輸出上。 Analyzer 類構(gòu)建用于分析文本的TokenStream 對象，因此（ thus）它表示（ represent）用于從文本中分解（ extract）出組成索引的 terms 的一個(gè)規(guī)則器（ policy）。詞典通常非常小，因而，整個(gè)過程的時(shí)間是毫秒級的。 下面我們可以通過對該索引的查詢來解釋一下為什么要建立索引。其次大量用到的是對數(shù)字的 壓縮，數(shù)字只保存與上一個(gè)值的差值（這樣可以減小數(shù)字的長度，進(jìn)而減少保存該數(shù)字需要的字節(jié)數(shù)）。 為了減小索引文件的大小， Lucene 對索引還使用了壓縮技術(shù)。其中詞典文件不僅保存有每個(gè)關(guān)鍵詞，還保留了指向頻率文件和位置文件的指針，通過 指針可以找到該關(guān)鍵字的頻率信息和位置信息。我們注意到關(guān)鍵字是按字符順序排列的（ lucene 沒有使用 B 樹結(jié)構(gòu)），因此 lucene 可以用二元搜索算法快速定位關(guān)鍵詞。 加上“出現(xiàn)頻率”和“出現(xiàn)位置”信息后，我們的索引結(jié)構(gòu)變?yōu)椋? 關(guān)鍵詞 文章號(hào) 出現(xiàn)位置 guangzhou 1[2] 3， 6 he 2[1] 1 i 1[1] 4 live 1[2],2[1] 2， 5， 2 shanghai 2[1] 3 tom 1[1] 1 以 live 這行為例我們說明一下該結(jié)構(gòu)： live 在文章 1 中出現(xiàn)了 2 次，文章 2 中出現(xiàn)了一次，它的出現(xiàn)位置為“ 2,5,2”這表示什么呢？我們需要結(jié)合文章號(hào)和出現(xiàn)頻率 來分析，文章 1 中出現(xiàn)了 2 次，那么“ 2,5”就表示 live 在文章 1 中出現(xiàn)的兩個(gè)位置，文章 2 中出現(xiàn)了一次，剩下的“ 2”就表示 live 是文章 2 中第 2 個(gè)關(guān)鍵字。倒排索引把這個(gè)關(guān)系倒過來，變成：“關(guān)鍵詞”對“擁有該關(guān)鍵詞的所有文章號(hào)”。 用戶通常希望查“ live”時(shí)能把含“ lives”，“ lived”的文章也找出來，所以需要把“ lives”，“ lived”還原成“ live” 文章中的標(biāo)點(diǎn)符號(hào)通常不表示某種概念，也可以過濾掉，在 lucene 中以上措施由 Analyzer 類完成，經(jīng)過上面處理后 文章 1 的所有關(guān)鍵詞為： [tom] [live] [guangzhou] [live] [guangzhou] 文章 2 的所有關(guān)鍵 詞為： [he] [live] [shanghai] 三、 有了關(guān)鍵詞后，我們就可以建立倒排索引了。中文單詞間是連在一起的需要特殊的分詞處理。該結(jié)構(gòu)及相應(yīng)的生成算法如下： 一、設(shè)有兩篇文章 1 和 2 文章 1 的內(nèi)容為： Tom lives in Guangzhou,I live in Guangzhou too. 文章 2 的內(nèi)容為： He once lived in Shanghai. 二、由于 lucene 是基于關(guān)鍵詞索引和查詢的，首先我們要取得這兩篇文章的關(guān)鍵詞，通常我們需要如下處理措施 我們現(xiàn)在有的是文章內(nèi)容，即一個(gè)字符串，我們先要找出字符串中的所有單詞，即分詞。 Lucene 最核心的特征是通過特殊的索引結(jié)構(gòu)實(shí)現(xiàn)了傳統(tǒng)數(shù)據(jù)庫不擅長的全文索引機(jī)制，并提供了擴(kuò)展接口，以方便針對不同應(yīng)用的定制。從而大大提高了多關(guān)鍵詞查詢的效率，所以，全文 檢索問題歸結(jié)到最后是一個(gè)排序問題。對于檢索系統(tǒng)來說核心是一個(gè)排序問題。 通常比較厚的書籍后面常常附關(guān)鍵詞索引表（比如：北京： 12, 34 頁，上海：3,77 頁 ?? ），它能夠幫助讀者比較快地找到相關(guān)內(nèi)容的頁碼。 比較一下 Lucene 和數(shù)據(jù)庫： 全文檢索 ≠ like %keyword% 由于數(shù)據(jù)庫索引不是為全文索引設(shè)計(jì)的，因此，使用 like %keyword%時(shí)，數(shù)據(jù)庫索引是不起作用的，在使用 like 查詢時(shí)，搜索過程又變成類似于一頁頁翻書的遍歷過程了，所以 對于含有模糊查詢的數(shù)據(jù)庫 服務(wù)來說， LIKE 對性能的危害是極大 的。 Lucene 的 API 接口設(shè)計(jì)的比較通用，輸入輸出結(jié)構(gòu)都很像數(shù)據(jù)庫的表 ==記錄 ==字段，所以很多傳統(tǒng)的應(yīng)用的文件、數(shù)據(jù)庫等都可以 比較方便的映射到 Lucene 的存儲(chǔ)結(jié)構(gòu) /接口中。 Lucene 可以作為一個(gè)運(yùn)行庫被包含進(jìn)入應(yīng)用本身中去，而不是做為一個(gè)單獨(dú)的索引服務(wù)器存在。在高度的面向?qū)ο罄碚摰闹蜗拢沟肔ucene 的實(shí)現(xiàn)容易理解，易于擴(kuò)展。在索引核心的基礎(chǔ)上開始設(shè)計(jì)對外的接口 與。 從面象對象的觀點(diǎn)來考察， Lucene 應(yīng)用了最基本的一條程序設(shè)計(jì)準(zhǔn)則：引入 額 外 的 抽 象 層 以 降 低 耦 合 性 。 Lucene 的將所有源碼分為了 7 個(gè)模塊（在 java 語言中以包即 package 來表示），各個(gè)模塊所屬的系統(tǒng)部分也如上圖所示。 以下將討論 Lucene 系統(tǒng)的結(jié)構(gòu)組織，并給出系統(tǒng)結(jié)構(gòu)與源碼組織圖： 從圖中我們清楚的看到， Lucene 的系統(tǒng)由基礎(chǔ)結(jié)構(gòu)封裝、索引核心、對外接口三大部分組成。 Lucene 系統(tǒng)結(jié)構(gòu)分析 Lucene 作為一個(gè)優(yōu)秀的全文檢索引擎，其系統(tǒng)結(jié)構(gòu)具有強(qiáng)烈的面向?qū)ο筇卣鳌Ｗ詈?，轉(zhuǎn)移到 apache 軟件基金會(huì)后，借助于 apache 軟件基金會(huì)的網(wǎng)絡(luò)平臺(tái)，程序員可以方便的和開發(fā)者、其它程序員交流，促成資源的共享，甚至直接獲得已經(jīng)編寫完備的擴(kuò)充功能。在這一點(diǎn)上，商業(yè)軟件的靈活性遠(yuǎn)遠(yuǎn)不及Lucene。