【发布时间】:2018-04-27 00:12:23
【问题描述】:
我的应用程序的写入吞吐量很低,我可以在 2-3 分钟内让更改反映在 solr 搜索结果中。
目前我通过我的索引应用程序进行提交(在每批文档之后),并且还在 solr 端配置了以下内容:
solr.autoSoftCommit.maxTime : -1 (disabling auto soft commit)
solr.autoCommit.maxTime : 300000 (5 mins of hard auto commit interval)
opensearcher : false
选择配置的原因来自我对以下几点的理解:
- 我的应用程序被大量读取需要大量的缓存,我无法让我的缓存刷新。因此,我完全禁用了软提交。
- 我再次禁用了 opensearcher,如果我不这样做,它会使顶级缓存无效,这是不可取的
在生产中,我观察到,只要我的应用程序尝试索引 1 个文档(或一批),然后(从我的应用程序)发出提交语句,我的所有顶级缓存都会被删除。
我想也许仅仅依靠硬自动提交会有所帮助,但据此stack overflow link
硬提交是关于持久性,软提交是关于可见性。这里实际上有两种风格,openSearcher=true 和 openSearcher=false。首先,我们将讨论在这两种情况下会发生什么。如果 openSearcher=true 或 openSearcher=false,以下后果最为重要:
tlog 被截断:新的 tlog 被启动。旧的 tlog 将是 如果较新的已关闭 tlog 中有超过 100 个文档,则删除。 当前索引段已关闭并刷新。背景段 可以启动合并。以上发生在所有硬提交上。那 离开 openSearcher 设置
openSearcher=true: Solr/Lucene 搜索器重新打开,所有 缓存失效。完成自动升温等。这曾经是 只有这样您才能看到新添加的文档。
openSearcher=false: 除了以上四点之外,没有其他任何事情发生。寻找 文档,软提交是必要的。
因此,总而言之,软提交将刷新缓存,opensearcher=true 的自动硬提交也将如此。虽然 opensearcher=false 的自动硬提交将不允许我添加的更改被反映。
如果我误解了什么,请指出我。
现在这是我的问题:
- 是否无法确保在将某些文档添加到索引并同时使更改可用时不会清除顶级过滤器缓存?
- 如果是这种情况,那么我是否需要始终依赖缓存的预热才能在缓存中获取一些文档?
- 除了热身之外,还有其他方法可以避免这种情况吗?如果他们想构建一个快速可搜索的产品并拥有一定的写入吞吐量?
我已经阅读了几个文档链接和文章,但我找不到任何合适的解释在不同场景中使用的设置。如果有人可以解释我做错了什么并指导我找到正确的解决方案,那将非常有帮助。
【问题讨论】: