SOLR autoCommit 与 autoSoftCommit

Question

我对 和 感到非常困惑。这是我的理解

• autoSoftCommit - 在 autoSoftCommit 之后，如果 SOLR 服务器出现故障，autoSoftCommit 文档将会丢失。

• autoCommit - 对磁盘进行硬提交，并确保将所有 autoSoftCommit 提交写入磁盘并提交任何其他文档。

我的以下配置似乎只与 autoSoftCommit 一起使用。 autoCommit 本身似乎没有进行任何提交。有什么我想念的吗？

<updateHandler class="solr.DirectUpdateHandler2">
    <updateLog>
        <str name="dir">${solr.ulog.dir:}</str>
    </updateLog>
   <autoSoftCommit>
        <maxDocs>1000</maxDocs>
        <maxTime>1200000</maxTime>
    </autoSoftCommit>
    <autoCommit>
        <maxDocs>10000</maxDocs>
        <maxTime>120000</maxTime> 
        <openSearcher>false</openSearcher>
    </autoCommit>
</updateHandler>

为什么 autoCommit 自己工作？

Answer 1

我认为这个article 对你有用。它详细解释了硬提交和软提交的工作原理，以及在调整系统时应考虑的权衡。

我总是对此感到不寒而栗，因为在某些情况下任何建议都会出错。我的第一个建议是不要过度思考这个问题。一些非常聪明的人试图使整个过程变得健壮。先尝试简单的事情，然后只在必要时进行调整。特别是，查看事务日志的大小并调整硬提交间隔以保持这些“合理大小”。请记住，如果在 JVM 崩溃后重新启动，惩罚主要是涉及的重放时间。 15秒可以忍受吗？那为什么要变小呢？

我们已经看到硬提交间隔比软提交间隔短得多的情况，请参阅下面的批量索引位。

这些是开始的地方。

重（散装）索引

这里的假设是您有兴趣尽快将大量数据添加到索引中，以便将来某个时候进行搜索。我在考虑数据源等的原始负载。

将您的软提交间隔设置得相当长。如在 10 分钟内。软提交是关于可见性的，我在这里的假设是批量索引不是近乎实时的搜索，所以不要做打开任何类型的搜索器的额外工作。 将硬提交间隔设置为 15 秒，openSearcher=false。再次假设您将只是在 Solr 上爆破数据。这里最糟糕的情况是您重新启动系统并且必须从 tlog 重播 15 秒左右的数据。如果您的系统比这更频繁地上下跳动，请先解决其原因。 只有在你尝试过简单的事情之后，你才应该考虑改进，它们通常只在特殊情况下才需要。但它们包括： 为批量加载操作完全关闭 tlog 使用某种 map-reduce 过程离线索引 每个分片只有一个领导者，没有用于负载的副本，然后打开副本并让它们进行旧式复制以迎头赶上。请注意，这是自动的，如果节点发现它与领导者“太远”不同步，它会启动旧式复制。在它赶上之后，它将获取文档，因为它们被索引到领导者并保留自己的 tlog。 等等

索引重，查询轻

我的意思是说，搜索日志文件。在这种情况下，您几乎一直有大量数据进入系统。但查询负载很轻，通常用于排查或分析使用情况。

将您的软提交间隔设置为相当长的时间，直至文档可见的最大延迟。这可能只是几分钟或更长时间。甚至可能需要几个小时才能发出硬提交 (openSearcher=true) 或按需软提交。 将你的硬提交设置为 15 秒，openSearcher=false

索引-轻、查询-轻或重

这是一个相对静态的索引，有时会出现少量索引。说每 5-10 分钟（或更长时间）进行一次更新

除非需要 NRT 功能，否则我会在这种情况下省略软提交，并在 openSearcher=true 的情况下每 5-10 分钟执行一次硬提交。在这种情况下，如果您使用单个外部索引进程进行索引，则让客户端发出硬提交可能是有意义的。

索引重，查询重

这是近实时 (NRT) 案例，确实是其中最棘手的案例。这需要实验，但这是我要开始的地方

将您的软提交间隔设置为您可以承受的时间。不要听你的产品经理说“我们需要不超过 1 秒的延迟”。真的。用力推回去，看看用户是否得到了最好的服务，或者甚至会注意到。软提交和 NRT 非常棒，但它们不是免费的。 将硬提交间隔设置为 15 秒。

在我的情况下（索引繁重，查询繁重），复制主从花费了太长时间，减慢了对从属的查询。通过将 softCommit 增加到 15 分钟并将 hardCommit 增加到 1 分钟，性能提升很大。现在复制工作没有问题，服务器每秒可以处理更多的请求。

虽然这是我的用例，但我意识到我真的不需要这些项目在主服务器上实时可用，因为主服务器仅用于索引项目，并且每次复制时从服务器中都有新项目可用周期（5分钟），这对我来说完全没问题。你应该根据你的情况调整这个参数。

Answer 2

软提交是关于可见性的。 硬提交是关于持久性的。 优化关乎性能。

软提交非常快，有变化是可见的，但这种变化不会持久（它们只在内存中）。所以在崩溃期间，这种变化可能是最后的。
硬提交更改会持久保存到磁盘。
优化类似于硬提交，但它也将 solr 索引段合并为单个段以提高性能。但它的成本非常高。

提交（硬提交）操作使索引更改对新的搜索请求可见。硬提交使用事务 log 获取最新文档更改的 id，并在索引文件上调用 fsync 以确保它们具有 已刷新到稳定存储，不会因断电而导致数据丢失。

软提交要快得多，因为它只使索引更改可见并且不同步索引文件或写入 一个新的索引描述符。如果 JVM 崩溃或断电，上次硬后发生的更改 提交将丢失。具有 NRT 要求的搜索集合（希望索引更改快速 搜索可见）将希望经常进行软提交，但不太频繁地进行硬提交。一个 softCommit 可能是“更少 昂贵”的时间，但不是免费的，因为它会降低吞吐量。

优化类似于硬提交，只是它强制将所有索引段合并为一个 先分段。根据使用情况，此操作应该不经常执行（例如，每晚），如果有的话，因为 它涉及读取和重写整个索引。无论如何，段通常会随着时间的推移而合并（如 由合并策略决定），而优化只是强制这些合并立即发生。

auto commit properties we can manage from sorlconfig.xml files.
<autoCommit>
       <maxTime>1000</maxTime>
  </autoCommit>


    <!-- SoftAutoCommit

         Perform a 'soft' commit automatically under certain conditions.
         This commit avoids ensuring that data is synched to disk.

         maxDocs - Maximum number of documents to add since the last
                   soft commit before automaticly triggering a new soft commit.

         maxTime - Maximum amount of time in ms that is allowed to pass
                   since a document was added before automaticly
                   triggering a new soft commit.
      -->

     <autoSoftCommit>
       <maxTime>1000</maxTime>
     </autoSoftCommit>

参考资料：

https://wiki.apache.org/solr/SolrConfigXml

https://lucene.apache.org/solr/guide/6_6/index.html

Answer 3

对于硬提交，您有 openSearcher=false。这意味着即使提交发生了，搜索器也没有重新启动并且看不到更改。尝试更改该设置，您将不需要软提交。

SoftCommit 会重新打开搜索器。因此，如果您同时拥有这两个部分，软提交会显示新的更改（即使它们不是硬提交），并且 - 按照配置 - 硬提交会将它们保存到磁盘，但不会更改可见性。

这允许将软提交设置为 1 秒，并让文档快速显示并减少硬提交发生的频率。