SOLR autoCommit vs autoSoftCommit

Question

我很困惑和。以下是我的理解

• autoSoftCommit - 一个autoSoftCommit后，如果该SOLR服务器出现故障，autoSoftCommit文档都将丢失。

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

我的下面的配置似乎只与使用autoSoftCommit。自动提交自己似乎没有做任何提交。有什么我失踪？

<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

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

我总是不寒而栗，因为在某些情况下，任何建议都是错误的。我的第一个建议是不要过问这个问题。一些非常聪明的人试图使整个过程稳健。首先尝试简单的事情，并根据需要调整事物。特别是，查看事务日志的大小并调整您的硬提交间隔以保持这些“合理大小”。请记住，如果在JVM崩溃后重新启动，那么惩罚主要是涉及重播时间。 15秒是可以忍受的吗？为什么要小一点呢？

我们已经看到硬提交间隔远小于软提交间隔的情况，请参阅下面的批量索引位。

这些是开始的地方。

HEAVY（散装）分度

这里的假设是，你有兴趣在未来获得大量数据的索引尽快搜索某个时候。我正在考虑数据源的原始负载等。

将您的软提交间隔设置得相当长。在10分钟内。软承诺是关于可见性的，这里我的假设是批量索引不是关于实时搜索，所以不要做任何打开任何搜索器的额外工作。 将您的硬提交间隔设置为15秒，openSearcher = false。再一次假设是，你将只是在Solr爆炸数据。这里最糟糕的情况是，您重新启动系统，必须重播您的tlog中15秒左右的数据。如果您的系统比此更频繁地弹起，请首先确定原因。 只有在您尝试过简单的事情之后，才会考虑优化，通常只有在特殊情况下才需要。但是它们包括： 为批量加载操作完全关闭tlog 使用某种映射减少过程进行脱机索引 只有每个碎片有一个引导程序，没有负载副本，稍后打开副本并让它们执行旧式复制追赶。请注意，这是自动的，如果节点发现它与领导者“太远”不同步，它会启动旧式复制。追上之后，它会在文档被索引到领导者并保留自己的tlog时获得文档。 等

指数重，QUERY-LIGHT

我的意思是，比如，搜索日志文件。这种情况下，几乎所有的时间都有很多数据进入系统。但查询负载很轻，通常用于排查或分析使用情况。

将您的软提交间隔设置得相当长，最长可达到文档可见的最大延迟时间。这可能只是几分钟或更长时间。甚至可能需要数小时才能发出硬提交（openSearcher = true）或按需提交软提交。 设置您的硬盘提交到15秒，openSearcher =假 INDEX-LIGHT，查询轻或重

这是一个相对静态的指标，有时得到的索引的一个小爆裂。假设每5-10分钟（或更长时间）进行一次更新

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

指数重，QUERY重

这是近实时（NRT）的情况下，并且是真正的最棘手的地段。这将需要实验，但这里是我开始的地方

设置你的软提交间隔，只要你能站立。不要听你的产品经理说“我们需要不超过1秒的延迟”。真。推回去，看看用户是最好的服务，甚至会注意到。软承诺和NRT是相当惊人的，但他们不是免费的。 将您的硬提交间隔设置为15秒。

在我的情况下（索引繁重，查询繁重），复制主从需要很长的时间，从而减慢了查询的速度。通过将softCommit增加到15min并将hardCommit增加到1min，性能改进非常好。现在复制可以毫无问题地工作，而且服务器每秒可以处理更多的请求。

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

Answer 3

软提交是关于可见性。硬承诺是关于耐久性。优化是关于性能。

软提交的速度非常快，有变化是显而易见的，但这种变化不会持续（它们只在内存中）。所以坠毁的变化可能是最后的期间。
硬提交更改持久存储到磁盘。
优化是像辛勤承诺，但它也合并Solr的索引段到一个单一的段提高性能。但它是非常昂贵的。

一个提交（硬提交）操作使得指数的变化，以新的搜索请求可见。硬提交使用事务日志 得到的最新文件的变化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