【问题标题】:Preventing solr cache flush when commiting提交时防止 solr 缓存刷新
【发布时间】: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

选择配置的原因来自我对以下几点的理解:

  1. 我的应用程序被大量读取需要大量的缓存,我无法让我的缓存刷新。因此,我完全禁用了软提交。
  2. 我再次禁用了 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 的自动硬提交将不允许我添加的更改被反映。

如果我误解了什么,请指出我。

现在这是我的问题:

  1. 是否无法确保在将某些文档添加到索引并同时使更改可用时不会清除顶级过滤器缓存?
  2. 如果是这种情况,那么我是否需要始终依赖缓存的预热才能在缓存中获取一些文档?
  3. 除了热身之外,还有其他方法可以避免这种情况吗?如果他们想构建一个快速可搜索的产品并拥有一定的写入吞吐量?

我已经阅读了几个文档链接和文章,但我找不到任何合适的解释在不同场景中使用的设置。如果有人可以解释我做错了什么并指导我找到正确的解决方案,那将非常有帮助。

【问题讨论】:

    标签: caching search solr


    【解决方案1】:

    你的理解是对的。

    Solr 缓存与索引的特定实例相关联 搜索器,索引的特定视图,在搜索过程中不会更改 该搜索者的生命周期。只要那个索引搜索器正在 使用后,其缓存中的任何项目都将有效且可供重复使用。

    当打开一个新的搜索器时,当前的搜索器会继续 服务请求,而新的自动预热其缓存。新的 searcher 使用当前搜索器的缓存来预填充它自己的。 当新搜索器准备好时,它被注册为当前搜索器 searcher 并开始处理所有新的搜索请求。老搜索者 完成所有请求的服务后将关闭。

    1. 如果您需要让您的搜索者访问新添加的文档,您 需要打开一个新的搜索器。这可以通过使用软来完成 使用 openSearcher=true 提交或硬提交。缺点是 您的顶级缓存将失效。这就是你的价格 为获得知名度付费。

    2. 是的,预热是在之前填充缓存的最佳方法 打开一个新的搜索器。你应该确定什么是最 系统中常用的查询,并让这些查询自动预热新的 缓存。

    3. 如果您不想要实时搜索并且可以容忍这种情况,您应该关闭软提交并使用 opensearcher=true 的硬提交。硬提交的间隔取决于您的应用程序可以容忍多少延迟。如果您不关心在 t=t1 索引的文档会出现直到 t=t1+x 分钟。您应该每 x 分钟提交一次。

    每个选项都有一个缺点。你需要弄清楚什么最适合你。

    天下没有免费的午餐。

    【讨论】:

    • 关于 #1 - 如果索引的内容发生变化,缓存将不再有效,并且不再受信任 - 所以如果用户想要查看更改(并且不要离开响应处于未定义状态),它们必须无效。关于#3 - commitWithin 可能是这里最好的实现,因为它允许你说“这些文档应该在三分钟内可见” - 所以你可以从多个位置索引而不必担心索引被提交更多来自其他线程。
    • 感谢@root545 的解释。这有帮助。
    【解决方案2】:

    从 solr 用户列表中应对 您可以尝试使用更实时的分段缓存。
    它应该像 q={!parent which=COLOR:Blue v=''} 而不是 q=COLOR:Blue 确保您在 solrconfig.xml 中有以下定义,此再生器应在搜索器之间传输过滤器位集。

     <query>
        <cache name="perSegFilter" 
               class="solr.LRUCache"
               size="100"
               initialSize="10"
               autowarmCount="100%"
               regenerator="solr.NoOpRegenerator"/>
      </query>
    

    在提交后立即检查此缓存是有意义的。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-01-18
      • 2020-06-29
      • 2015-03-05
      • 2011-03-09
      • 2014-11-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多