UpdateHandlers in SolrConfig

UpdateHandlers in SolrConfig

On this Page

• Commits
  • commit and softCommit
  • autoCommit
  • commitWithin
• Event Listeners
• Transaction Log
• Other Options

UpdateHandlers in SolrConfig

本节中的设置是在solrconfig.xml中的<updateHandler>元素中配置的，可能会影响索引更新的性能。这些设置将影响如何在内部进行更新。<updateHandler>配置不影响RequestHandlers处理客户端的update请求的更高级的配置。

<updateHandler class="solr.DirectUpdateHandler2">
  ...
</updateHandler>

Commits

发送到Solr的数据在提交到索引之前是不能搜索的。这样做的原因是，在一些情况下，提交比较慢，并且多个更新请求应该进行隔离，以避免覆盖数据。因此，最好对何时提交数据进行控制。有几个选项可用于控制提交的时间。

commit and softCommit

在Solr中，提交是要求Solr“提交”那些更改到Lucene索引文件的操作。默认情况下，提交操作会导致“hard commit”所有Lucene索引文件保存到稳定存储(磁盘)上。当客户端在更新请求中包含commit=true参数时，这将确保在索引更新完成后，所有添加和删除操作影响的索引段都被写入磁盘。

如果指定了另一个标志softCommit=true，那么Solr将执行一个“soft commit”，这意味着Solr将快速地将您的更改提交到Lucene数据结构中，但不能保证将Lucene索引文件写入到稳定的存储中。这是一种接近实时存储的实现，这是一种提高文档可见性的特性，因为您不必等待后台合并和存储(对于ZooKeeper来说，如果使用SolrCloud的话)完成后再进行其他操作。完整的提交意味着，如果服务器崩溃，Solr将准确地知道数据存储的位置; soft commit 交意味着存储了数据，但还没有存储位置信息。软提交的权衡之处在于，它提供了更快的可见性，因为它不需要等待后台完成merge。

For more information about Near Real Time operations, see Near Real Time Searching.

autoCommit。

这些设置将控制挂起的更新自动推送到索引的频率。autoCommit交的另一种选择是使用commitWithin，它可以在向Solr发出更新请求时定义。或在更新请求程序中。

1. maxDocs。
   自上次提交以来发生的更新数量。

2. maxTime。
   从最早未提交更新开始的毫秒数。

3. maxSize。
   磁盘上事务日志(tlog)的最大大小，在此之后触发hard commit。当文档的大小未知并且想将tlog的大小限制在合理的大小时，这很有用。有效值可以是字节(默认没有后缀)、千字节(如果用k后缀定义，如25k)、兆字节(m)或千兆字节(g)。

4. openSearcher。
   执行提交时是否打开新的搜索器。如果为false，则提交将把最近的索引更改刷新到稳定存储，但不会打开新的搜索器以使这些更改可见。默认值为true。

如果达到了maxDocs、maxTime或maxSize的任何限制，Solr将自动执行提交操作。如果autoCommit未设置，那么只有显式的commit将更新索引。是否使用auto-commit取决于应用程序的需要。

确定最佳的auto-commit 设置是性能和准确性之间的权衡。频繁更新的设置将提高搜索的准确性，因为新的内容将被更快地搜索，但性能可能会因为频繁更新而受到影响。较少的更新可能会提高性能，但是更新在查询中显示需要更长的时间。

<autoCommit>
  <maxDocs>10000</maxDocs>
  <maxTime>30000</maxTime>
  <maxSize>512m</maxSize>
  <openSearcher>false</openSearcher>
</autoCommit>

你也可以像指定'soft' commits一样指定'soft' autoCommits ，除了你设置了autoSoftCommit标签而不是autoCommit。

<autoSoftCommit>
  <maxTime>60000</maxTime>
</autoSoftCommit>

commitWithin

设置中的commitWithin允许强制文档提交在定义的时间段内发生。这最常用于Near Real Time Searching，因此默认执行soft commit。但是，这并不会将新文档复制到主/从环境中的从服务器。如果这是您实现的要求，您可以通过添加参数强制hard commit，如本例所示:

<commitWithin>
  <softCommit>false</softCommit>
</commitWithin>

使用此配置，当您在更新消息中调用commitWithin时，它将每次自动执行一次hard commit。

Transaction Log

如RealTime Get一节中所述，该特性需要transaction log 。它在solrconfig.xml的updateHandler部分中配置。

Realtime Get目前依赖于update log特性，该特性在默认情况下是启用的。它依赖于在solrconfig中配置的更新日志:

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
</updateLog>

另外三个专家级配置设置会影响索引性能和副本在进入完全恢复之前的更新延迟程度——更多信息请参阅write side fault tolerance:

1. numRecordsToKeep. 每个日志中要保存的更新记录的数量。默认值是100。
2. maxNumLogsToKeep. 保留的日志的最大数量。默认值是10。
3. numVersionBuckets. 当重建索引进行update检测时，保持最大版本的bucket的数量;增加这个值可以减少大容量索引期间同步访问版本桶的成本，这需要每个Solr核心的堆空间(8 bytes (long) * numVersionBuckets)。默认值是65536。

例如，将包含在solrconfig.xml中的<config><updateHandler>，采用上述高级设置:

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
  <int name="numRecordsToKeep">500</int>
  <int name="maxNumLogsToKeep">20</int>
  <int name="numVersionBuckets">65536</int>
</updateLog>

Other Options

在某些情况下，复杂的更新(如spatial/shape)可能需要很长时间才能完成。在默认配置中，属于同一内部版本桶的其他更新将无限期地等待，最终这些未完成的请求可能会堆积起来，导致线程耗尽，最终导致OutOfMemory错误。

updateHandler部分中的选项versionBucketLockTimeoutMs通过为这种非常长时间运行的更新请求指定有限的超时来防止这种情况发生。如果达到这个限制，这个更新将失败，它不会永远阻止所有其他更新。更多细节请参见SOLR-12833。

与此设置相关的内存开销。大于默认值0(意味着无限制超时)的值会导致Solr使用版本桶的不同内部实现，这将每个Solr核心的内存消耗从_{1.5MB增加到}6.8MB。

<updateHandler class="solr.DirectUpdateHandler2">
  ...
  <int name="versionBucketLockTimeoutMs">10000</int>
</updateHandler>