Apache Lucene項(xiàng)目可能會(huì)在幾個(gè)月后發(fā)布其下一個(gè)主要版本7.0！

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

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

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

Doc值作為迭代器

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

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

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

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

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

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

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

再見索引時(shí)間的提升

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

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

查詢計(jì)分更簡單

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

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

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

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

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

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

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

更多東西

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

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

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

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

最后，維度點(diǎn)API 現(xiàn)在會(huì)預(yù)先獲取一個(gè)字段名稱，以提供按字段的點(diǎn)訪問 ，從而與doc值A(chǔ)PI的工作方式匹配。

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

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

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

總結(jié)

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

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