Lucene 优化期间Solr%100写入可用性

这就是我的困境

我正在用Solr运行一个实时搜索索引，每天索引大约600万个文档。文件大约7天后过期。因此，我每天都要添加600万个文档，删除600万个文档。不幸的是，我需要每隔一段时间运行一次“优化”，否则我将耗尽磁盘空间

在“优化”期间，Solr继续为读取请求提供服务，但写入请求被阻止。我所有的写操作都在一个队列后面，所以在操作上，一切都很好。然而，由于我的索引太大，“优化”大约需要一个小时，而在这一小时内，没有新的更新可供读取。所以我的索引是实时的，除了我每天优化的小时数。在此期间，该指数似乎落后了一个小时。这不是最优的

我目前的解决方案是：将所有数据写入两个Solr索引，都在队列后面。每12小时对两个索引进行交替“优化”。在索引1的“优化”过程中，将所有读取流量定向到索引2，反之亦然。不过，这种基于时间的路由确实显得非常脆弱和草率

---

有更好的方法吗？

您是否尝试使用不同的合并因素或不同的合并策略？如果您正在进行持续写入，那么这可能是比优化更好的方法。

使用复制

---

写给你的主人，复制给你的奴隶。Optimize将在主服务器上运行，并对从服务器运行所有查询

根据评论和常见问题，不需要优化。不优化可能会在最初增加索引大小，但不应持续增加。我建议您禁用optimize几天并监视索引大小。

另一个基于时间的选项是每天维护一个单独的索引，并每天写入所有索引。在这种情况下，您不需要执行删除操作，而是以先进先出（FIFO）的方式旋转索引

你明白了。在第2天，索引1将完全停止使用，您将切换到使用索引2进行读取

---

显然，这是一个过于简单的示例，您可能希望旋转索引命名（索引2变为索引1，依此类推），但希望这能提供另一种实现方法。

这很有效！哇，我真希望早点知道。我本可以避免大量的写宕机。谢谢事实上，恐怕这没用。随着时间的推移，我们的性能急剧下降，合并是随机发生的，造成的停机时间比我们每天执行计划优化的2小时还要多。您的

合并系数是多少？你可以像前面提到的那样尝试增加它。问题不是100%的读可用性，而是100%的写可用性。使用您提出的解决方案，当我们在master上进行优化时，我们会遇到写宕机。谢谢，我将对此进行研究并报告。不同的合并策略是如何执行的？
Index 1 = Day 1 + Day 2 + Day 3 + Day 4 + Day 5 + Day 6 + (no longer used)
Index 2 = empty + Day 2 + Day 3 + Day 4 + Day 5 + Day 6 + Day 7 + (no longer used)
Index 3 = empty + empty + Day 3 + Day 4 + Day 5 + Day 6 + Day 7 + Day 8
...