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