关于lucene文件锁和增量索引BUG的讨论。

先用我现在的真实项目作为环境给大家介绍一下：30万左右的纪录数，几十人不停的在维护这些纪录，索引的建立方式我采用了8个小时一次全量索引、20分钟一次增量索引，之所以跑的这么频繁，是希望能保持一定的实时性（增量）和准确性（全量），索引存放的目录加一个整型的数字作为文件夹名称，每一次新的全量索引的建立都用一个大一位的整数存放，等索引建完后自动切换到新的索引文件进行检索。以上这些就是大致的情况，下面分别讨论标题提到的两个问题：
1、文件锁。
    每次全量索引的文件大小大概为130M，每次增量索引大概增加一倍，一段时间后索引文件的大小非常可观，由于每次新的全量索引会重新建立一个目录，故采用自动删除旧的目录方式，但是被使用过的旧的索引文件却无法删除，即使使用了IndexReader的unclock方法也不行，不知道大家有没有遇到过这种情况。
2、增量索引的BUG。
    lucene利用IndexWriter(dir, analysis, false)中的最后一个参数设置不清空目录来创建增量索引，在修改的时候其实原理类似于我上面创建新的全量索引的方式，但是切换的时间不一样，我是在新的索引完成后切换，但是lucene是在一开始就切换，这样就会造成修改的数据量如果很大，在修改的期间检索出来的结果非常不稳定，我觉得这应该是一个逻辑上的BUG，不知大家认为如何。

可以考虑使用compass 吧。将事务和索引捆绑在一起，那样就不用增量索引了吧。

谢谢bjwulin这个建议，本来对compass不了解，刚才去搜了一下，果然是针对我的问题有很大的提升，万分感谢！

我也很奇怪,不知道为什么一增量索引,索引数据就增大一倍!

索引完后要optimize，不会大一倍，楼主的现象应该是没有做optimize

他应当是有做optimize的，只是因为他说

“被使用过的旧的索引文件却无法删除”

应该是还有程序在使用里面的索引文件，在切换点上没有进行完全的close或者close没有真正完成，是否考虑延时close与删除，然后先删除目录里的文件，再去试着删除目录。

另外，我想知道你动态切换的时间点是什么，具体说说，如何应对并发呢？

你好，我也是做lucene搜索的，目前项目遇到的情况跟你的那种状况很类似，我们目前的索引数量有50万，每10分钟更新一次，每次都会有新增2000 条，整个索引文件有几百M了，全量更新一次要花1个小时，预见未来的数据规模会达到百万级别。你的帖子有个回复提到Compass，我查了一下，感觉听适合我们的需求的，主要是对象索引映射实现的实时更新很诱人：），不知道你那边情况怎么样，用Compass好使否？索引性能怎么样？
我的msn：emmetxu@hotmail.com 非常有兴趣和你聊聊 ，谢了。

我最近也在做lucene,关于增量索引是挺让人头疼,我觉得lucene这个增量索引做的不尽人意,每一次增量它本身不会判断重复的索引,相当于在原来的基础上又做了一次全量索引,当然少了一步清空目录的操作,关于增量索引,自己还要做判断,每一次的循环addDocument()要判断原索引中是否存在重复的索引,如果是还要判断文件最后的修改时间是否跟索引的最后修改时间相匹配!不匹配删除掉,把新的添加到索引中.关键问题是如何判断文件的主KEY(文件名和路径)索引中是否存在!!这个也是我一直没有解决掉的,看了一下LUCENE的底层代码并没有提供这样的接口供调用!迷惑,如果哪位仁兄有好的方法希望一起探讨,赐教!

因为你即使用的是增量索引,方法中依旧用的是writer.addDocument(new Field())这个方法,当然要增加一倍了

就象我说的,必须经过判断才能控制这种情况,关键是判断的那一步让我头疼