設計類圖

1：搜索類圖

2.Lucene的索引效率

一般書籍後面經常附關鍵詞索引表（好比：北京：12, 34頁，上海：3,77頁……），它可以幫助讀者比較快地找到相關內容的頁碼。而數據庫索引可以大大提升查詢的速度原理也是同樣，想像一下經過書後面的索引查找的速度要比一頁一頁地翻內容高多少倍……而索引之因此效率高，另一個緣由是它是排好序的。對於檢索系統來講核心是一個排序問題。

因爲數據庫索引不是爲全文索引設計的，所以，使用like "%keyword%"時，數據庫索引是不起做用的，在使用like查詢時，搜索過程又變成相似於一頁頁翻書的遍歷過程了，因此對於含有模糊查詢的數據庫服務來講，LIKE對性能的危害是極大的。若是是須要對多個關鍵詞進行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。因此創建一個高效檢索系統的關鍵是創建一個相似於科技索引同樣的反向索引機制，將數據源（好比多篇文章）排序順序存儲的同時，有另一個排好序的關鍵詞列表，用於存儲關鍵詞==>文章映射關係，利用這樣的映射關係索引：[關鍵詞==>出現關鍵詞的文章編號，出現次數（甚至包括位置：起始偏移量，結束偏移量），出現頻率]，檢索過程就是把模糊查詢變成多個能夠利用索引的精確查詢的邏輯組合的過程。從而大大提升了多關鍵詞查詢的效率，因此，全文檢索問題歸結到最後是一個排序問題。

由此能夠看出模糊查詢相對數據庫的精確查詢是一個很是不肯定的問題，這也是大部分數據庫對全文檢索支持有限的緣由。Lucene最核心的特徵是經過特殊的索引結構實現了傳統數據庫不擅長的全文索引機制，並提供了擴展接口，以方便針對不一樣應用的定製。

能夠經過一下表格對比一下數據庫的模糊查詢：

	Lucene全文索引引擎	數據庫
索引	將數據源中的數據都經過全文索引一一創建反向索引	對於LIKE查詢來講，數據傳統的索引是根本用不上的。數據須要逐個便利記錄進行GREP式的模糊匹配，比有索引的搜索速度要有多個數量級的降低。
匹配效果	經過詞元(term)進行匹配，經過語言分析接口的實現，能夠實現對中文等非英語的支持。	使用：like "%net%" 會把netherlands也匹配出來， 多個關鍵詞的模糊匹配：使用like "%com%net%"：就不能匹配詞序顛倒的xxx.net..xxx.com
匹配度	有匹配度算法，將匹配程度（類似度）比較高的結果排在前面。	沒有匹配程度的控制：好比有記錄中net出現5詞和出現1次的，結果是同樣的。
結果輸出	經過特別的算法，將最匹配度最高的頭100條結果輸出，結果集是緩衝式的小批量讀取的。	返回全部的結果集，在匹配條目很是多的時候（好比上萬條）須要大量的內存存放這些臨時結果集。
可定製性	經過不一樣的語言分析接口實現，能夠方便的定製出符合應用須要的索引規則（包括對中文的支持）	沒有接口或接口複雜，沒法定製
結論	高負載的模糊查詢應用，須要負責的模糊查詢的規則，索引的資料量比較大	使用率低，模糊匹配規則簡單或者須要模糊查詢的資料量少

 

3 中文切分詞機制

對於中文來講，全文索引首先還要解決一個語言分析的問題，對於英文來講，語句中單詞之間是自然經過空格分開的，但亞洲語言的中日韓文語句中的字是一個字挨一個，全部，首先要把語句中按「詞」進行索引的話，這個詞如何切分出來就是一個很大的問題。

首先，確定不能用單個字符做(si-gram)爲索引單元，不然查「上海」時，不能讓含有「海上」也匹配。但一句話：「北京天安門」，計算機如何按照中文的語言習慣進行切分呢？「北京 天安門」 仍是「北 京 天安門」？讓計算機可以按照語言習慣進行切分，每每須要機器有一個比較豐富的詞庫纔可以比較準確的識別出語句中的單詞。另一個解決的辦法是採用自動切分算法：將單詞按照2元語法(bigram)方式切分出來，好比："北京天安門" ==> "北京 京天 天安 安門"。這樣，在查詢的時候，不管是查詢"北京" 仍是查詢"天安門"，將查詢詞組按一樣的規則進行切分："北京"，"天安安門"，多個關鍵詞之間按與"and"的關係組合，一樣可以正確地映射到相應的索引中。這種方式對於其餘亞洲語言：韓文，日文都是通用的。

基於自動切分的最大優勢是沒有詞表維護成本，實現簡單，缺點是索引效率低，但對於中小型應用來講，基於2元語法的切分仍是夠用的。基於2元切分後的索引通常大小和源文件差很少，而對於英文，索引文件通常只有原文件的30%-40%不一樣，

	自動切分	詞表切分
實現	實現很是簡單	實現複雜
查詢	增長了查詢分析的複雜程度，	適於實現比較複雜的查詢語法規則
存儲效率	索引冗餘大，索引幾乎和原文同樣大	索引效率高，爲原文大小的30％左右
維護成本	無詞表維護成本	詞表維護成本很是高：中日韓等語言須要分別維護。 還須要包括詞頻統計等內容
適用領域	嵌入式系統：運行環境資源有限 分佈式系統：無詞表同步問題 多語言環境：無詞表維護成本	對查詢和存儲效率要求高的專業搜索引擎