apache lucene

無可估量的高貴的Apache軟件基金會（Apache Software Foundation）產生了許多巨大的產品（Ant，CouchDB，Hadoop，JMeter，Maven，OpenOffice，Subversion等），這些產品有助于構建我們的數字世界。 Lucene也許是一個鮮為人知的瑰寶，“……提供基于Java的索引和搜索技術，以及拼寫檢查，命中突出顯示和高級分析/令牌化功能。” 盡管從標題上避開了，Lucene還是許多Apache（和第三方）項目中一個安靜但不可或缺的組成部分。

讓我們看一下這個出色而成功的產品的基礎結構。

在開始之前，請先進行以下四個警告。

作為一種語法結構分析，此評論對程序語義或無論多么精致的交付用戶體驗都不在乎 。

結構本身值得進行調查，因為它支配著變更潛在成本的可預測性。 結構不良的系統表現出過度的互連性，其中的連鎖React會嚴重影響更改成本估算的準確性。 結構良好的系統維護和升級的費用不一定便宜，但是通常它們帶來的麻煩更少。

該分析將包裝結構描繪為斯波克林圖 ，其中圓圈表示包裝，直線表示從上方繪制的包裝到下方繪制的包裝的依賴性，而曲線表示從下方繪制的包裝到上方繪制的包裝的依賴性。 。 程序包的顏色表示它所參與的可傳遞程序包依賴關系的相對數量：越紅，可傳遞程序依賴關系越多。

沒有圖可以證明結構價值或成本。 高級分析僅在提示問題的答案被埋在代碼的地質層之下時才會進行。

因此，為了生意……

崛起 …

圖1：Lucene 1.4.3版的程序包結構。

圖1顯示了仍歸檔的Lucene的最早版本之一，版本1.4.3。 回想一下，簡單的結構測試表明隨機選擇了一個程序包，并詢問：“如果該程序包發生更改，它最有可能影響其他哪些程序包？”

以索引為例。 很明顯的QueryParser和跨度都依賴于它，因此可以通過任何變化指標受到影響，而曲線顯示， 搜索就靠它呢。 這種容易的依賴關系識別是整個圖形的特征??，使其結構合理。

布拉沃（Bravo），露西娜（Lucene），您的開局很好。

圖2：Lucene 2.0版的程序包結構。

圖2顯示了2.0版（請注意，我們不會研究每個發行版，而是在整個發行路徑上均勻地布置里程碑），并且互連的簡單性仍在繼續。 盡管方法的數量從1.4.3的1,637版增加到2.0的2,085版，但程序包的數量卻從11個減少到10個。這促使有效耦合效率從41％降至37％略有下降，但是好的設計原則顯然可以精通此系統。

圖3：Lucene 2.4版的軟件包結構。

上面的圖3中呈現的2.4版本雖然遠沒有明顯的不良結構，但卻顯示出困擾的最初跡象。

的確，許多包裹與鄰居之間有著明顯的聯系。 但是現在有些沒有。 特別是搜索和索引似乎已經陷入彼此的事務中。

但是，這種結構的輕微退化掩蓋了幕后發生的動蕩變化。 在2.0版有2,085個方法的地方，2.4版的大小增加了一倍多，達到4,176個方法。 在版本2.0僅具有9,767個傳遞依賴項的情況下，版本2.4在繁重的48,370個傳遞依賴項之下下垂。 正如我們將看到的那樣，一些結構性的裂縫已經在方法級別上深層拉開，以觸發依賴關系的五倍增長，這是Lucene的程序員從未發現或密封的裂縫，并且困擾著后來的修訂版。

不僅依賴關系的數量急劇增加，而且程序的深度（其傳遞依賴關系的平均長度）也有所增加，從2.0版的7升級到2.4版的8.6，不僅為漣漪效應可能會撲朔迷離，但將這些音軌延伸到更遠的地方以分流虛假的沖擊。

盡管如此，這種結構仍然沒有解決任何問題。 專注于設計可以恢復早期版本所具有的簡單性。

圖4：Lucene 3.0版的程序包結構。

las，版本3.0（如上圖4所示）似乎仍在繼續呈下降趨勢。 再次，圖4并沒有呈現出一種不可挽回的結構：我們可以通過拆開包裝來了解它們之間如何相互連接。 但是，這項任務變得更加困難。

分析和跨度都被搜索和索引所吸引。 預測更改這四個軟件包中任何一個的影響現在似乎需要對所有其他軟件包進行自動調查。

為增加互連性做出的貢獻是在此修訂版中增加了800種方法。 即使傳遞依存關系的數量已下降到46,917，但平均長度卻再次增加，這次是9.3。

系統的結構是否超出了希望？ 一點也不：許多軟件包與同事之間都享有明確的依賴關系。 然而，即將到來的是版本3.5和大量傳遞依賴，盡管不是立即致命，但證明對所有藥物都具有抗藥性。

還有秋天……

圖5：Lucene 3.5版的程序包結構。

令人欣慰的是，如上圖5所示，版本3.5引入了額外的三個軟件包（總數達到18個），以嘗試分發和分離系統的功能。 慷慨的還可能會提出，盡管軟件包的結構已從上一版明顯地再次衰減了，但這種衰減仍然在一定程度上是局部的：壞男孩分析 ， 跨度 ， 搜索和索引繼續使Lucene鎮表現良好的其他人群感到恐懼。

但是慷慨到此為止。

盡管僅增加了1800種方法，修訂版3.5的傳遞依賴項數量卻猛增到109,357，這些依賴項的平均長度達到11種方法，這是整個演進過程中最大的遺憾。 鑒于結構復雜性的這種顯著上升，我們想知道包裝設計的效果如何–確實如此和諧無濟于事，因為應變最終破壞了下一個修訂里程碑中的所有控制外觀。

圖5：Lucene 4.0版的程序包結構。

如圖5所示，修訂版4.0在先前的修訂版中增加了1600種方法，使總數達到8,474，并且傳遞依賴項的數量相對適度地增加到116,211，但是從圖中可以看出，發生了一些可怕的事情。

先前版本的Swift發展的互連性突然系統化，導致該結構內陷到可怕的纏結的球狀關系中，這使代碼影響預測極為不可靠。

的確，此修訂版增加了另外兩個軟件包–將潛在的耦合效率提高到43％–并將（輕微）傳遞依賴項長度減少到10.4，但是控制如此大量的傳遞依賴項的巨大努力只是破壞了系統。 它不會恢復。

圖6：Lucene 4.5版的軟件包結構。

在圖6所示的修訂版4.5中，一些英勇的行動將傳遞依賴的數量減少到106,242，同時仍將方法的數量增加到9,562，也許某些軟件包設法使自己遠離系統上狂躁的黑洞。核心。 但是工作太少了，太遲了。

圖7：Lucene 5.0版的軟件包結構。

如圖7所示，修訂版5.0嘗試通過刪除200種方法來馴服野獸，但這奇怪地導致可傳遞依賴項的數量再次增加到113,556。

版本5.0看起來和版本4.5一樣糟糕嗎？ 好吧，也許不是。 看起來有點干凈。 但是，我們不應該讓這種情況使我們對圖7所示的巨大混亂視而不見：該系統痛苦不堪。 預測更改任何這些中央軟件包的成本已經變得很困難。

為什么？

要了解破壞系統初始結構完整性的原因，我們必須檢查3.5版。 再說一次，這看起來好像不是最糟糕的結構，但是這次修訂預示了最終導致破產的變化。

主要的變化不僅是規模上的變化：更大的系統不一定會陷入結構不良的境地。 修訂版3.5將方法數量增加了35％，但修訂版2.4將方法數量增加了100％以上，而不會破壞整個組織。

相反，罪魁禍首是傳遞依賴的數量及其在系統中的分布。

修訂版3.5中引入的新的傳遞依賴項數量驚人，從46,917增至109,357。 這使依賴方法比達到了動脈硬化16。

圖8：比較Lucene的方法傳遞依存關系比率。

依賴于方法的比率已經太高了。 但是，在以前的版本中，這些可傳遞依賴項在很大程度上只限于一個或兩個程序包。 在版本3.0中，所有可傳遞方法依賴項的95％終止于其原始包或僅在一個依賴項中的包中終止。 這給了希望，從某種意義上講，變更可能會將自己限制在接近原點的區域，而很少有變更能夠溢出到整個系統中，并且無法進行成本預測。

但是，修訂版3.5看到該數字暴跌至75％。 這意味著所有修訂版3.5的傳遞依賴項中有25％溢出到三個或更多程序包中。 結合這兩個因素，我們發現有33,000多個依賴項需要等待遠遠超出其起源的彈射變化。 最重要的是，這注定了產品會進一步結構衰減。

圖9：Lucene傳遞依賴項的百分比，少于3個包。

然后，這結束了對Lucene包級別結構的檢查。 我們是否應該深入研究套餐級別？ 我們是否應該梳理各個軟件包以檢查各種類別的星座？ 不行 。根據Blighttown的推論 ，如果包裝級別的結構不好，我們不希望在下面找到鉆石。 所以我們不會。

最終成績

讓我們嘗試對Lucene的結構進行客觀評分（其最終修訂版本此處為5.0）。

我們將使用四個因素的平均值。 第一個度量Lucene試圖限制可能形成的依賴關系數量的嘗試。 第二和第三次嘗試捕獲傳遞依賴項的長度，第四次嘗試捕獲傳遞依賴項的數量。 當然，大型系統總會比小型系統具有更多的依賴關系，因此我們不能僅僅因為系統A的依賴關系少就說系統A的結構比系統B更合理。 取而代之的是，我們必須通過標準化大小或使測量在某種意義上具有自參考性來得出可以公平比較的測量。

首先，我們將測量其絕對理想效率：這將分析結構的潛在耦合 ，并基本詢問封裝了多少種方法而不使用其他方法，因此可以想象會創建多少依賴關系。 如果將每種方法都放在一個類中，那么每種方法對彼此都是可見的，因此效率為0％。 隨著方法的私有化并把它們放在單獨的包私有類中，這種方法的價值不斷提高，從而使方法之間的封裝越來越多。

Lucene得分為44％，表明它至少已嘗試封裝其功能，但還有更多工作要做。

其次，我們將以一種允許程序之間公平比較的形式來衡量Lucene的傳遞依賴項的長度。 為此，我們將使用CDF圖來顯示Lucene的傳遞方法依賴項占其最長傳遞依賴關系的百分比。

圖10：Lucene的傳遞依賴CDF。

在上面的圖10中，我們看到Lucene的傳遞依存關系的一半短于最長的傳遞依存關系的長度的45％。 這不好。 系統對紋波效應的抵抗力取決于其大部分依賴關系是否短暫。 例如， JUnit的傳遞依賴的一半僅占其最長依賴關系長度的30％。

當我們需要一個具有改進結構的數字時，我們將使用100減去該數字，因此Lucene的得分為100 – 45 = 55，該值應接近70。

我們將要討論的第三個因素是：跨越兩個或更少程序包的方法所占的百分比，這個數字為75.5％。 聽起來不錯，但是使用現代結構技術 ，幾乎沒有理由將該值小于90％。

最后，我們需要一個因素來衡量系統中有多少依賴項，因為依賴項的數量越少越好。 為了規范化大小，我們想測量每個方法的方法相關性數量。 不幸的是，在這里我們必須估算出行業最低的分數。 一些研究表明25似乎是一個合適的數字：如果系統每個方法包含25個以上的依賴項，則該系統的結構是如此糟糕，以至于所有其他所有其他指標都失去了重要性。

前面我們看到，Lucene每個方法有12個巨大的依賴關系； 因此我們將使用的數字為25-12 = 13，以25的百分比表示，得出52％。 如圖8所示，其他系統的每種方法的依賴關系低至6，這個指標的收益率超過70％。

這使得Lucene的最終得分為226.5 / 400分，即57％。 根據牢固的結構原理，現代程序的分數很容易超過80％，所以這是一個很差的分數，表示，這是一個糟糕的結構。 Lucene在本系列到目前為止所分析的系統的排行榜中排名倒數第二。

因子	得分
絕對勢偶效率％	44
100 –（最長依賴關系長度的一半，即一半系統短于該長度）	55
方法傳遞相關性百分比，范圍不超過2個軟件包	75.5
（（25-（每個方法的傳遞方法依賴項數）/ 25），以25的百分比表示	52
平均	57％

表1：Lucene 5.0的結構評估。

摘要

程序	結構得分
Spoiklin Soice	84％
JUnit的	67％
Struts	67％
FitNesse	62％
彈簧	60％
Lucene	57％
螞蟻	24％

表2：Lucene在排行榜上的位置。

可以做的更好。

翻譯自: https://www.javacodegeeks.com/2015/05/the-structure-of-apache-lucene.html

apache lucene

總結

以上是生活随笔為你收集整理的apache lucene_Apache Lucene的结构的全部內容，希望文章能夠幫你解決所遇到的問題。

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