Apache Lucene項目可能會在幾個月后發(fā)布其下一個主要版本7.0！

請記住，Lucene開發(fā)人員通常會努力為下一個非主要（功能）發(fā)行版移植新功能，而即將發(fā)布的6.5已經(jīng)有了很多重大更改 ，因此新的主要發(fā)行版令人興奮，因為這意味著僅7.0的功能，我我們現(xiàn)在描述的是那些我們認為無法在6.5下移植的特別大的變量。

當然，在每個主要版本中，我們還會做更多平凡的事情，例如刪除不推薦使用的6.x API，并放棄對舊索引的支持（??使用Lucene 5.x或更早版本編寫）。

這只是7.0新功能的一部分。 有關完整列表的信息， 請參見后面的CHANGES.txt的7.0.0部分 。

Doc值作為迭代器

7.0中最大的變化是將文檔值從隨機訪問API更改為限制性更強的迭代器API 。

Doc值是Lucene在所有文檔中按列跨步的數(shù)字，按文檔排序或二進制的字段存儲。 它們可用于保存評分信號，例如單字節(jié)（默認情況下）文檔長度編碼或與應用程序相關的信號，或用于排序，構面或分組，甚至是一些查詢中可能用于范圍過濾的數(shù)字字段。 他們的列跨步存儲意味著跨文檔訪問一個字段的所有值是有效的，而行跨步存儲用于存儲單個字段的所有字段值。

長期以來，帖子是通過迭代器消耗的，因此，這是相對自然的更改，并且兩者共享相同的基類，
DocIdSetIterator ，以單步執(zhí)行或搜索每次DocIdSetIterator 。

最初死記硬背地切換到迭代器API的過程實際上只是一次管道交換，并且比隨后的所有對用戶有影響的改進（由于限制性更強的API）而引起的興趣要小：

• 7.0編解碼器現(xiàn)在可以稀疏地編碼稀疏的doc值和長度歸一化因子（“范數(shù)”）
• 離群值不再占用過多空間
• 我們基于文檔值的查詢利用了新的API
• 現(xiàn)在，在稀疏情況下， 頂級的僅瀏覽的構面計數(shù)和查詢中命中的構面計數(shù)都更快
• 新的advanceExact方法可實現(xiàn)更有效的跳過

通過這些更改，您最終只需為您實際使用的文檔值付費，包括索引大小，索引性能等。這與索引的其他部分（如發(fā)布，存儲的字段，術語向量等）相同，并且意味著具有稀疏doc值的用戶不再會花費不合理的時間進行合并或合并時索引異常龐大 。

我們基于NYC Trip Data語料庫的 夜間稀疏基準測試表明，上述每項更改（以及更多！）都取得了令人印象深刻的收益。

再見索引時間的提升

現(xiàn)在已棄用了索引時間提升功能，它使您可以提高特定文檔相對于其他文檔的先驗得分，該功能已在7.0版中刪除 。

這一直是一個脆弱的功能：它與字段的長度一起被編碼為一個字節(jié)值，因此精度很低。 此外，現(xiàn)在可以直接將自定義增強功能寫入自己的doc值字段，并使用函數(shù)查詢在搜索時應用增強功能。 最后，隨著索引時間的增加， 長度編碼更加精確 ，尤其是前九個長度值（1到9）是不同的。

查詢計分更簡單

BooleanQuery長期以來一直暴露一種令人困惑的評分功能，稱為協(xié)調因子 （ coord ），以獎勵包含更高百分比的搜索字詞的匹配。 但是，只有在對TF / IDF之類的術語具有“弱”飽和度的評分模型時，才需要使用此技巧，以使文檔中單個術語的多次出現(xiàn)比從查詢中添加另一個術語的一次出現(xiàn)更為強大。 由于這是特定于一個評分模型TFIDFSimilarity ，并且由于Lucene現(xiàn)在默認已切換到更好的Okapi BM25評分模型，因此我們現(xiàn)在已從 BooleanQuery和Similarity 完全刪除了7.0中的協(xié)調因子 。

同樣，評分的查詢規(guī)范化階段將被刪除 。 此階段嘗試使不同查詢和索引之間的得分均等，以使它們具有更高的可比性，但未更改命中的排序順序，并且也是TF / IDF特有的。

通過這些評分簡化， 當相同的子條款出現(xiàn)不同的Occur約束時 ， BooleanQuery現(xiàn)在可以進行更具進取性的查詢優(yōu)化，這以前是不可能的，因為分數(shù)會發(fā)生變化。

經(jīng)典查詢解析器不再在空白處拆分

Lucene原來的查詢解析器現(xiàn)在稱為“經(jīng)典”，始終將傳入的查詢文本預分割為空白，然后將這些單個標記分別發(fā)送給查詢時間分析器。 這意味著多令牌過濾器（例如SynonymGraphFilter或ShingleFilter ）將不起作用。

例如，如果用戶要求“拒絕服務攻擊”，而您將同義詞“拒絕服務”映射到DOS，則經(jīng)典查詢解析器將分別分析“拒絕”，“ of”和“服務”，因此您的同義詞將永不匹配。

我們已經(jīng)在查詢解析器中添加了一個選項，該選項不對空格進行預分割，但對于6.x版本保留默認值，以保持向后兼容性。 最后，在7.0版中， 我們修復了該默認設置，以便分析人員可以一次看到多個令牌，并且同義詞將起作用。

更多東西

從7.0開始，Lucene將（最終！） 記錄到索引元數(shù)據(jù)中，Lucene版本最初是使用該版本創(chuàng)建它的 。 這些知識可以幫助我們實現(xiàn)將來的向后兼容性。

有限狀態(tài)轉換器在Lucene中以多種方式使用，曾經(jīng)有一個復雜的方法調用pack ，它會占用更多字節(jié)，以進一步縮小FST的體積。 但是代碼很復雜，很少使用，有時甚至使FST更大，因此我們在7.0中將其刪除 。

用于在索引中添加，更新和刪除文檔的IndexWriter 將不再接受有時由錯誤的令牌過濾器產(chǎn)生的損壞的令牌偏移 。 偏移量用于突出顯示，而斷開的偏移量（單個標記的結束偏移量在開始偏移量之前，或者令牌的起始偏移量相對于先前的標記向后偏移）只能破壞搜索時突出顯示。 因此，通過此更改，Lucene通過拋出異常來防止在索引時發(fā)生此類錯誤。 為了在用戶甚至不知道其分析儀產(chǎn)生損壞的偏移量的情況下簡化此過渡，我們還添加了一些令牌過濾器來“校正”偏移量，然后再將其傳遞給
IndexWriter 。

Lucene的高級用戶經(jīng)常需要在搜索時為每個段緩存一些自定義的內容，但是用于此目的的API過于龐大，并且可能導致意外的內存泄漏，因此我們已對這些API進行了大修，以減少意外濫用的機會 。

最后，維度點API 現(xiàn)在會預先獲取一個字段名稱，以提供按字段的點訪問 ，從而與doc值API的工作方式匹配。

Lucene的7.0還沒有被釋放，所以如果你有任何額外的主要釋放值得改變想法，你想探索請伸手 ！

[我在亞馬遜工作，并且本網(wǎng)站上的帖子屬于我自己，不一定代表亞馬遜的職位]

翻譯自: https://www.javacodegeeks.com/2017/03/apache-lucene-7-0-coming-soon.html

總結

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

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