終于，在一系列強(qiáng)大的4.x功能（最近是4.10.2）發(fā)布之后，我們終于在努力開發(fā)另一個主要的Apache Lucene版本！

沒有確切時間的承諾（完成時就完成了！），但是我們已經(jīng)有一個自愿發(fā)布經(jīng)理 （謝謝您，Anshum！）。

Lucene的一個主要版本意味著所有不推薦使用的API（從4.10.x版本開始）都將被刪除，不再支持3.x索引，同時仍支持眾多4.x索引格式以實(shí)現(xiàn)向后兼容，并且4.10.x分支成為我們的僅修正錯誤的發(fā)行系列（無新功能，無API更改）。

5.0.0已經(jīng)包含了許多激動人心的更改，我將在下面進(jìn)行描述，并且隨著正在進(jìn)行的積極開發(fā)它們?nèi)栽诓粩喟l(fā)展。

增強(qiáng)索引安全性

5.0.0的許多更改都集中在提供更強(qiáng)大的保護(hù)以防止索引損壞。

所有的文件訪問現(xiàn)在使用 Java的API的NIO.2 ，給我們更好的錯誤處理（例如， Files.delete返回一個有意義的異常）與原子重命名沿更安全的提交 ，減少了猙獰的風(fēng)險“整個指數(shù)走了”之類的錯誤此doozie 。

Lucene的復(fù)制模塊以及在Lucene之上的分布式服務(wù)器（例如Elasticsearch或Solr ）必須將索引文件從一個位置復(fù)制到另一個位置。 他們這樣做是出于備份目的（例如， 快照和還原 ），從一個節(jié)點(diǎn)到另一個節(jié)點(diǎn)的遷移或恢復(fù)分片或添加新副本時的目的。 這樣的復(fù)制器會嘗試增量復(fù)制，因此，如果存在相同的文件名，且具有相同的長度和校驗和，則不會再次復(fù)制該文件。

不幸的是，這些層有時會有細(xì)微的錯誤（它們很復(fù)雜！）。 由于校驗和 （在4.8.0中添加），Lucene已經(jīng)檢測到復(fù)制器在復(fù)制時是否引起了任何位翻轉(zhuǎn)，這表明Elasticsearch使用的壓縮庫中存在一個長期存在的令人討厭的錯誤 。

在5.0.0版本中，我們可以更進(jìn)一步，現(xiàn)在通過為每個段和提交分配唯一的ID （ segments_N文件）來檢測整個文件是否復(fù)制到錯誤的文件名。 現(xiàn)在，每個索引文件都在其標(biāo)頭中記錄段ID ，然后在打開索引時對這些ID進(jìn)行交叉檢查。

新的Lucene50Codec還包括進(jìn)一步的索引損壞檢測。

甚至CorruptIndexException本身也得到了改進(jìn)！ 現(xiàn)在，它將始終引用檢測到損壞的文件或資源，因為現(xiàn)在這是其構(gòu)造函數(shù)的必需參數(shù)。 當(dāng)更高級別檢測到損壞（例如，字段信息文件中的字段編號錯誤）時，產(chǎn)生的CorruptIndexException現(xiàn)在將指出文件中是否還存在校驗和不匹配，從而有助于縮小損壞的可能來源。

最后，在合并期間， IndexWriter現(xiàn)在始終在合并之前檢查傳入的段是否損壞。 這可能意味著，升級到5.0.0后，合并可能會發(fā)現(xiàn)舊版4.x索引中長期存在的潛在損壞。

減少堆使用

5.0.0還包括一些更改，以減少索引和搜索期間的堆使用。

如果您的索引具有1B文檔，則在4.10.2緩存單個基于FixedBitSet的篩選器將花費(fèi)不小的125 MB堆空間！ 但是在5.0.0版本中，Lucene現(xiàn)在支持可隨機(jī)寫和可擴(kuò)展的稀疏位集（ RoaringDocIdSet和SparseFixedBitSet ），因此所需的堆與設(shè)置的位成比例，而不是索引中存在的文檔總數(shù)。 這些位集還大大簡化了MultiTermQuery的重寫方式（不再需要CONSTANT_SCORE_AUTO_REWRITE_METHOD ），并且它們提供了比FixedBitSet的線性掃描更快的高級實(shí)現(xiàn)。 最后，它們提供了更準(zhǔn)確的cost()實(shí)現(xiàn)，使Lucene可以更好地選擇在查詢時如何驅(qū)動交叉路口。

新的Lucene50Codec 合并 IndexWriter期間的堆使用量也要低得多 ，因為合并的段的doc值和規(guī)范不再完全加載到所有字段的堆中。 現(xiàn)在將它們加載到當(dāng)前正在合并的一個字段中，然后刪除。

現(xiàn)在，默認(rèn)的規(guī)范格式在適當(dāng)時使用稀疏編碼，因此為許多稀疏字段啟用規(guī)范的索引將在搜索時看到所需堆的大量減少。

解釋堆使用的API

如果仍然發(fā)現(xiàn)Lucene使用的堆多于預(yù)期，則5.0.0有一個新的API可打印樹結(jié)構(gòu) ，該結(jié)構(gòu)顯示遞歸分解哪些部分正在使用多少堆。 這類似于Lucene的explain API ，用于了解文檔為什么具有一定的相關(guān)性得分，但適用于堆使用。

它產(chǎn)生如下輸出：

_cz(5.0.0):C8330469: 28MB postings [...]: 5.2MB ... field 'latitude' [...]: 678.5KB term index [FST(nodes=6679, ...)]: 678.3KB

與查看凝視Java堆轉(zhuǎn)儲相比，這是查看堆中正在消耗什么的更快的方法。

進(jìn)一步的變化

附加的5.0.0更改很長； 這里是其中的一些：

• 舊的實(shí)驗性發(fā)帖格式（ Sep/Fixed/VariableIntPostingsFormat ）已刪除。 PulsingPostingsFormat也已刪除，因為默認(rèn)的發(fā)布格式已經(jīng)產(chǎn)生了唯一的條件。
• FieldCache走了（移動到專用UninvertingReader中misc模塊）。 這意味著當(dāng)您打算對字段進(jìn)行排序時，應(yīng)使用doc值對該字段建立索引，這比FieldCache快得多，堆消耗更少。
• Tokenizer和Analyzer 不再需要在初始狀態(tài)下使用Reader 。
• 現(xiàn)在， NormsFormat獲得了自己專用的NormsConsumer/Producer
• FieldInfo簡化（Lucene的“低模式”）：不再需要normType （它始終是DocValuesType.NUMERIC ），不再需要isIndexed （只需檢查IndexOptions ）
• 復(fù)合文件的處理更為簡單，現(xiàn)在處于編解碼器的控制之下。
• 用于對多值字段進(jìn)行排序的SortedSetSortField從沙箱提升為Lucene的核心
• PostingsFormat現(xiàn)在寫帖子的時候，就像DOC值使用“拉” API。 此功能非常強(qiáng)大，因為您可以采用發(fā)布格式進(jìn)行操作，這些操作需要對發(fā)布進(jìn)行一次以上的遍歷操作，例如遍歷每個術(shù)語的所有發(fā)布以決定應(yīng)使用哪種壓縮格式。
• 諸如IndexWriterConfig和分析組件之類的類的初始化不再需要版本。

我在這里描述的更改只是我們今天針對5.0.0版本進(jìn)行的排列的快照。 5.0.0仍在積極開發(fā)中（歡迎打補(bǔ)丁！），因此該列表將在實(shí)際發(fā)行完成時更改。

翻譯自: https://www.javacodegeeks.com/2014/11/apache-lucene-5-0-0-is-coming.html

總結(jié)

以上是生活随笔為你收集整理的Apache Lucene 5.0.0即将发布！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。