lucene使用3.0.3

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

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

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

5.0.0已經包含了許多激動人心的更改，我將在下面進行描述，并且隨著正在進行的積極開發它們仍在不斷發展。

增強索引安全性

5.0.0的許多更改都集中在提供更強大的保護以防止索引損壞。

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

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

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

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

新的Lucene50Codec還包括進一步的索引損壞檢測。

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

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

減少堆使用

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

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

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

現在，默認的規范格式在適當時使用稀疏編碼，因此為許多稀疏字段啟用規范的索引將在搜索時看到所需堆的大量減少。

解釋堆使用的API

如果仍然發現Lucene使用的堆多于預期，則5.0.0有一個新的API可以打印樹結構 ，該結構顯示遞歸分解哪些部分正在使用多少堆。 這類似于Lucene的explain API ，該API用于了解文檔為什么具有一定的相關性評分，而是應用于堆用法。

它產生如下輸出：

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

與試圖凝視Java堆轉儲相比，這是一種查看堆中正在消耗完什么的更快的方法。

進一步的變化

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

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

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

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

lucene使用3.0.3

總結

以上是生活随笔為你收集整理的lucene使用3.0.3_Apache Lucene 5.0.0即将发布！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。