摘要: Solr 的近实时搜索 NRT(Near Real Time Searching)意味着文档可以在索引以后马上可以被查询到。
Solr 不会因为本次提交而阻塞更新操作,不会等待后台合并操作(merge)的完成而是直接检索索引并返回数据 参见原文
利用 NRT,就可以设置 soft commit,因为标准的 commit 操作代价高昂,soft commit 可以做到近乎实时的查询效果而不丢失数据。
一个 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 到索引一次 |
使用 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 操作使得测试文档被插入后可以立即生效:
- 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 会使文档在一个确定的时间段内 commit,因此常常用于 NRT 检索。但是,对于 master/slave 环境,可能会导致新的文档不能复制到 slave 中(因为只有 commit 操作才会触发复制机制,softcommit 不会使 replicate 生效)。如果你需要这样的做,那就只能使用 hard commit 了,例如:
- <commitWithin>
- <softCommit>false</softCommit>
- </commitWithin>