Solr学习笔记 - 关于近实时搜索

2020-08-03 10:30:02 浏览数 (1)

从solr官方文档上看，有关solr搜索实时性的文章大概有：

  1. 关于updateHandler：UpdateHandlers in SolrConfig
  2. 关于近实时搜索：Near Real Time Searching

UpdateHandlers

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

UpdateHandlers in SolrConfig

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

代码语言：txt复制
<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索引文件写入到稳定的存储中。这是一种接近实时存储的实现，这是一种提高文档可见性的特性，因为您不必等待后台合并和存储完成后再进行其他操作(如果使用SolrCloud的话，对于ZooKeeper来说)。完整的提交意味着，如果服务器崩溃，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 设置是性能和准确性之间的权衡。频繁更新的设置将提高搜索的准确性，因为新的内容将被更快地搜索，但性能可能会因为频繁更新而受到影响。较少的更新可能会提高性能，但是更新在查询中显示需要更长的时间。

代码语言：txt复制
<autoCommit>
  <maxDocs>10000</maxDocs>
  <maxTime>30000</maxTime>
  <maxSize>512m</maxSize>
  <openSearcher>false</openSearcher>
</autoCommit>

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

代码语言：txt复制
<autoSoftCommit>
  <maxTime>60000</maxTime>
</autoSoftCommit>
commitWithin

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

代码语言：txt复制
<commitWithin>
  <softCommit>false</softCommit>
</commitWithin>

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

Transaction Log

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

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

代码语言：txt复制
<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>，采用上述高级设置:

代码语言：txt复制
<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。

代码语言：txt复制
<updateHandler class="solr.DirectUpdateHandler2">
  ...
  <int name="versionBucketLockTimeoutMs">10000</int>
</updateHandler>

Near Real Time Searching

  • Commits and Searching
    • Transaction Logs(tlogs)
    • Configuring Commits
  • Advanced Commit Options

Near Real Time (NRT) search 意味着文档被编入索引后不久就可以进行搜索。NRT搜索是SolrCloud的主要特性之一，在master/slave配置中很少尝试。

文档的持久性和可搜索性是由commits控制的。“Near”在“Near Real Time”是可配置的，以满足您的应用程序的需要。提交可以是“hard”提交，也可以是“soft”提交，可以由客户端(比如SolrJ)通过REST调用发出，也可以配置为在solrconfig.xml中自动执行。通常给出的建议是在solrconfig.xml中配置提交策略(见下面)，并避免从外部发出提交。

通常在NRT应用程序中，hard commits配置为openSearcher=false，而soft commits配置为使文档对搜索可见。

当发生提交时，会启动各种后台任务，例如合并段。这些后台任务不会阻止对索引的额外更新，也不会延迟文档的搜索可用性。

在为NRT配置时，要特别注意cache和autowarm设置，因为它们会对NRT性能产生重大影响。对于非常短的自动提交间隔，考虑完全禁用caching和autowarming。

Commits and Searching

hard commit 调用fsync进行索引化文件，以确保它们已被刷新到稳定的存储上。当前的事务日志将被关闭，并打开一个新的事务日志。请参阅下面的“transaction log”讨论，了解在没有hard commit的情况下如何恢复数据。hard commit还可以选择性地使文档在搜索中可见，但是不建议在NRT搜索中这样做，因为它比soft commit的开销更大。

soft commit 更快，因为它只使得索引更改可见，而不fsync索引文件，启动一个新的段或启动一个新的事务日志。有NRT需求的collections需要soft commit，以满足应用程序的可见性需求。soft commit可能比hard commit“更少的开销”(openSearcher=true)，但它不是免费的。建议在应用程序需求合理的情况下设置此值。

hard commit和soft commit都有两个主要的配置参数: maxDocs 和 maxTime。

maxDocs

Integer。定义激活前要处理的更新数量。

maxTime

Integer。激活前等待的毫秒数。

如果指定了这两个参数，则使用第一个过期的参数。一般来说，最好使用maxTime而不是maxDocs，特别是在批量索引大量文档时。明智地使用maxDocs和maxTime来调整提交策略。

hard commit有一个额外的参数openSearcher

openSearcher

true|false, 是否使文档对搜索可见。对于NRT应用程序，这通常被设置为false。由soft commit控制文档对搜索的可见性。

Transaction Logs

事务日志是自上次hard commit以来更新的“滚动窗口”。每次发生任何类型的hard commit时，都会关闭当前事务日志，打开一个新的事务日志。Soft commits对事务日志没有影响。

启用tlogs时，添加到索引中的文档将在索引调用返回到客户机之前写入tlog。在发生不适当的关闭(电源丢失、JVM崩溃、kill -9等)时，任何写入tlog但在Solr停止时还没有通过hard commit提交的文档都将在启动时重新播放。因此数据不会丢失。

当Solr被优雅地关闭时(使用bin/Solr stop命令)，Solr将关闭tlog文件和索引段，因此在启动时不需要重播。

令人困惑的一点是事务日志中包含多少数据。tlog不包含所有文档，只包含上次硬提交之后的文档。旧的事务日志文件在不再需要时被删除。

上面隐含的意思是，如果禁用了硬提交，事务日志将永远增长。因此，索引时启用硬提交是很重要的。

Configuring Commits

如上所述，通常最好在solrconfig.xml中配置提交(hard and soft)，避免从外部源发送提交。检查您的solrconfig.xml文件，因为默认值可能没有调整到您的需要。下面是两种提交方式的NRT配置示例:每60秒一次的hard commit和每30秒一次的soft commit。注意，这些不是一些示例中的值!

代码语言：txt复制
<autoCommit>
  <maxTime>${solr.autoCommit.maxTime:60000}</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

<autoSoftCommit>
   <maxTime>${solr.autoSoftCommit.maxTime:30000}</maxTime>
</autoSoftCommit>

可以在运行时通过定义Java“系统变量”来覆盖这些参数，例如指定-Dsolr.autoCommit.maxTime=15000. 将以15秒的值覆盖hard commit间隔。

autoCommit (openSearcher=false)和autoSoftCommit的选择有不同的结果。如果出现非法的关闭，Solr可能需要autoCommit中指定的时间重播事务日志中未提交的文档。

autoSoftCommit所选择的时间决定了文档发送到Solr之后，在它变为可搜索且不影响事务日志之前的最长时间。为这个值选择应用程序所能容忍的时间间隔，通常15-60秒是合理的，甚至更长，这取决于需求。在时间间隔设置为非常短的情况下(比如1秒)，考虑禁用缓存(尤其是queryResultCache和filterCache)，因为它们没有什么效用。

对于非常高的批量索引，特别是对于没有搜索的初始加载，考虑通过为maxTime参数指定一个值-1来关闭autoSoftCommit。

Advanced Commit Options

所有类型的提交都可以从SolrJ客户机或通过URL调用。通常的建议是不要从外部调用提交。如果需要，请参阅更新命令。这些选项用于可从浏览器或curl等发出的XML更新命令，而相应的选项可从SolrJ客户机获得。

lucene/solr android xml

0 人点赞