29

我很困惑 and 。这是我的理解

  • 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 自己工作？

4

3 回答 3

40

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

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

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

这些是开始的地方。

重（散装）索引

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

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

索引重，查询轻

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

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

索引灯，查询灯或重

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

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

索引重，查询重

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

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

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

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

于 2013-10-30T12:19:56.467 回答
33

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

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

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

于 2013-07-16T01:24:42.060 回答
1

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

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

提交（硬提交）操作使索引更改对新的搜索请求可见。硬提交使用事务日志获取最新文档更改的 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

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

于 2017-12-21T11:05:00.447 回答