IndexWriter commit的Lucene .NET频率

Question

我在Lucene.Net中使用IndexWriter编写了许多文档。由于需要添加文档，所以我想知道在提交之前是否需要添加最佳文档数量。显然太多了，如果发生崩溃，你可能会失去内存中的所有内容，太频繁地在每个文件被添加后都会加速吞吐量。

Answer 1

在达到非常高的数字之前，似乎并不存在性能问题。

Total time to commit [10] messages was [00:00:00.1093779] 
Total time to commit [20] messages was [00:00:00.0156221] 
Total time to commit [40] messages was [00:00:00] 
Total time to commit [80] messages was [00:00:00.0312509] 
Total time to commit [160] messages was [00:00:00.0156231] 
Total time to commit [320] messages was [00:00:00.0156273] 
Total time to commit [640] messages was [00:00:00.0312489] 
Total time to commit [1280] messages was [00:00:00.0312509] 
Total time to commit [2560] messages was [00:00:00.0500343] 

Answer 2

这不是一个好的答案，看似简单的问题。除了“这取决于” ......

这取决于很多因素，如：

• 多大每个文档？如果它们很大（很多领域，大领域），那么当冲刷发生时，数字将会很小
• 什么是用例？你批量插入？如果是，那么它的值越高越好，IO越少，吞吐量越高。你是否需要立即承诺/坚持/坚持文档。那么你应该承诺每一次添加/更新。很多的IO，但是如果频率很低。然后是无限的光谱。

您最好设置“setRAMBufferSizeMB”而不是“setMaxBufferedDocs”。限制使用的内存量使基础架构需求更具可预测性。默认情况下，lucene按内存大小刷新（默认为16MB）。

还有另一种方法。将缓冲区大小设置为相当高的数字。但也有一个定时器定期提交。这可以在缓冲和可能“失去”更新的时段之间达到平衡。

是否存在与文档关联的递增“ID”？如果是这样，请确保它是一个领域。然后在启动时，您可以通过使用一个ID降序排序（如“通过ID desc选择顶级1顺序”）执行查询来查询最新的文档，并从那里重新启动更新。

如果没有ID，则添加数字日期字段并将DateTime.UtcNow.Ticks放入其中。这成为你的“更新游标”。

要牢记的另一件事是搜索延迟。摄取文档和搜索文档之间的时间。您可以遵循NRT模式并几乎完全保持最新状态。但是有成本。或者你可以决定一些延迟是可以接受的。在这种情况下，您可以更明智地决定何时刷新读取器/搜索器。

更多的概念性讨论。如果您可以提供关于各种关注点和参数的更多细节，我可以更具体一些。