solr实时思路

左手的ㄟ右手 2022-04-21 15:04 314阅读 0赞

\[b\]\[color=green\]\[size=medium\]  
  
【转】http://www.tnove.com/?p=331  
  
在solr中，实时搜索有3种方案，①soft commit，这其实是近实时搜索，不能完全实时。②RealTimeGet，这是实时，但只支持根据文档ID的查询。③和第一种类似，只是触发softcommit。综上，其实是由实时（②）和近实时（①③）两种。  
  
  
本文主要介绍solr4.0 之后使用NRT的方法和需要的配置，同时介绍下commit相关的一些命令的使用效果  
NRT方案 1  
  
使用soft commit达到近实时搜索的效果。http://sling2007.blog.163.com/blog/static/84732713201391745435121/这里可以看到为什么是近实时搜索。  
  
为了使用soft commit ，我们需要配置solrconfig.xml。其中两个地方需要修改  
  
a.  
  
<autoCommit>  
<maxDocs>10000</maxDocs>   
<maxTime>15000</maxTime>   
<openSearcher>false</openSearcher>   
</autoCommit>  
  
这里需要将hard commit 的 openSearcher改为true。Hard commit时间根据自己系统承载能力和需要设置。因为hard commit动作较大，对性能有较大影响。原则稍长较好，但又不能太长，以免突然断电导致大量数据丢失（hard commit前数据都在memery中）。  
  
b.  
  
  
<autoSoftCommit>  
<maxTime>2000</maxTime>  
</autoSoftCommit>  
  
将soft commit 打开（默认配置注释了该节点），这里的时间是你希望在几秒内搜到，此处我的设置为2s。可根据需要设置，值越小NRT效果越好，相反的，会带来性能上的影 响。如果索引请求量不是特别大，则可以将值设小点，比如1000.不建议小于1000，小于1000并没有意义。  
  
设置a，b之后就可通过普通的SearchHandler 搜到到了。Solr 默认配置的SearchHandler REST接口有“/select”“/query”“/browse”。  
  
值得注意的是：当索引请求量巨大时，solr并不一定能保证在你设置的时间内能立马搜索到最新的文档，通常会有秒级别的延迟。  
NRT方案 2  
  
另外一种使用NRT的方法同样需要配置NRT1中的a项。  
  
此外还要配置solrconfig.xml的RealTimeGetHandler。根据solr的文档。该Handler有如下特性：  
  
realtime get handler, guaranteed to return the latest stored fields of any document,  
without the need to commit or open a new searcher. The current implementation relies  
on the updateLog feature being enabled.  
  
  
该搜索Handler的接口为“/get”。该接口使用了一个特定的组件RealTimeGetComponent，该接口会通用solrCore的 getRealtimeSearcher()方法，后者会先搜索一下updateLog，再做普通搜索。至于该接口是否有效，作者还没使用过。  
NRT方案 3  
  
第3种使用NRT的方法依然需要配置NRT1中的a项。这次使用普通的SearchHandler来实现NRT。利用solr的commit和 commitwithin。实现方式是每次索引文档后都明确的发送一个commit或者commitwithin命令。这样也可以马上搜索刚索引的数据。 由于发送命令需要走网络，时间上有不确定性，总体速度也不如NRT1。这里commit为hard commit请求，方法为commit=true；commitwithin为softcommit请求，方法为commitwithin=2000. 从前所述可以看出同样是commit，是用commitwithin将能更快搜到新文档，此处表示2s内要完成softcommit。该方法灵活性较高， 适合在一些特殊情况下使用。  
  
综上，虽然我们可以通过不同手段（包括变相的手段NRT3）来实现NRT。但NRT1中的配置softcommit的方式才是最佳选择，这也是其存在的价值。但是在一些特殊的应用场景可以根据需要使用NRT3。比如，索引频繁而搜索量很小。  
solrj客户端  
  
  
如果我们使用solrj的客户端操作，  
  
执行下面操作的时候  
  
server.add(docs);  
  
server.commit();  
  
可以看到后台日志的默认参数是：  
  
optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false  
  
用下面的方式操作的时候  
  
UpdateRequest req = new UpdateRequest();  
req.setCommitWithin(60000);  
req.add(docs);  
UpdateResponse res = req.process(server);  
  
可以看到，默认参数是：  
  
optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true  
主要的不同在于softCommit的参数。  
当然也可以用org.apache.solr.client.solrj.request.AbstractUpdateRequest.setAction(ACTION action, boolean waitFlush, boolean waitSearcher)来逐个设置。  
  
  
Commit  
  
上面提到的commit，其实在NRT及非NRT的情况下都会涉及到。Solr支持的commit 方式有两种。并且在不同情况下会有些有趣的情况出现。下面我们就介绍下几种commit的case。  
  
直接在发送commit=true或commitwithin=2000的参数提交commit请求。  
发送索引内容为的索引数据 。这种情况下可以对commit进一步设置参数：  
  
waitFlush = "true" | "false" — default is true — block until index changes are flushed to disk  
waitSearcher = "true" | "false" — default is true — block until a new searcher is opened and registered as the main query searcher, making the changes visible.  
softCommit = "true" | "false" — default is false — perform a soft commit - this will refresh the 'view' of the index in a more performant manner, but without "on-disk" guarantees  
expungeDeletes = "true" | "false" — default is false — merge segments with deletes away.  
  
注：waitFlush在solr1.4之前支持，4.0之后已被取消。  
  
例子：  
  
3. 发送普通索引数据的同时带上commit参数。  
  
例子：curl http://localhost:8983/solr/update?commitWithin=3000 -H "Content-Type: text/xml" --data-binary 'testdoc'  
  
Case 3存在一个特殊例子，值得注意：当发送该 类型请求到leader节点，所有replica节点将可以马上搜索到该请求的文档。如果请求发送至replica节点，马上搜索该replica节点将 不能搜索到，需要等待下一个commit命令才能搜索到，而其它replica不确定能否搜到（可能搜到也可能不能）。即solr允许leader和 replica节点数据的短时间的不一致。下一次commit后所有节点数据会一致被搜到该文档。导致这种case的原因是，索引数据需要首先由 leader处理，再到replica，所以发给任何replica的数据都需先转发给leader。而收到commit的replica则直接处理并发 给其它replica（包括leader）处理。  
Optimize  
  
Optimize 是一种特殊的commit。它除了做commit还会做索引的合并，所以其代价远大于commit命令。  
  
由于optimize也是先做commit，所以它支持commit的前3个参数。另外还有一个它自己独有的参数  
  
maxSegments = N — default is '1' — optimizes down to at most this number of segments  
  
prepareCommit  
  
用法prepareCommit=true 。该命令调用lucene的prepareCommit方法.如果对lucene 不够了解建议不要使用\[/size\]\[/color\]\[/b\]