我很困惑和。这是我理解的
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会独立工作？
答案 0 :(得分：32)
我认为这个article对您有用。它详细解释了硬提交和软提交的工作原理，以及在调整系统时应该考虑的权衡。
我总是对此感到不寒而栗，因为在某些情况下任何建议都是错误的。我的第一个建议是不要过度思考这个问题。一些非常聪明的人试图使整个过程变得强大。首先尝试简单的事情，只在必要时调整一下。特别是，查看事务日志的大小并调整硬提交间隔以保持这些“合理大小”。请记住，如果在JVM崩溃后重新启动，则惩罚主要是重播时间。 15秒可以忍受吗？为什么要小一点？
我们已经看到硬提交间隔比软提交间隔短得多的情况，请参阅下面的批量索引位。
这些是开始的地方。
重（大宗）指数
这里的假设是，您有兴趣在将来的某个时间尽快为索引获取大量数据。我正在考虑数据源的原始负载等。
将软提交间隔设置得相当长。在10分钟。软提交是关于可见性的，我的假设是批量索引不是近实时搜索，所以不要做任何类型的搜索器的额外工作。 将硬提交间隔设置为15秒，openSearcher = false。再次假设您将在Solr处爆炸数据。这里最糟糕的情况是你重新启动你的系统并且必须从你的tlog中重放15秒左右的数据。如果您的系统比这更频繁地上下跳动，请先解决原因。 只有在你尝试过简单的事情之后，你应该考虑改进，它们通常只在特殊情况下才需要。但它们包括： 完全关闭批量加载操作的tlog 使用某种map-reduce进程离线索引 每个分片只有一个领导者，没有负载的副本，然后打开副本并让他们进行旧式复制以赶上。请注意，这是自动的，如果节点发现它与领导者“太远”不同步，则会启动旧式复制。在它赶上之后，它将获得文档，因为它们被索引到领导者并保留自己的tlog。 等
INDEX-HEAVY，QUERY-LIGHT
我的意思是说，搜索日志文件。在这种情况下，您可以在系统中随时获得大量数据。但查询负载非常轻，通常用于排除故障或分析使用情况。
将软提交间隔设置得相当长，直到您可以看到文档可见的最大延迟。这可能只需几分钟或更长时间。甚至可能需要几小时才能发出硬提交（openSearcher = true）或软提交。 将您的硬提交设置为15秒，openSearcher = false INDEX-LIGHT，QUERY-LIGHT或HEAVY
这是一个相对静态的索引，有时会获得一小段索引。每隔5-10分钟（或更长时间）说一次更新
除非需要NRT功能，否则在这种情况下我会省略软提交，并且使用openSearcher = true每隔5-10分钟进行一次硬提交。在这种情况下，如果您使用单个外部索引进程进行索引，则让客户端发出硬提交可能是有意义的。
INDEX-HEAVY，QUERY-HEAVY
这是近实时（NRT）案例，实际上是最棘手的。这个将需要实验，但这是我开始的地方
尽可能长时间设置软提交间隔。不要听你的产品经理说“我们需要不超过1秒的延迟”。真。向后推，看看用户是否得到最好的服务，或者甚至会注意到。软提交和NRT非常惊人，但它们并不是免费的。 将您的硬提交间隔设置为15秒。
在我的情况下（索引很重，查询繁重），复制主从的时间太长，从而减慢了对从服务器的查询速度。通过将softCommit增加到15min并将hardCommit增加到1min，性能提升很好。现在复制没有问题，服务器每秒可以处理更多的请求。
这是我的用例，但我意识到我并不需要实时在主服务器上提供这些项目，因为主服务器仅用于索引项目，并且每个复制都可以在从服务器中使用新项目循环（5分钟），这对我的情况完全没问题。你应该根据你的情况调整这些参数。
答案 1 :(得分：29)
对于硬提交，您有openSearcher = false。这意味着即使提交发生，搜索者也没有重新启动，也看不到更改。尝试更改该设置，您将不需要软提交。
SoftCommit会重新打开搜索者。因此，如果您同时拥有这两个部分，则软提交会显示新的更改（即使它们不是硬提交的），并且 - 如配置的那样 - 硬提交将它们保存到磁盘，但不会更改可见性。
这允许将软提交设置为1秒，并且文档快速显示并且难以进行硬提交。
答案 2 :(得分：-2)
软提交是关于可见性的。 硬提交是关于耐久性的。 优化是关于绩效。
软提交非常快，可见变化但这种变化不会持续存在（它们只在内存中）。因此在崩溃期间，这种变化可能是最后的。
硬提交更改持续到磁盘
优化就像硬提交一样，但它也将solr索引段合并为一个段以提高性能。但它的成本非常高。
提交（硬提交）操作使索引更改对新搜索请求可见。硬提交使用该事务 log获取最新文档更改的ID，并在索引文件上调用fsync以确保它们具有 已被冲洗至稳定存储，电源故障不会导致数据丢失。
软提交要快得多，因为它只能使索引更改可见，并且不会fsync索引文件或写入 一个新的索引描述符。如果JVM崩溃或断电，则在最后一次硬盘后发生更改 提交将丢失。搜索具有NRT要求的集合（希望快速进行索引更改） 对搜索可见的）会想要经常进行软提交，但是硬提交频率较低。 softCommit可能更少 昂贵＆＃34;在时间方面，但不是免费的，因为它可以降低吞吐量。
优化就像硬提交一样，只是强制所有索引段合并为一个 细分第一。根据使用情况，该操作应该不经常进行（例如，每晚），如果有的话，应该进行 它涉及阅读和重写整个索引。无论如何，细分通常会随着时间的推移而合并（如 由合并政策决定），并优化只是迫使这些合并立即发生。
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>
参考文献：