我一直在寻找加速我正在处理的应用程序的solr查询的潜在方法。我已经读过有关solr缓存（https://wiki.apache.org/solr/SolrCaching）的内容，我认为过滤器和查询缓存可能会有所帮助。应用程序的配置会设置这些缓存，但它看起来像一些未经过实验的默认设置，而且我们的缓存命中率相对较低。
我无法确定的一个细节是缓存如何处理更新。如果我更新将导致从查询或过滤器缓存中删除或添加该记录的记录，请以高效的方式更新缓存吗？该应用程序相当重写，因此缓存是否以有利的方式更新将可能决定是否尝试调整缓存将有很大帮助。
答案 0 :(得分：0)
简短的回答是对索引进行更新（添加，编辑或删除），然后进行提交操作，重建索引并替换当前索引。由于高速缓存与特定索引版本相关联，因此在替换索引时将丢弃它们。如果启用了自动装配，则新索引中的缓存将使用您指定的最新查询或查询进行准备。
然而，这是我们正在谈论的Solr，并且通常有多种方法来处理任何情况。这绝对是这种情况。上面提到的提交操作称为硬提交，可能会也可能不会发生，具体取决于您的Solr配置以及您的应用程序如何与之交互。还有另一个称为软提交的选项，我相信它对你的索引来说是一个不错的选择。这是差异......
硬提交意味着重建索引然后保存到磁盘。这可以确保不会丢失更改，但这是一项昂贵的操作。
软提交意味着索引在内存中更新，而不是持久保存到磁盘。这是一个便宜得多的操作，但如果Solr意外停止，数据可能会丢失。
更进一步，Solr有两个漂亮的设置，称为 autoCommit 和 autoSoftCommit ，我强烈推荐。如果启用自动提交，则应禁用应用程序代码中的所有硬提交操作。 autoCommit设置可以指定排队文档更改的时间段（maxTime）和/或队列中允许的更改数（maxDocs）。当达到这些限制中的任何一个时，执行硬提交。 autoSoftCommit设置的工作方式相同，但会导致（您猜对了）软提交。 Solr关于UpdateHandlers的文档是了解这一点的一个很好的起点。
这些设置可以有效地进行批量更新，而不是一次进行批量更新。在像你这样的写作繁重的应用程序中，这绝对是一个好主意。最佳设置取决于读取与写入的频率，当然还取决于应用程序的业务需求。如果需要近实时（NRT）搜索，您可能希望将autoSoftCommit设置为几秒钟。如果搜索结果有点陈旧，那么你应该考虑将autoSoftCommit设置为一分钟甚至几分钟。 autoCommit设置通常设置得更高，因为它的主要功能是数据完整性和持久性。
我建议在非生产环境中进行大量测试，以确定应用程序的合理缓存和提交设置。鉴于您的应用程序是大量写入的，我会倾向于保守的缓存设置，您可能希望完全禁用自动装配。您还应该监视生产中的缓存统计信息，并减少命中率较低的缓存大小。当然，请记住，您的最佳设置将是一个移动目标，因此您应定期查看它们并在需要时进行调整。
在相关的说明中，Seven Deadly Sins of Solr是一本很好的读物，与手头的主题相关。祝你好运，与索尔一起玩得开心！