我是Apache SOLR的新手，我想在SOLR中实现归档，因为我的数据日益增长。我不太确定SOLR是否允许数据存档？ 如果有人对此有任何建议，请给我。
答案 0 :(得分：1)
这个问题非常普遍，所以要给出一个简单易懂的答案有点困难，但如果考虑归档片刻，那么它有两个部分。
第一部分在solr中相当容易，只要您可以识别将选择“旧”文档的查询。例如，如果您有一个字段记录您将数据发送到solr的名称'index_date'想要在2014年1月1日之前删除所有内容，那么您可能会这样做：
curl http://localhost:8983/solr/update --data '<delete><query>indexed_date:[* TO 2014-01-01T00:00:00]</query></delete>' -H 'Content-type:text/xml; charset=utf-8'
第二部分需要更多思考。第一个问题是，为什么要将solr中的数据移动到其他位置。或多或少的答案必须是因为你认为你可能需要它。但问问自己，用例是什么用例，并且您可以为该用例提供服务。您是否计划在以后的某个时间点将数据重新放入solr中？ solr是唯一存储此数据的地方，您只需要它来进行记录保存/审核吗？
您必须根据自己的需要确定“归档”的后半部分，但这里有一些需要考虑的事项：solr中存储的数据背后的数据=“false”已经丢失。您无法完全重建创建它们的数据。可以使用常规查询在xml / json / csv中检索stored =“true”的字段，然后输出到您选择的长期存储。 许多系统使用solr作为主要源的索引，而不是使用solr作为主要源本身。在这种情况下，可能不需要存档数据，只需删除太旧而无法与搜索结果相关的数据，但当然要确保您的业务团队在执行此操作之前理解并同意此策略！ ：）
编辑：我碰巧回头看看这个，当我重读它时，我意识到我遗漏了一些东西并且有了新的发展。
我遗漏了什么
上述按查询删除策略的缺点是已删除的文档仍保留在索引中（仅标记为已删除），可能会浪费多达50％的空间（如果您运行“优化”，则可能会浪费更多！） ）。以下是Eric Erickson关于删除和空间后果的好文章：
https://lucidworks.com/2017/10/13/segment-merging-deleted-documents-optimize-may-bad/
新发展
如果时间是删除的标准，你遵循我上面提到的关于没有solr成为事实的唯一来源的最佳实践（即solr只是主要来源的索引，而不是数据存储）那么你可能会非常我们希望使用新的时间路由别名功能，它保留一组临时限制的集合并删除最旧的集合。删除集合而不是通过查询删除的好处是没有合并要做。索引的片段整体消失，因此没有删除的文档会浪费空间。
http://lucene.apache.org/solr/guide/7_4/time-routed-aliases.html
自我推销免责声明：与David Smiley一起，helped write this feature