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