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自身没法恢复问题。这样对于程序要求过高了。对于服务器管理也要求过高了。