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

您有用于硬提交的openSearcher=false。这意味着，即使发生了提交，搜索程序仍未重新启动，无法看到更改。尝试更改该设置，您将不需要软提交。

SoftCommit确实会重新打开搜索程序。因此，如果这两个部分都有，软提交将显示新的更改(即使它们不是硬提交的)，并且--按照配置--硬提交将它们保存到磁盘，但不会更改可见性。

这允许将软提交设置为1秒，并使文档快速显示，而硬提交发生的频率较低。

Answer 2

我认为这个文章对你是有用的。它详细解释了如何进行硬提交和软提交工作，以及在优化您的系统时应该考虑的权衡。

我对此总是不寒而栗，因为在某些情况下，任何建议都是错误的。我的第一个建议是不要过分考虑这个问题。一些非常聪明的人试图使整个过程变得健壮。先尝试简单的事情，必要时只对事情做些调整。特别是，查看事务日志的大小，并调整硬提交间隔以保持这些“合理大小”。请记住，如果您在JVM崩溃后重新启动，那么代价主要是重播时间。15秒可以忍受吗？那为什么变小呢？ 我们已经看到硬提交间隔比软提交间隔短得多的情况，请参阅下面的批量索引位。 这里是开始的地方。 重(批量)索引 这里的假设是，您感兴趣的是尽快获取大量数据到索引中，以便在将来的某个时候进行搜索。我认为原始负载的数据源等等。 设置您的软提交间隔相当长。作为in10分钟。软提交是关于可见性的，我在这里的假设是，批量索引并不是关于近乎实时的搜索，所以不要做打开任何类型搜索器的额外工作。将硬提交间隔设置为15秒，openSearcher=false。同样的假设是，你将仅仅是在Solr上进行数据爆破。最糟糕的情况是，您重新启动系统，并必须重播15秒左右的数据从您的tlog。如果您的系统比这更频繁地上下跳，那么首先修复原因。只有在你尝试了简单的事情之后，你才应该考虑改进，它们通常只有在不寻常的情况下才会被要求。但它们包括:完全关闭tlog，为批量加载操作建立离线索引，使用某种映射减少进程，每个碎片只有一个领导者，加载时没有副本，然后稍后打开副本，让它们进行旧式复制以迎头赶上。注意，这是自动的，如果节点发现它与领导者“太远”不同步，它就会启动一个旧的复制。在它赶上之后，它将获得文档，因为它们被编入了领导者的索引，并保留了自己的tlog。等。 索引重，查询量小 我是说，比如说，搜索日志文件。在这种情况下，大量的数据总是出现在系统中。但是，查询负载非常轻，通常用于故障排除或分析使用情况。 设置您的软提交间隔相当长，最大的延迟，您可以支持文档是可见的。这可能只需要几分钟或更长时间。可能甚至几个小时都有发出硬提交(openSearcher=true)或按需软提交的能力。把你的努力时间设为15秒，openSearcher=false 索引-轻型，查询-轻或重 这是一个相对静态的索引，有时会得到少量的索引。每隔5-10分钟(或更长时间)进行一次更新。 除非需要NRT功能，否则在这种情况下，我将省略软提交，并在使用openSearcher=true时每5-10分钟执行一次硬提交。在这种情况下，如果使用单个外部索引过程进行索引，则让客户端发出硬提交可能是有意义的。 索引重，查询重 这是近实时(NRT)的案例，也是最棘手的问题。这一次需要实验，但我要从这里开始 将您的软提交间隔设置到尽可能长的时间内。不要听你的产品经理说“我们不需要超过1秒的延迟”。真的。使劲向后推，看看用户是否得到了最好的服务，甚至会注意到。软提交和NRT是相当惊人的，但它们不是免费的。将硬提交间隔设置为15秒。

在我的例子中(索引重，查询重)，复制主从耗时太长，减缓了对从机的查询速度。通过将softCommit提高到15 1min，hardCommit提高到1 1min，性能得到了很大的提高。现在，复制没有问题，服务器可以每秒处理更多的请求。

不过，这是我的用例，我意识到我真的不需要在主服务器上实时提供这些项，因为主服务器只用于索引项，并且在每个复制周期(5分钟)的从站中都有新的项可用，这对我的案例来说是完全可以的。您应该为您的情况调优此参数。

Answer 3

软提交是关于可见度的。艰难的承诺是关于耐用性的。优化是关于性能的。

软提交非常快，更改是可见的，但这些更改不会持久(它们仅在内存中)，.So在崩溃期间--这种更改可能是最后一次。

硬提交更改将持久化到磁盘。

优化类似于硬提交，但它也将solr索引段合并到一个单独的段中，以提高性能，.But非常昂贵。

提交(硬提交)操作使索引更改对新的搜索请求可见。硬提交使用事务日志获取最新文档更改的id，并对索引文件调用fsync，以确保索引文件已被刷新到稳定存储，并且不会因停电而造成数据丢失。

软提交要快得多，因为它只会使索引更改可见，而不会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

6/index.html