原文出处:http://blog.chenlb.com/2009/01/solr-multicore-work-with-solr-distributed-searching-to-search-big-index.html
Solr Distributed Searching (分布式搜索) 是 solr 1.3 的特性。大索引,可能有多种原因要把它分成N个小的索引,可以把小索引放到其它的机器上,但是我没这么多机器怎么办呢?solr 1.3 有 multicore,恩,multicore 简单使用 可以看我那一篇文章。各个 core 各不干扰,可以独立做索引(做索引时,可以分散到各个core上)。
现来看下 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 二条。
接着会有一个问题:原来很多程序调用 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来做代理(合并结果),结果成功运行。
想来想去,能不能不要另一个tomcat实例呢,直接就用一个 core,继续再探索... 。
我再开一个 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名定义别名,就是用“,”号隔开。改为如下:
<?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)。
至于死循环问题,同事在看源码,看是否不用多加一个额外的core来合并。结果他发现一个shard.qt的参数可以解决此问题,本质就是让所有的shard调用不用默认request handler,shard.qt可以做到这一点,使所有的shard调用都加qt参数。
现来改为最后的方案,在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协议好。
----------------
http://blog.chenlb.com/2009/01/solr-multicore-work-with-solr-distributed-searching-to-search-big-index.html
分享到:
相关推荐
- 将配置好的Solr文件夹打包并分发到其他三台Solr服务器上。 **5. 启动Solr服务** - 启动Solr服务后,可以通过以下URL访问Solr: ``` http://192.168.172.130:8983/solr/index.html ``` **6. 配置Solr Core** ...
6. **性能优化**:Solr提供了多种优化策略,如利用NRT(Near Real Time)机制实现快速搜索更新,通过Shard路由策略分发查询负载,以及通过缓存机制提高响应速度。 7. **扩展性**:Solr支持多种插件机制,可以扩展其...
这包括设置Zookeeper的地址,以及集群的基本属性,如默认的Shard数量和Replication Factor。 3. **Zookeeper集群搭建**: - 安装Zookeeper,将下载的3.4.6版本解压到指定目录。 - 修改`conf/zoo.cfg`配置文件,...
### Solr介绍与SolrCloud特性详解 #### 一、Solr概述 Solr是一款基于Java的开源全文搜索引擎,它建立在Apache Lucene之上。Lucene本身是一个高性能、全功能的文本搜索引擎库,但并不提供完整的搜索应用服务。Solr...
在这种模式下,Solr实例被组织成一个集群,每个实例都可以是Shard的一部分或者作为领导者来处理特定Shard的写入。 2. **ZooKeeper**:在SolrCloud中,ZooKeeper作为一个协调服务,管理集群的状态信息,包括节点的...
当需要将 Lucene 索引分发到多个 Solr 服务器(shard)时,可以使用类似下面的代码: ```java public void distributeIndex(String[] hosts) throws CorruptIndexException, IOException { IndexReader reader = ...
5. **负载均衡与请求路由**: 使用负载均衡器(如Nginx或HAProxy)将请求分发到各个Solr节点,确保高可用性和性能。 维护Solr集群主要包括监控、优化和故障排查: 1. **监控**: 使用Solr自带的JMX监控工具,或者第...
- **查询分发**:客户端的查询请求被分发到所有的shard副本。 - **本地搜索**:每个shard副本在其本地索引上执行搜索操作。 - **结果汇总**:各shard的结果被汇总到一个指定的节点,通常为发起查询的节点。 - **...
- Core:Solr的基本工作单元,每个Core对应一个索引或Shard,具备独立的索引和查询能力。 - Leader:每个Shard的负责人,负责处理索引更新和查询请求,通过选举产生。 总的来说,SolrCloud提供了一种强大的分布式...
1. 分区(Sharding):索引数据被分割成多个部分,每个部分称为一个分片(Shard)。分片可以进一步分为多个副本,以实现冗余和故障恢复。分片使得大型索引可以在多台机器上并行处理,提高了处理能力和响应速度。 2....
4. **Leader**:在每个Shard中,当选的Replica作为Leader,负责接收和分发索引操作,确保数据的一致性。 5. **Replica**:Shard的备份,多个Replica可以提高可用性和容错性,当Leader失效时,新的Leader会在其他...
- **数据上传**:使用Solr提供的工具或者API将数据导入到SolrCloud,可能涉及Shard分配和副本同步。 - **查询与优化**:测试查询性能,根据负载调整索引分布和查询策略,优化查询响应时间和资源利用率。 4. **...
节点分为三类:主节点负责集群级别的管理,数据节点存储数据和倒排索引,协调节点负责处理客户端请求并分发任务。默认情况下,每个节点既是数据节点又是主节点,可以通过配置调整角色。\n\n- **分片(Shard)**:分...