标签：head 插入 apach 设置 blog wiki bsp mit optimize
摘要： 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>
标签：head 插入 apach 设置 blog wiki bsp mit optimize
原文地址：http://www.cnblogs.com/faunjoe88/p/7131334.html
