solr 的软提交和硬提交

Question

摘要： Solr 的近实时搜索 NRT（Near Real Time Searching）意味着文档可以在索引以后马上可以被查询到。

Solr 不会因为本次提交而阻塞更新操作，不会等待后台合并操作（merge）的完成而是直接检索索引并返回数据 参见原文

利用 NRT，就可以设置 soft commit，因为标准的 commit 操作代价高昂，soft commit 可以做到近乎实时的查询效果而不丢失数据。

Commits 与 Optimizing

一个 commit 操作可以使新的查询请求能够感知到索引的变化，一般使用的 hard commit 通过事务的方式确保数据是最新的，并且会有同步方法（fsync）的调用确保数据能持久化。而 soft commit 效率高是因为没有调用同步方法，这样的话，一旦 JVM 崩溃，可能会丢失数据。使用 NRT 可以使 Solr 多做 soft commit 而少一点 hard commit。

我们所使用的 optimize 很像 hard commit，不同的是它会强制将所有的索引片段合并为一个。一般我们很少使用它，因为它会重写整个索引。正常情况下，片段合并会根据配置自动进行，调用 optimize 只是手动加快了这一进程。

对于 soft commit，常用下面两个参数：

参数	说明
maxDocs	int 型，每多少个文档 push 到索引一次
maxTime	long 型，每多少毫秒 push 到索引一次

Auto commit

使用 autocommit 也可以使用上面两个参数 maxDocs 和 maxTime。

一般，设置 autocommit 为每 1-10 分钟一次，设置 autosoftcommit 为每秒一次。这样的话，新的文档就可以在 1 秒内被添加到索引，就算出现意外，丢 失的数据也只是上一次 hard commit 之后添加的数据。

<autoSoftCommit> 
    <maxTime>1000</maxTime> 
</autoSoftCommit>

这是一段 commit 的配置，从经验角度，配置 maxTime 参数比 maxDocs 效果好，尤其是索引量很大的时候。一般还建议对于批处理的索引请求关闭 autoSoftCommit 功能。

其他的参数

参数	参考值（默认）	说明
waitSearcher	布尔（true）	新的搜索器打开并注册为主查询搜索器之前，是否阻塞查询
softCommit	布尔（false）	是否执行 softCommit
expungeDeletes	布尔（false）	仅针对 commit，是否清理掉已经delete的数据
maxSegments	整数（1）	优化为多少个片段 segments

下面就是一个配置片段：

<commit waitSearcher="false"/>
<commit waitSearcher="false" expungeDeletes="true"/>
<optimize waitSearcher="false"/>

在 URL 中使用 commit 参数

下面的 URL 使用了 commit 操作使得测试文档被插入后可以立即生效：

http://localhost:8983/solr/core0/update?stream.body=<add><doc> 
<field name="id">testdoc</field></doc></add>&commit=true

接下来，你可能会用到下面这个URL：

http://localhost:8983/solr/core0/update?stream.body=<optimize/>

还可以添加更多的参数，比如优化为 10 个片段，不需要等待操作结束：

http://localhost:8983/solr/core0/update?optimize=true&maxSegments=10&waitFlush=false

改变默认的 commitWithin 行为

参数 commitWithin 会使文档在一个确定的时间段内 commit，因此常常用于 NRT 检索。但是，对于 master/slave 环境，可能会导致新的文档不能复制到 slave 中（因为只有 commit 操作才会触发复制机制，softcommit 不会使 replicate 生效）。如果你需要这样的做，那就只能使用 hard commit 了，例如：

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