lucene 索引注意事項

來源:互聯網
上載者:User
文章目錄
  • Boosting特性
  • Indexing Date
  • Indexing 數字
  • 排序
  • Lucene的IndexWriter調整
  • RAMDirectory 和 FSDirectory 轉化
  • 為查詢最佳化索引(index)
  • 並行作業Lucene和locking機制
  • Locing
  • 調試IndexWriter
Boosting特性

luncene對Document和Field提供了一個可以設定的Boosting參數(權重), 這個參數的用處是告訴lucene, 某些記錄更重要,在搜尋的時候優先考慮他們 比如在搜尋的時候你可能覺得幾個門戶的網頁要比垃圾小站更優先考慮

lucene預設的boosting參數是1.0, 如果你覺得這個field重要,你可以把boosting設定為1.5, 1.2....等, 對Document設定boosting相當設定了它的每個Field的基準boosting,到時候實際Field的boosting就是(Document-boosting*Field-boosting)設定了一遍相同的boosting.

似乎在lucene的記分公式裡面有boosting參數,不過我估計一般人是不會去研究他的公式的(複雜),而且公式也無法給出最佳值,所以我們所能做的只能是一點一點的改變boosting, 然後在實際檢測中觀察它對搜尋結果起到多大的作用來調整

一般的情況下是沒有必要使用boosting的, 因為搞不好你就把搜尋給搞亂了, 另外如果是單獨對Field來做Bossting, 也可以通過將這個Field提前來起到近似的效果

Indexing Date

日期是lucene需要特殊考慮的地方之一, 因為我們可能需要對日期進行範圍搜尋, Field.keyword(string,Date)提供了這樣的方法,lucene會把這個日期轉換為string, 值得注意的是這裡的日期是精確到毫秒的,可能會有不必要的效能損失, 所以我們也可以把日期自行轉化為YYYYMMDD這樣的形勢,就不用精確到具體時間了,通過File.keyword(Stirng,String) 來index, 使用PrefixQuery 的YYYY一樣能起到簡化版的日期範圍搜尋(小技巧), lucene提到他不能處理1970年以前的時間,似乎是上一代電腦系統遺留下來的毛病

Indexing 數字

 

  1. 如果數字只是簡單的資料, 比如中國有56個民族. 那麼可以簡單的把它當字元處理
  2. 如果數字還包含數值的意義,比如價格, 我們會有範圍搜尋的需要(20元到30元之間的商品),那麼我們必須做點小技巧, 比如把3,34,100 這三個數字轉化為003,034,100 ,因為這樣處理以後, 按照字元排序和按照數值排序是一樣的,而lucene內部按照字元排序,003->034->100 NOT(100->3->34)

 

排序

Lucene預設按照相關度(score)排序,為了能支援其他的排序方式,比如日期,我們在add Field的時候,

必須保證field被Index且不能被tokenized(分詞),並且排序的只能是數字,日期,字元三種類型之一

Lucene的IndexWriter調整

IndexWriter提供了一些參數可供設定,列表如下

  屬性 預設值 說明
mergeFactor org.apache.lucene.mergeFactor 10 控制index的大小和頻率,兩個作用
maxMergeDocs org.apache.lucene.maxMergeDocs Integer.MAX_VALUE 限制一個段中的document數目
minMergeDocs org.apache.lucene.minMergeDocs 10 緩衝在記憶體中的document數目,超過他以後會寫入到磁碟
maxFieldLength   1000 一個Field中最大Term數目,超過部分忽略,不會index到field中,所以自然也就搜尋不到

這些參數的的詳細說明比較複雜:mergeFactor有雙重作用

  1. 設定每mergeFactor個document寫入一個段,比如每10個document寫入一個段
  2. 設定每mergeFacotr個小段合并到一個大段,比如10個document的時候合并為1小段,以後有10個小段以後合并到一個大段,有10個大段以後再合并,實際的document數目會是mergeFactor的指數

簡單的來說mergeFactor 越大,系統會用更多的記憶體,更少磁碟處理,如果要打批量的作index,那麼把mergeFactor設定大沒錯, mergeFactor 小了以後, index數目也會增多,searhing的效率會降低, 但是mergeFactor增大一點一點,記憶體消耗會增大很多(指數關係),所以要留意不要"out of memory"
把maxMergeDocs設定小,可以強制讓達到一定數量的document寫為一個段,這樣可以抵消部分mergeFactor的作用.
minMergeDocs相當於設定一個小的cache,第一個這個數目的document會留在記憶體裡面,不寫入磁碟。這些參數同樣是沒有最佳值的, 必鬚根據實際情況一點點調整。
maxFieldLength可以在任何時刻設定, 設定後,接下來的index的Field會按照新的length截取,之前已經index的部分不會改變。可以設定為Integer.MAX_VALUE

RAMDirectory 和 FSDirectory 轉化

RAMDirectory(RAMD)在效率上比FSDirectyr(FSD)高不少, 所以我們可以手動的把RAMD當作FSD的buffer,這樣就不用去很費勁的調優FSD那麼多參數了,完全可以先用RAM跑好了index, 周期性(或者是別的什麼演算法)來回寫道FSD中。 RAMD完全可以做FSD的buffer。

為查詢最佳化索引(index)

Indexwriter.optimize()方法可以為查詢最佳化索引(index),之前提到的參數調優是為indexing過程本身最佳化,而這裡是為查詢最佳化,最佳化主要是減少index檔案數,這樣讓查詢的時候少開啟檔案,最佳化過程中,lucene會拷貝舊的index再合并,合并完成以後刪除舊的index,所以在此期間,磁碟佔用增加, IO符合也會增加,在最佳化完成瞬間,磁碟佔用會是最佳化前的2倍,在optimize過程中可以同時作search。

並行作業Lucene和locking機制

 

  • 所有唯讀操作都可以並發
  • 在index被修改期間,所有唯讀操作都可以並發
  • 對index修改操作不能並發,一個index只能被一個線程佔用
  • index的最佳化,合并,添加都是修改操作

IndexWriter和IndexReader的執行個體可以被多線程共用,他們內部是實現了同步,所以外面使用不需要同步

 

Locing

    lucence內部使用檔案來locking, 預設的locking檔案放在java.io.tmpdir,可以通過-Dorg.apache.lucene.lockDir=xxx指定新的dir,有write.lock commit.lock兩個檔案,lock檔案用來防止並行操作index,如果並行操作, lucene會拋出異常,可以通過設定-DdisableLuceneLocks=true來禁止locking,這樣做一般來說很危險,除非你有作業系統或者物理層級的唯讀保證,比如把index檔案刻盤到CDROM上。

調試IndexWriter

IndexWriter 有一個infoStream的

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在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.