【发布时间】：2016-02-19 17:13:19
【问题描述】：
我正在使用 Lucene .Net 中的 IndexWriter 编写许多文档。由于提交添加的文档是有成本的，我想知道在提交之前是否有最佳数量的文档要添加。显然太多了，如果发生崩溃，您可能会丢失内存中的所有内容，过于频繁，例如添加每个文档后会限制吞吐量。
【问题讨论】：
标签： .net lucene.net
【发布时间】：2016-02-19 17:13:19
【问题描述】：
在达到非常高的数字之前，似乎不会对性能造成影响。
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]
【讨论】：
对于这个看似简单的问题，这不是很好的答案。除了“这取决于”...
这取决于很多事情，例如：
- 每个文档有多大？如果它们很大（很多字段，很大的字段），那么当刷新发生时这个数字会非常小
- 用例是什么？你批量插入吗？如果是，那么高值它“更好”，更少的 IO = 更高的吞吐量。您是否要求文档立即提交/持久/持久。然后你应该提交每个添加/更新。大量 IO，但如果频率较低。然后是介于两者之间的无限光谱。
您最好设置“setRAMBufferSizeMB”而不是“setMaxBufferedDocs”。限制使用的内存量使基础设施需求更加可预测。默认情况下，lucene 按内存大小（默认 16MB）刷新。
还有另一种方法。将缓冲区大小设置为相当高的数字。但也有一个计时器来定期提交。这在缓冲和您可能“丢失”更新的时间之间取得了平衡。
是否有与文档关联的递增“ID”？如果是这样，请确保它是一个字段。然后在启动时，您可以通过使用 ID 降序排序（如“按 ID desc 选择前 1 个订单”）进行查询来查询最新的文档，然后从那里重新开始更新。
如果没有 ID，则添加一个数字日期字段并将 DateTime.UtcNow.Ticks 放入其中。这将成为您的“更新光标”。
要记住的另一件事是搜索延迟。提取文档和可搜索文档之间的时间量。您可以遵循 NRT 模式并且几乎完全是最新的。但这是有代价的。或者您可以决定某些延迟是可以接受的。在这种情况下，您可以更明智地决定何时刷新阅读器/搜索器。
更多的是概念性讨论。如果您可以提供有关各种关注点和参数的更多详细信息，我可以更具体。
【讨论】：