Solr Distributed Searching (分布式搜索) 是 solr 1.3 的特性。大索引,可能有多种缘由要把它分红N个小的索引,能够把小索引放到其它的机器上,可是我没这么多机器怎么办呢?solr 1.3 有 multicore,恩,multicore 简单使用 能够看我那一篇文章。各个 core 各不干扰,能够独立作索引(作索引时,能够分散到各个core上)。 html
现来看下 Distributed Searching 的效果,打开:http://localhost:8080/solr-cores/core0/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on&shards=localhost:8080/solr-cores/core0,localhost:8080/solr-cores/core1 能够看到三条记录,core0 一条,core1 二条。 tomcat
接着会有一个问题:原来不少程序调用 solr,用如 localhost:8080/solr-cores/select/?q=*%3A* 。又不想改原来的调用的代码,能不能作到透明呢,探索... 分布式
记得之前看 solr 文档时能够定义一些默认的查询参数,那 shards 参数也应该能够写在配置里。而后再 core0 的 solrconfig.xml 文件里的 standard request handler 里加入这参数,如: 性能
<requestHandler name="standard" class="solr.SearchHandler" default="true"> <!-- default values for query parameters --> <lst name="defaults"> <str name="echoParams">explicit</str> <str name="shards">localhost:8080/solr-cores/core0,localhost:8080/solr-cores/core1</str> </lst> </requestHandler>
立刻运行下,但好长时间没有结果,CPU使用率很高,深思了下,.... 估计是死循环,由于solr解析shards后,调用shard时,是用默认的request handler。而其中一个shard又是core0(自身),那就等于不会结果的递归。因此这种方法不行。要避免死循环,就不要core0来作合并,能够找其它。因而我就加了一个tomcat实例如localhost:8080/solr来作代理(合并结果),结果成功运行。 url
想来想去,能不能不要另外一个tomcat实例呢,直接就用一个 core,继续再探索... 。 spa
我再开一个 core 就命名为 core,复制core0为core。把原来core0/solrconfig.xml的配置的shards去掉,而后在 solr1.3/example/multicore/solr.xml里加,如: 代理
<?xml version="1.0" encoding="UTF-8" ?> <solr persistent="false"> <cores adminPath="/admin/cores"> <core name="core" instanceDir="core" /> <core name="core0" instanceDir="core0" /> <core name="core1" instanceDir="core1" /> </cores> </solr>
结果成功运行。其中,core0、core1是有数据的,而core是没数据的,core只是运行合并。问题虽然能够差强人意地解决。可是还有一个问题:原来的程序要调用solr,全部url不能改变,加了core是要改url 的,看源码时发现它能够为core名定义别名,就是用“,”号隔开。改成以下: code
<?xml version="1.0" encoding="UTF-8" ?> <solr persistent="false"> <cores adminPath="/admin/cores"> <core name="core,," instanceDir="core" /> <core name="core0" instanceDir="core0" /> <core name="core1" instanceDir="core1" /> </cores> </solr>
"core,,"为何是两个","号呢?。"core,"解析不出两个名,全部就无别名了。"core,,",解析出两个名,一是:"core,一是:"" 空串。有了空串就能够原来的url能够到达core(合并的core)。 xml
至于死循环问题,同事在看源码,看是否不用多加一个额外的core来合并。结果他发现一个shard.qt的参数能够解决此问题,本质就是让全部的shard调用不用默认request handler,shard.qt能够作到这一点,使全部的shard调用都加qt参数。 htm
现来改成最后的方案,在core0与core1的solrconfig.xml里加一个request handler如:
<requestHandler name="shard" class="solr.SearchHandler" />
而后再core0的solrconfig.xml的默认request handler加shards参数,与shards.qt为shard(shard request handler),如:
<requestHandler name="standard" class="solr.SearchHandler" default="true"> <!-- default values for query parameters --> <lst name="defaults"> <str name="echoParams">explicit</str> <str name="shards.qt">shard</str> <str name="shards">localhost:8080/solr-cores/core0,localhost:8080/solr-cores/core1</str> </lst> </requestHandler>
而后在,solr.xml里的core(没数据的去掉),把core0加上空的别名,如:
<core name="core0,," instanceDir="core0" />
固然也能够在core1里加相同的参数,这样core0与core1的功能是同样的,就是两个搜索的url均可以找到全部的数据,我认为:每一个配置同样,在索引分到其它机器的时候比较有做用(若是这样,能够不用multicore的形式,即原始形式),在外面看不出是几个索引的,同时合并的任务也均匀一些。
Solr Distributed Searching 固然也会消耗,合并的core会向每一个shard的core发送两次请求:第一次是找id;第二次是根据id再找文档。若是有N个shard,能够认为有2N+1次请求,1是做合并的请求,其中2N的请求(发每一个shard发送的)是用二进制协议通讯,性能比xml协议好。