Apache Lucene 4.0 發布亮點介紹

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也可以了。

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

     * 新的DocValues類型可以為每個文檔提供額外的類型數據。類似：PayLoad, 可以在用這個特性自定義打分因子。

     * IndexWriter 寫入索引到硬盤支持完全并發，之前IndexWriter在應用層能多線程調用，但在寫入硬盤的時候不是同步的。這對于經常要重建索引的場景，減少了等待索引的時間。

     * 每個Document的標準化因子 norms 不再局限于一個字節。自定義排序的實現可以使用任何DocValues類型的排序因子。

     * 索引結構更加透明化，增加了索引統計機制，包括： 提供針對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。

       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。 以模塊化的方式提供了 非結構化信息管理分析器 和 空間信息搜索模塊。

來自：http://blog.csdn.net/accesine960/article/details/8066877