lucene索引優(yōu)化

1、這篇文章主要介紹了如何提高 Lucene 的索引速度。介紹的大部分思路都是很容易嘗試的，當(dāng)然另外一部分可能會加大你程序的復(fù)雜度。所以請確認索引速度確實很慢，而且很慢的原因確實是因為 Lucene自身而造成的。 推薦姐妹篇： 皿提高和優(yōu)化 Lucene搜索速度?確認你在使用最新的 Lucene 版本。?盡量使用本地文件系統(tǒng)遠程文件系統(tǒng)一般來說都會降低索引速度。 如果索引必須分布在遠程服務(wù)器，請嘗試先在本地生成索引，然后分發(fā)到遠程服務(wù)器上。?使用更快的硬件設(shè)備，特別是更快的 IO 設(shè)備?在索引期間復(fù)用單一的IndexWhter實例?使用按照內(nèi)存消耗Flush代替根據(jù)文檔數(shù)量Flush在 Lucen

2、e2.2 之前的版本，可以在每次添加文檔后調(diào)用 ramSizelnBytes 方法,當(dāng)索引消耗過多的內(nèi)存時，然后在調(diào)用 flush()方法。這樣做在索引大量小文檔或者文檔大小不定的情況下尤為有效。你必須先把 maxBufferedDocs 參數(shù)設(shè)置足夠大，以防止 writer 基于文檔數(shù)量 flush。但是注意，別把這個值設(shè)置的太大，否則你將遭遇Lucene-845 號 BUG 不過這個 BUCE 經(jīng)在 2.3 版本中得到解決。在 Lucene2.3 之后的版本。 IndexWriter 可以自動的根據(jù)內(nèi)存消耗調(diào)用 flush()。你可以通過 writer.setRAMBufferSizeMB

3、()來設(shè)置緩存大小。 當(dāng)你打算按照內(nèi)存大小 flush 后，確保沒有在別的地方設(shè)置 MaxBufferedDocs 值。 否則 flush 條件將變的不確定(誰先符合條件就按照誰)。?在你能承受的范圍內(nèi)使用更多的內(nèi)存在 flush 前使用更多的內(nèi)存意味著 Lucene 將在索引時生成更大的 segment,也意味著合并次數(shù)也隨之減少。在 Lucene-843 中測試，大概 48M 時存可能是一個比較合適的值。但是，你的程序可能會是另外一個值。這跟不同的機器也有一定的關(guān)系，請自己多加測試，選擇一個權(quán)衡值。?關(guān)閉復(fù)合文件格式調(diào)用 setUseCompoundFile(false)可以關(guān)閉復(fù)合文件選

4、項。 生成復(fù)合文件將消耗更多的時間(經(jīng)過 Lucene-888 測試，大概會增加 7%-33%勺時間)。但是請注意,這樣做將大大的增加搜索和索引使用的文件句柄的數(shù)量。如果合并因子也很大的話，你可能會出現(xiàn)用光文件句柄的情況。重用 Document 和 Field 實例在 lucene2.3 中，新增了一個叫 setValue 的方法，可以允許你改變字段的值。這樣的好處是你可以在整個索引進程中復(fù)用一個 Filed 實例。這將極大的減少 GC 負擔(dān)。最好創(chuàng)建一個單一的 Document 實例，然后添加你想要的字段到文檔中。同時復(fù)用添加到文檔的 Field 實例，通用調(diào)用相應(yīng)的 SetValue 方法

5、改變相應(yīng)的字段的值。然后重新將 Document 添加到索引中。注意：你不能在一個文檔中多個字段共用一個 Field 實例，在文檔添加到索引之前，F(xiàn)ield 的值都不應(yīng)該改變。也就是說如果你有 3 個字段，你必須創(chuàng)建 3 個 Field 實例，然后再之后的 Document 添加過程中復(fù)用它們。?在你的分析器 Analyzer 中使用一個單一的 Token 實例在分析器中共享一個單一的 token 實例也將緩解 GC 的壓力。?在 Token 中使用 char 口接口來代替 String 接口來表示數(shù)據(jù)在 Lucene2.3 中，Token 可以使用 char 數(shù)組來表示他的數(shù)據(jù)。這樣可以避免

6、構(gòu)建字符串以及 GC 回收字符串的消耗。通過配合使用單一 Token 實例和使用char 口接口你可以避免創(chuàng)建新的對象。?設(shè)置 autoCommit 為 false在 Lucene2.3 中對擁有存儲字段和 Term 向量的文檔進行了大量的優(yōu)化，以節(jié)省大索引合并的時間。你可以將單一復(fù)用的 IndexWriter 實例的 autoCommit 設(shè)置為 false 來見證這些優(yōu)化帶來的好處。注意這樣做將導(dǎo)致 searcher 在IndexWriter 關(guān)閉之前不會看到任何索引的更新。如果你認為這個對你很重要，你可以繼續(xù)將 autoCommit 設(shè)置為 true,或者周期性的打開和關(guān)閉你的 writ

7、er。?如果你要索引很多小文本字段，如果沒有特別需求，建議你將這些小文本字段合并為一個大的 contents 字段，然后只索引 contents。（當(dāng)然你也可以繼續(xù)存儲那些字段）?加大 mergeFactor 合并因子，但不是越大越好大的合并因子將延遲 segment 的合并時間，這樣做可以提高索引速度，因為合并是索引很耗時的一個部分。但是，這樣做將降低你的搜索速度。同時，你有可能會用光你的文件句柄如果你把合并因子設(shè)置的太大。值太大了設(shè)置可能降低索引速度，因為這意味著將同時合并更多的 segment,將大大的增加硬盤的負擔(dān)。?關(guān)閉所有你實際上沒有使用的功能如果你存儲了字段，但是在查詢時根本沒有

8、用到它們，那么別存儲它們。同樣 Term向量也是如此。如果你索引很多的字段，關(guān)閉這些字段的不必要的特性將對索引速度提升產(chǎn)生很大的幫助?使用一個更快的分析器有時間分析文檔將消耗很長的時間。 舉例來說， StandardAnalyzer 就比較耗時,尤其在Lucene2.3 版本之前。你可以嘗試使用一個更簡單更快但是符合你需求的分析器。?加速文檔的構(gòu)建時間在通常的情況下，文檔的數(shù)據(jù)來源可能是外部（比如數(shù)據(jù)庫，文件系統(tǒng)，蜘蛛從網(wǎng)站上的抓取等），這些通常都比較耗時，盡量優(yōu)化獲取它們的性能。?在你真的需要之前不要隨意的優(yōu)化 optimize 索引（只有在需要更快的搜索速度的時候）?在多線程中共享一個 I

9、ndexWriter最新的硬件都是適合高并發(fā)的（多核 CPU 多通道內(nèi)存構(gòu)架等），所以使用多線程添加文檔將會帶來不小的性能提升。就算是一臺很老的機器，并發(fā)添加文檔都將更好的利用 IO 和 CPU 多測試并發(fā)的線程數(shù)目，獲得一個臨界最優(yōu)值。?將文檔分組在不同的機器上索引然后再合并如果你有大量的文本文檔需要索引，你可以把你的文檔分為若干組，在若干臺機器上分別索引不同的組， 然后利用 writer.addIndexesNoOptimize 來將它們合并到最終的一個索引文件中。?運行性能測試程序如果以上的建議都沒有發(fā)生效果。建議你運行下性能檢測程序。找出你的程序中哪個部分比較耗時。這通常會給你想不到的

10、驚喜。當(dāng)你取回文檔時，使用 FieldSelector 仔細的選擇哪些字段需要獲取，如何獲取。不要獲取多于你需要的 hits獲取更多的搜索結(jié)果將會降低搜索速度。有兩個原因：其一，search 方法在返回 Hits 對象時，如果超過 100 個 hits,lucene 將在內(nèi)部自動重新執(zhí)行搜索。解決方案：使用返回 HitCollector 的 Search 方法。其二,搜索結(jié)果可能分布在硬盤的不同地方，獲取他們可能需要很多的 IO 操作。這個是很難避免的，除非索引比較小，可以直接緩存到內(nèi)存當(dāng)中。如果你不需要完整的文檔對象，你只需要其中的一個很小的字段，你可以使用 FieldCache 類來緩存它，從而達到快速訪問的效果。當(dāng)使用 fuzzy 查詢時設(shè)置一個較小的比較長度（pre 巾 xLength）Fuzzy 查詢執(zhí)行 CPL集型字符串比較，盡量避免將用戶查詢的 Term 與所有的 Term 進行比較。你可以設(shè)置只比較以前 N 個字符開頭的 Term。prefixLength 在 QueryParser 以及 FuzzyQuery 中可