lucene形成磁盤空間不足的問題

我不知道是否是理解錯了增量索引的概念
我搜索的網頁不會重複,不是對全部的網頁都不停的搜,而是我搜索特定的網站.這裏面不會出現重複現象.每次爬到的網頁確定是index裏沒有的

問一個問題
若是有10個網頁須要創建index
是
IndexWriter iw=new IndexWriter(...);
for(int i=0;i<10;i++){
iw.addDocuemnt(doc[i]);
}
iw.close();

仍是
for(int i=0;i<10;i++){
IndexWriter iw=new IndexWriter(...);
iw.addDocuemnt(doc[i]);
iw.close();
}

還有，若是index量有10G，作一次optimize須要多長時間？
建議多長時間Optimize一次？
對一個剛剛作過Optimize的index目錄作Optimize，會不會很快就結束，仍是也須要很長時間？
optimize結束後是否是隻剩下3個文件？若是有其餘文件，是否是意味着有問題呢？（沒有Reader或者Searcher在使用這個index的時候）
 
 發表時間：2007-08-12 沒有必要6分鐘一次。 每次optimize都會從新作索引， 光拷貝10G文件就得多少分鐘？若是不是頻繁刪除的話， 一天， 甚至一禮拜一趟均可以。 選擇系統負載少的時候就行。 

 發表時間：2007-09-06 1:當search動做太頻繁,或者訪問的人不少,在optimize時會出現這個message
java.io.IOException: Cannot delete E:\index\_nir.f2;
注意檢查下是否是每次查詢完都把indexReader給close了。你能夠測試下，頻繁的開search，若是還有這個異常，估計就是沒把indexReader給close（千萬不要覺得close the indexSearcher 就ok了，要注意新建indexSearcher時傳的參數是什麼，是Direcitory,仍是indexReader，仍是字符串文件路徑，這影響是否close indexReader） 
返回頂樓         回帖地址 0 0 請登陸後投票
 
 發表時間：2007-09-07 新建indexReader時傳入的是index file path，並且在search完畢後都在finally裏面作了close動做。

BTW：我把optimize動做去掉後，也就是說不管它運行多久都不讓他optimze，結果index很正常，文件數量不會增長不少，search也okay。

問題是總不能老這樣呀，一直不optimize也不行呀。我作一次optimize，就要n分鐘，index文件太大，沒辦法。

並且個人index動做是針對不一樣的網頁，好比 http://xxx.xxx.xxx/1.html被index後，之後遇到這個頁面就不會再作index動做。換句話說，每次index的內容都是新的，不會覆蓋之前的東西。這樣的需求是否是不用optimize呀。 
返回頂樓         回帖地址 0 0 請登陸後投票
  發表時間：2007-09-07 fool_leave，你用的lucene版本是多少？若是是2.2的話，能夠用indexwriter；之前用2.0，我用indexReader執行刪除操做也出現過相似的狀況（懷疑是indexreader只將被刪除的documents設置了下刪除的標誌，在close的時候沒真正執行刪除動做，也許是我少執行了一個步驟，=會去看看reader的刪除操做）。若是由於文件太大致使優化(optimze，它的做用是從新整理段，把document的id從新設置，這個對搜索效率頗有幫助，和document裏term的內容不要緊)的時間很長，那就得從新考慮下你的架構了(10g太大了)。這個得請教下imjl. 
返回頂樓         回帖地址 0 0 請登陸後投票
 
 發表時間：2007-09-07 建議設置時間任務，凌晨2點啓動indexWriter進行optimise。
啓動前前臺頁面切換到顯示維護的狀態，而後等待全部的reader,searcher關閉，而後進行optimise。（固然只有一個writer在跑）

In environments with frequent updates, optimize is best done during low volume times, if at all.
摘自lucene的文檔
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/index/IndexWriter.html#optimize()

It is best not to re-open readers while optimize is running.
這句話我不是很明白，我以爲應該是說不要在optimize運行時打開新的reader。可是用的re-open，難道是說
不要在optimize時，重置reader。的狀態？ 
返回頂樓         回帖地址 0 0 請登陸後投票
 
 發表時間：2007-09-07 由於if some but not all readers re-open while the optimize is underway, this will cause > 2X temporary space to be consumed as those new readers will then hold open the partially optimized segments at that time.因此It is best not to re-open readers while optimize is running.在進行優化的時候最好不要新開readers(2.2裏好像沒有reopen這個方法吧，2.3裏估計會出)，由於新的readers同時會打開部分優化過的段，索引耗損的臨時空間會大於兩倍索引大小(翻譯錯了樓下的必定要指出來哦)。

我以爲在作優化時，不會對searcher有影響，沒必要關閉搜索功能。 
返回頂樓         回帖地址 0 0 請登陸後投票
 
 發表時間：2007-09-10 thanks
不管是否是reopen,optimize都會耗用更多的space來存儲臨時文件.但這些都是臨時文件,在動做結束後會被釋放掉.因此若是硬盤空間足夠，這些多餘的耗用應該不是大問題。

但個人index目錄總共有3G（我把舊的document刪除了）。不過每次optimize同樣要花費很長時間。我不知道應該如何從新設置document的id.個人lucene version是2.0的。

lucene的optimize的結果除了將index的文件數變成3個，還有什麼好處呢？到如今我看來只有在delete索引節點後有必要經過optimize真正的把這些節點刪除，其餘的優點彷佛很是不明顯。（由於我每次寫入index的索引內容都是新的，不會有重複或追加現象）。我如今完全把optimize從程序裏去掉了，運行到如今已經1個月了，每分鐘都有新內容加進去，但index目錄依然很正常，文件數24個，從文件的修改時間上來看也很正常。search動做也很正常。

若是一次optimize須要花費5分鐘以上的時間，而這個操做又是不可中斷的，一旦在optimize過程當中終止了程序，就會出現lucene自身沒法恢復問題。這樣對於程序要求過高了。對於服務器管理也要求過高了。