IndexWriter提交时做的事情:
1.Flush 任何 buffered docs和删除
2.同步所有的新进创建的文件,包括新flushed文件,和merge产生的文件(自最后一次commit调用后的或IndexWriter打开前的 IndexWriter调用 Directory.sync来实现这个,而这个操作会存储到真的IO。这个通常是一个耗时的操作。
3.写和同步下一个segments_N文件。一旦完成,IndexReaders将突然看见上次看到的提交。
4.删除老的commits(调用IndexDeletionPolicy来实现),你可以创建你的自己的实现。
IndexDeletionPolicy
默认值为KeepOnlyLastCommitDeletionPolicy,无论新的commit是否完成 它删掉所有的commits。大多情况就用这个默认值。但对于一些高级的应用,你会保留一个老的 point-in-time的snapshot,即使是更多的改变提交到index中,你可以实现自己的policy。
例如,当在NFS上共享index时,它可能很有必要定制删除策略-直到所有的reader使用index(这index已切到最近的提交)再删除commits。
另一个例子是一个零售公司想保存最近N个版本的catalog。注意无论何时你的选择的策略,保存一个commit,它会消耗必要的index磁盘。如果你keep多commits在index里,有一些现成的API可以帮你。
管理多commits
一般的,一个Lucene的index将只有一个commit,即最后一个commit。但通过实现了一个定制的删除策略,你可以容易的在index聚集多个commits。你可以使用静态的IndexReader.listCommits()方法列出当前所有的commits。然后你可以一个个的处理这些commits。例如,如果你之前调用过IndexWriter.commit(String commitUserData),那么该字符串对于每个commits都可以访问了(即通过调getUserData()方法)。这个字符串可能存储一些对你的应用有用的东西,使你获取你感兴趣的特殊的commit)
一旦你找到一个commit,你可以打开一个IndexReader:一些静态方法能接收IndexCommit参数。你可以使用这些以显示的搜索以前一个版本的索引。
使用同样的逻辑, 你可以基于前一个commit打开一个IndexWriter,但这种使用情况有很大的不同:这个允许你rollback到前一个commit,并且能基于那一点开始索引新文档,且能有效的撤销基于那个commit点后的所有索引的更改。这个同IndexWriter的rollback方法相似,除了这种方法:只回退当前IndexWriter 会话中的变更完成;同时打开一个之前的commit以使你回到很久之前的一个提交。
TWO PHASED COMMIT
For applications that need to commit a transaction involving a Lucene index and other external resources, for example a database, Lucene exposes the prepareCommit() and prepareCommit(String commitUserData) methods. Each method does steps 1 and 2 above, as well as most of step 3, but it stops short of making the new segments_N file visible to a reader. After prepareCommit() is called, you should then either call rollback(), to abort the commit, or commit(). Commit() is a very fast call if prepareCommit() was already called. If an error will be hit, for example disk full, most likely prepareCommit() will hit the error, not commit(). The separation of these two steps of committing allows you to build a distributed two-phase commit protocol involving Lucene.
两阶段提交
对于那些需要提交事务(该事务涉及lucene索引和其他外部资源)的应用,如数据库,lucene expose prepareCommit() 和 prepareCommit(String commitUserData) 方法。每个方法做上面提到的1和2,3也会做到,但它停一小会,直到新的segments_N文件对一个reader可见。prepareCommit()调用完后,你应该要么调用rollback,要么放弃commit,要么-commit。commit是一个很快的调用,如果 prepareCommit()已完成调用。如果一个错误出现,如磁盘满了,那么是prepareCommit会碰到错误,而不是commit。这两个提交步骤的分开允许你构建一个分布式的的两阶段提交协议。
1.Flush 任何 buffered docs和删除
2.同步所有的新进创建的文件,包括新flushed文件,和merge产生的文件(自最后一次commit调用后的或IndexWriter打开前的 IndexWriter调用 Directory.sync来实现这个,而这个操作会存储到真的IO。这个通常是一个耗时的操作。
3.写和同步下一个segments_N文件。一旦完成,IndexReaders将突然看见上次看到的提交。
4.删除老的commits(调用IndexDeletionPolicy来实现),你可以创建你的自己的实现。
IndexDeletionPolicy
默认值为KeepOnlyLastCommitDeletionPolicy,无论新的commit是否完成 它删掉所有的commits。大多情况就用这个默认值。但对于一些高级的应用,你会保留一个老的 point-in-time的snapshot,即使是更多的改变提交到index中,你可以实现自己的policy。
例如,当在NFS上共享index时,它可能很有必要定制删除策略-直到所有的reader使用index(这index已切到最近的提交)再删除commits。
另一个例子是一个零售公司想保存最近N个版本的catalog。注意无论何时你的选择的策略,保存一个commit,它会消耗必要的index磁盘。如果你keep多commits在index里,有一些现成的API可以帮你。
管理多commits
一般的,一个Lucene的index将只有一个commit,即最后一个commit。但通过实现了一个定制的删除策略,你可以容易的在index聚集多个commits。你可以使用静态的IndexReader.listCommits()方法列出当前所有的commits。然后你可以一个个的处理这些commits。例如,如果你之前调用过IndexWriter.commit(String commitUserData),那么该字符串对于每个commits都可以访问了(即通过调getUserData()方法)。这个字符串可能存储一些对你的应用有用的东西,使你获取你感兴趣的特殊的commit)
一旦你找到一个commit,你可以打开一个IndexReader:一些静态方法能接收IndexCommit参数。你可以使用这些以显示的搜索以前一个版本的索引。
使用同样的逻辑, 你可以基于前一个commit打开一个IndexWriter,但这种使用情况有很大的不同:这个允许你rollback到前一个commit,并且能基于那一点开始索引新文档,且能有效的撤销基于那个commit点后的所有索引的更改。这个同IndexWriter的rollback方法相似,除了这种方法:只回退当前IndexWriter 会话中的变更完成;同时打开一个之前的commit以使你回到很久之前的一个提交。
TWO PHASED COMMIT
For applications that need to commit a transaction involving a Lucene index and other external resources, for example a database, Lucene exposes the prepareCommit() and prepareCommit(String commitUserData) methods. Each method does steps 1 and 2 above, as well as most of step 3, but it stops short of making the new segments_N file visible to a reader. After prepareCommit() is called, you should then either call rollback(), to abort the commit, or commit(). Commit() is a very fast call if prepareCommit() was already called. If an error will be hit, for example disk full, most likely prepareCommit() will hit the error, not commit(). The separation of these two steps of committing allows you to build a distributed two-phase commit protocol involving Lucene.
两阶段提交
对于那些需要提交事务(该事务涉及lucene索引和其他外部资源)的应用,如数据库,lucene expose prepareCommit() 和 prepareCommit(String commitUserData) 方法。每个方法做上面提到的1和2,3也会做到,但它停一小会,直到新的segments_N文件对一个reader可见。prepareCommit()调用完后,你应该要么调用rollback,要么放弃commit,要么-commit。commit是一个很快的调用,如果 prepareCommit()已完成调用。如果一个错误出现,如磁盘满了,那么是prepareCommit会碰到错误,而不是commit。这两个提交步骤的分开允许你构建一个分布式的的两阶段提交协议。