[lucene] lucene对索引的修改为什么只能先删除后增加
 |
ybzshizds
2009-06-02
我们对lucene索引做修改操作时，都是先删除后增加
但是从原理上分析，为什么只能这样做，是索引自己特殊的结构导致的吗？ 请高手从分析源代码的角度解释一下。 如果修改源码，实现真正的修改，使Document修改前和修改后在segement中的docId不变，也就是修改的那条索引在索引文件中的位置依然不变(先删除后增加，docId排在最后了，位置也变了)能否做到？ |
 |
chester60
2009-06-03
简单的来说，要删除一个文档，要同时修改terminfo（每个term出现的频率），docList（比如“java”这个词在文档1，3，5，7……出现），还有保存field信息的fdx文件。这些文件还有对应的索引文件，有的索引的格式是比较难改的，改动一项可能会引起整个文件大量的变动。
其实lucene根本没有真正删除doc，只是做了一个特例表，删除的doc不进行排序操作而已。 |
|
ybzshizds
2009-06-03
引用 其实lucene根本没有真正删除doc，只是做了一个特例表，删除的doc不进行排序操作而已。
IndexReader.deleteDocument(int docNum)方法是作个删除标记，随后对索引的访问会跳过这个标记的文档。如果IndexReader.document(int docNum),指定要读这个已经作了删除标记的文档会抛出 "attempt to access a deleted document"异常 IndexReader.undeleteAll(),可以恢复删除的文档 有点类似于windows的回收站功能。 但是当执行 IndexWrite.optimize()对索引进行优化时就是真正的物理删除了，这里的物理删除是把索引重做了一遍吗，还是说只是将作了删除标记的文档删除 |
|
chester60
2009-06-04
ybzshizds 写道 但是当执行 IndexWrite.optimize()对索引进行优化时就是真正的物理删除了，这里的物理删除是把索引重做了一遍吗，还是说只是将作了删除标记的文档删除 重做 |
