solr 近实时搜索

孤独750

　　摘要： 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>