更新 SOLR 文档而不添加已删除的文档答案

【问题标题】：Update SOLR document without adding deleted documents更新 SOLR 文档而不添加已删除的文档
【发布时间】：2019-04-14 00:59:15
【问题描述】：

我正在运行大量 SOLR 文档更新，这导致成千上万的文档被删除，磁盘使用量显着增加（100 Gb）。

我可以通过优化删除所有已删除的文档

卷曲http://localhost:8983/solr/core_name/update?optimize=true

但这需要几个小时才能运行，并且需要大量 RAM 和磁盘空间。

有没有更好的方法从 SOLR 索引中删除已删除的文档或更新文档而不创建已删除的文档？

感谢您的帮助！

【问题讨论】：

更新：通过在极少数情况下使用 commit=True 和 expungeDeletes=True 进行更新，它确实删除了一些已添加的已删除文档（从没有它的 8295 到有它的 97），但它也显着增加执行时间（从 2 分钟 30 秒到 5 分钟）。这很有帮助，但我不想一开始就添加那些已删除的文档。

标签： solr

【解决方案1】：

Lucene 使用 append only 策略，这意味着当添加旧文档的新版本时，将旧文档标记为已删除，并将新文档插入索引中。这种方式允许 Lucene 在添加文档时避免重写整个索引文件，代价是旧文档物理上仍然存在于索引中 - 直到发生合并或优化。

当您发出 expungeDeletes 时，您是在告诉 Solr 在已删除文档的数量超过某个阈值时执行合并，实际上，这意味着您在 Solr 认为必要的情况下强制在幕后进行优化。

如何解决此问题取决于有关您的用例的更具体信息 - 在一般情况下，只需将其保留为合并因子等的标准设置就足够了。如果您没有看到任何合并，您可能已经禁用了自动合并（取决于您的索引大小，并且看到数十万已删除的文档对于需要 2 分 30 秒的索引处理来说似乎很广泛）。在这种情况下，请确保正确启用它并再次调整它的值。还有一些更改 that were introduced with 7.5 to the TieredMergePolicy 允许对合并过程进行更详细的控制（可能还有更好的默认值）。

如果您每次都重新索引完整的数据集，索引到单独的集合/核心，然后在完成后切换别名或重命名核心，然后删除旧数据集也是一种选择。

【讨论】：

感谢您的回答！我研究了修改 TieredMergePolicy，特别是 reclaimDeletesWeight 参数，但没有弄清楚如何去做。你知道如何修改吗？它应该默认存在于solorconfig.xml文件中还是手动添加？
必须添加 - 请参阅 Customizing Merge Policies 了解该部分的外观。 reclaimDeletesWeight 设置应该可以通过 <double name="reclaimDeletesWeight">2.0</double> 更改。您通过<mergePolicy class="org.apache.lucene.index.TieredMergePolicy"> ... settings .. </mergePolicy> 告诉它使用 TMP
谢谢@MatsLindh。我更新了我的 solrconfig.xml 文件，添加了<mergePolicy class="org.apache.lucene.index.TieredMergePolicy"><int name="maxMergeAtOnce">8</int><int name="segmentsPerTier">8</int><double name="reclaimDeletesWeight">10.0</double></mergePolicy>。我会更新大约 50 万份文档，看看明天会是什么样子。
使用 reclaimDeletesWeight = 10 没有帮助。我的更新导致约 50 万个新删除的文档（约 1.5% 的总索引大小）和约 100Gb 的索引大小增加（约 30% 的索引大小）。我猜删除的文档数量不足以触发合并。如何检查是否禁用了自动合并？使用 expungeDeletes 时，它似乎没有进行完整的索引优化。那是对的吗？有没有办法查看哪个索引段中删除的文档最多，并且只优化这些段？再次感谢您的帮助。