solr 近实时搜索
摘要： 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>
页:
[1]