翻譯:如何提高和最佳化Lucene索引速度

來源:互聯網
上載者:User

這篇文章主要介紹了如何提高Lucene的索引速度。介紹的大部分思路都是很容易嘗試的,當然另外一部分可能會加大你程式的複雜度。所以請確認索引速度確實很慢,而且很慢的原因確實是因為Lucene自身而造成的。推薦姐妹篇:如何提高和最佳化Lucene搜尋速度

• 確認你在使用最新的Lucene版本。

• 盡量使用本地檔案系統

遠程檔案系統一般來說都會降低索引速度。如果索引必須分布在遠程伺服器,請嘗試先在本地產生索引,然後分發到遠程伺服器上。

• 使用更快的硬體裝置,特別是更快的IO裝置

• 在索引期間複用單一的IndexWriter執行個體

• 使用按照記憶體消耗Flush代替根據文檔數量Flush

在Lucene 2.2之前的版本,可以在每次添加文檔後調用ramSizeInBytes方法,當索引消耗過多的記憶體時,然後在調用flush()方法。這樣做在索引大量小文檔或者文檔大小不定的情況下尤為有效。你必須先把maxBufferedDocs參數設定足夠大,以防止writer基於文檔數量flush。但是注意,別把這個值設定的太大,否則你將遭遇Lucene-845號BUG。不過這個BUG已經在2.3版本中得到解決。

在Lucene2.3之後的版本。IndexWriter可以自動的根據記憶體消耗調用flush()。你可以通過writer.setRAMBufferSizeMB()來設定緩衝大小。當你打算按照記憶體大小flush後,確保沒有在別的地方設定MaxBufferedDocs值。否則flush條件將變的不確定(誰先符合條件就按照誰)。

• 在你能承受的範圍內使用更多的記憶體

在flush前使用更多的記憶體意味著Lucene將在索引時產生更大的segment,也意味著合并次數也隨之減少。在Lucene-843中測試,大概48MB記憶體可能是一個比較合適的值。但是,你的程式可能會是另外一個值。這跟不同的機器也有一定的關係,請自己多加測試,選擇一個權衡值。

• 關閉複合檔案格式

調用setUseCompoundFile(false)可以關閉複合檔案選項。產生複合檔案將消耗更多的時間(經過Lucene-888測試,大概會增加7%-33%的時間)。但是請注意,這樣做將大大的增加搜尋和索引使用的檔案控制代碼的數量。如果合并因子也很大的話,你可能會出現用光檔案控制代碼的情況。

• 重用Document和Field執行個體

在lucene 2.3中,新增了一個叫setValue的方法,可以允許你改變欄位的值。這樣的好處是你可以在整個索引進程中複用一個Filed執行個體。這將極大的減少GC負擔。

最好建立一個單一的Document執行個體,然後添加你想要的欄位到文檔中。同時複用添加到文檔的Field執行個體,通用調用相應的SetValue方法改變相應的欄位的值。然後重新將Document添加到索引中。

注意:你不能在一個文檔中多個欄位共用一個Field執行個體,在文檔添加到索引之前,Field的值都不應該改變。也就是說如果你有3個欄位,你必須建立3個Field執行個體,然後再之後的Document添加過程中複用它們。

• 在你的分析器Analyzer中使用一個單一的Token執行個體

在分析器中共用一個單一的token執行個體也將緩解GC的壓力。

• 在Token中使用char[]介面來代替String介面來表示資料

在Lucene 2.3中,Token可以使用char數組來表示他的資料。這樣可以避免構建字串以及GC回收字串的消耗。通過配合使用單一Token執行個體和使用char[]介面你可以避免建立新的對象。

• 設定autoCommit為false

在Lucene 2.3中對擁有儲存欄位和Term向量的文檔進行了大量的最佳化,以節省大索引合并的時間。你可以將單一複用的IndexWriter執行個體的autoCommit設定為false來見證這些最佳化帶來的好處。注意這樣做將導致searcher在IndexWriter關閉之前不會看到任何索引的更新。如果你認為這個對你很重要,你可以繼續將autoCommit設定為true,或者周期性的開啟和關閉你的writer。

• 如果你要索引很多小文字欄位,如果沒有特別需求,建議你將這些小文字欄位合并為一個大的contents欄位,然後只索引contents。(當然你也可以繼續儲存那些欄位)

• 加大mergeFactor合并因子,但不是越大越好

大的合并因子將延遲segment的合并時間,這樣做可以提高索引速度,因為合并是索引很耗時的一個部分。但是,這樣做將降低你的搜尋速度。同時,你有可能會用光你的檔案控制代碼如果你把合并因子設定的太大。值太大了設定可能降低索引速度,因為這意味著將同時合并更多的segment,將大大的增加硬碟的負擔。

• 關閉所有你實際上沒有使用的功能

如果你儲存了欄位,但是在查詢時根本沒有用到它們,那麼別儲存它們。同樣Term向量也是如此。如果你索引很多的欄位,關閉這些欄位的不必要的特性將對索引速度提升產生很大的協助。

• 使用一個更快的分析器

有時間分析文檔將消耗很長的時間。舉例來說,StandardAnalyzer就比較耗時,尤其在Lucene 2.3版本之前。你可以嘗試使用一個更簡單更快但是符合你需求的分析器。

• 加速文檔的構建時間

在通常的情況下,文檔的資料來源可能是外部(比如資料庫,檔案系統,蜘蛛從網站上的抓取等),這些通常都比較耗時,盡量最佳化擷取它們的效能。

• 在你真的需要之前不要隨意的最佳化optimize索引(只有在需要更快的搜尋速度的時候)

• 在多線程中共用一個IndexWriter

最新的硬體都是適合高並發的(多核CPU,多通道記憶體構架等),所以使用多線程添加文檔將會帶來不小的效能提升。就算是一台很老的機器,並發添加文檔都將更好的利用IO和CPU。多測試並發的線程數目,獲得一個臨界最優值。

• 將文檔分組在不同的機器上索引然後再合并

如果你有大量的文字文件需要索引,你可以把你的文檔分為若干組,在若干台機器上分別索引不同的組,然後利用writer.addIndexesNoOptimize來將它們合并到最終的一個索引檔案中。

• 運行效能測試程式

如果以上的建議都沒有發生效果。建議你運行下效能檢測程式。找出你的程式中哪個部分比較耗時。這通常會給你想不到的驚喜。

本翻譯屬於原創,轉載時請註明出處,英文原版請查看:

http://wiki.apache.org/jakarta-lucene/ImproveIndexingSpeed

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.