Lucene 4.0 正式版釋出，亮點特性中文解讀

　　2012年10月12日，Lucene 4.0正式釋出了（點選這裡下載最新版），這個版本因為諸多的新特性和大膽的架構調整一直備受期待。無論是索引結構，索引演算法以及整體架構的包容性都發生了翻天覆地的變化。正如大家一直所說的Lucene是一個搜尋工具包 ，而4.0的釋出則讓Lucene向搜尋框架的方向邁出了一大步。 下面我們來逐一解讀Lucene 4.0的新特性吧。

Lucene 4.0 的關鍵詞：

　　架構解耦，索引結構可定製化，索引結構透明化，向搜尋框架方向發展。

Lucene 4.0 正式版亮點功能：

　　一、通過解碼器Codec 機制 Lucene 索引格式與Lucene架構解耦，變成了Plugin方式實現，包括：Terms , Postings lists ,Stored 欄位,Term Vectors 等都可以以自定義的格式予以支援。

　　正如Mysql支援多種儲存引擎一樣，現在Lucene也可以了。

　　二、排序相關的演算法與向量空間模型解耦(即Lucene中經典的經典的(TF/IDF)模型)。同時提供：最佳匹配 Okapi BM 25，隨機分歧 (Divergence from Randomness )，語言模型和基於資訊量的模型。 不同的演算法模型可以組合串聯起來使用，這等於完全解放了Lucene的生產力！。

　　三、新的DocValues型別可以為每個文件提供儲存額外的型別資料。類似：PayLoad, 可以在用這個特性自定義排序打分引數。

　　四、IndexWriter 寫入索引到硬碟支援完全併發，之前IndexWriter在應用層能多執行緒呼叫，但在寫入硬碟的時候還是逐個執行緒順序寫入的。這對於經常要重建索引的場景，減少了等待索引的時間。

　　五、每個Document的標準化因子 norms 不再侷限於一個位元組。自定義排序的實現可以使用任何DocValues型別的排序因子。

　　六、索引結構更加透明化，增加了索引統計機制，利用這些統計資訊，Lucene索引內容不再是一個黑匣子了。

　　包括： 提供針對term或者Field的token數量，針對某個filed的Posting數量，包含某個field的positing的文件數量。當然有了這些索引統計的資料後，就可以自定義的改進評分機制了。

　　也就是說以下方法將會成為你的新朋友：

　　TermsEnum.docFreq()，TermsEnum.totalTermFreq()，Fields.getUniqueTermCount()，Fields.getUniqueFieldCount()

　　七、索引term不再侷限於UTF-16的字元格式，Lucene 4.0中 term 可以是任何二進位制數值(java中的byte陣列)。預設情況下文字類term是UTF-8位元組方式儲存。

　　八、在搜尋時使用Filter效率有大幅提升

　　九、針對索引merge執行緒新增了IO限速機制，減少搜尋執行緒與合併索引執行緒引起的IO爭用現象。

　　十、由於架構的解耦，增加了一系列可插拔和可替換的模組，包括： 

　　　　A: 新增編碼器codec：針對類 Hadoop DFS 的檔案系統提供。

　　　　B: 記憶體編碼器codec：把所有的term和posting放到一個記憶體中的FST（有限狀態機），針對記憶體型應用提升了搜尋速度。

　　　　C: 脈衝編碼器codec:主要利用了 Zipf 定律，根據term的頻率，把頻率達到制定閾值的term以inline的方式儲存。

　　　　瞭解c++ inline 函式的同學，應該知道inline對於提升函式呼叫速度的威力吧。

　　　　D: 明文編碼器codec: Lucene的索引結構為了提升效率，從來都是一個黑匣子。現在這個黑匣子可以以明文的方式儲存了。

　　　　很顯然這個編碼器主要是除錯、演示用的。估計很多需要寫論文的同學們很樂意使用這個功能。

　　　　E: Bloom編碼器codec: 國內很多人把Bloom翻譯為布隆，我還是喜歡直接用英文的Bloom。

　　　　關於什麼是Bloom 參考文章：http://blog.csdn.net/accesine960/article/details/1491483

　　　　F：直接編碼器 codec : 由這個名字可以看到，這個編碼器是為提升效率用的，主要針對高記憶體需求類的場景定製的。

　　　　G: 塊解碼器 codec:  使用了一個新的索引結構和壓縮模式schema。

　　十一、Term 偏移量可以選擇與Postings list儲存在一起。

　　十二、新增AutomatonQuery ，用來返回所有Term匹配有限狀態機文章列表

　　十三、FuzzyQuery 查詢速度提升了100-200倍。

　　十四、新增拼寫檢查器DirectSpellChecker，新的拼寫檢查器不需要單獨的索引，能夠直接使用主索引。

　　十五、 執行中的記憶體資料結構優化，包括：term 目錄，FiledCache 等。

　　以：500萬wekipedia資料為例 3.x 索引時需要600M記憶體，4.x 索引時需要 200M記憶體。

　　十六、所有的搜尋邏輯現在針對每個segment上工作。IndexReaer 也被完全重構，變成了：Atomic 和 Composite Reader。

　　這個變化比較大，我們知道Lucene在生成索引的時候會先生成小的Segment然後逐漸合併成大的Segment。Lucene的所有結構和元件都是以多個Segment為導向進行設計架構的。為搜尋多個Segment需要MultiReader，而多Reader的會導致在搜尋TermEnum 或者 Postings 的時候搜尋效率的下降。因此新的Reader去掉了MultiReader，以Atomic和Composite Reader 代替。

　　十七、Lucene 4.0 提供了模組化的API。 以模組化的方式提供了 非結構化資訊管理分析器 和 空間資訊搜尋模組。