Solr4.8.0源码分析(27)之ImplicitDocRouter和CompositeIdRouter

同样在公司工作中发现了一个现象,

1.我用/solr/admin/collections?action=CREATE&name=collection&numShards=3&replicationFactor=2创建collection

2. delete其中的一个shard

3. 使用以下命令增加shard,/admin/collections?action=CREATESHARD&shard=shardName&collection=name

如此就会报以下错误:shards can be added only to ‘implicit’ collections。

那么是什么原因呢?问题就出在Solr的两种ROUTER方式ImplicitDocRouter和CompositeIdRouter。在SolrCloud的开发文档中有这句话:

Shards can only created with this API for collections that use the ‘implicit’ router. Use SPLITSHARD for collections using the ‘compositeId’ router. A new shard with a name can be created for an existing ‘implicit’ collection.

也就是说在创建collections时候(如果指定参数numshards参数会自动切换到router=”compositeId”),如果采用compositeId方式,那么就不能动态增加shard。如果采用的是implicit方式,就可以动态的增加shard。进一步来讲:

  • ImplicitDocRouter就是和 uniqueKey无关,可以在请求参数或者SolrInputDocument中添加_route_(_shard_已废弃,或者指定field参数)参数获取slice ,(router=”implicit”) .
  • CompositeIdRouter就是根据uniqueKey的hash值获取slice,   (在指定numshards参数会自动切换到router=”compositeId”) .

综上所述,CompositeIdRouter在创建的时候由于指定了numshards参数即已经固定了hash区间,那么在update的时候,根据uniqueid的hash坐落在那个hash区间来决定这份document数据发送至哪个shard。而ImplicitDocRouter则是在创建的时候并不选定每个shard的hash区间,而是在需要update的document中增加_route_字段来存放需要发送的shard名字,以此shard的名字来决定发送至哪个shard。不难看出,相对来说ImplicitDocRouter更加灵活。

在http://stackoverflow.com/questions/15678142/how-to-add-shards-dynamically-to-collection-in-solr中很好的介绍了动态创建/删除shard的好处(ImplicitDocRouter)

 1 One solution to the problem is to use the “implicit router” when creating your Collection.
 2
 3 Solr does supports the ability to add New Shards (or DELETE existing shards) to your index (whenever you want) via the “implicit router” configuration (CREATE COLLECTION API).
 4
 5 Lets say – you have to index all “Audit Trail” data of your application into Solr. New Data gets added every day. You might most probably want to shard by year.
 6
 7 You could do something like the below during the initial setup of your collection:
 8
 9 admin/collections?
10 action=CREATE&
11 name=AuditTrailIndex&
12 router.name=implicit&
13 shards=2010,2011,2012,2013,2014&
14 router.field=year
15 The above command: a) Creates 5 shards – one each for the current and the last 4 years 2010,2011,2012,2013,2014 b) Routes data to the correct shard based on the value of the “year” field (specified as router.field)
16
17 In December 2014, you might add a new shard in preparation for 2015 using the CREATESHARD API (part of the Collections API) – Do something like:
18
19 /admin/collections?
20 action=CREATESHARD&
21 shard=2015&
22 collection=AuditTrailIndex
23 The above command creates a new shard on the same collection.
24
25 When its 2015, all data will get automatically indexed into the “2015” shard assuming your data has the “year” field populated correctly to 2015.
26
27 In 2015, if you think you don’t need the 2010 shard (based on your data retention requirements) – you could always use the DELETESHARD API to do so:
28
29 /admin/collections?
30 action=DELETESHARD&
31 shard=2015&
32 collection=AuditTrailIndex
时间: 2024-08-09 14:40:22

Solr4.8.0源码分析(27)之ImplicitDocRouter和CompositeIdRouter的相关文章

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三)

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三) 本文是SolrCloud的Recovery策略系列的第三篇文章,前面两篇主要介绍了Recovery的总体流程,以及PeerSync策略.本文以及后续的文章将重点介绍Replication策略.Replication策略不但可以在SolrCloud中起到leader到replica的数据同步,也可以在用多个单独的Solr来实现主从同步.本文先介绍在SolrCloud的leader到replica的数据同步,下一篇

Solr4.8.0源码分析(10)之Lucene的索引文件(3)

Solr4.8.0源码分析(10)之Lucene的索引文件(3) 1. .si文件 .si文件存储了段的元数据,主要涉及SegmentInfoFormat.java和Segmentinfo.java这两个文件.由于本文介绍的Solr4.8.0,所以对应的是SegmentInfoFormat的子类Lucene46SegmentInfoFormat. 首先来看下.si文件的格式 头部(header) 版本(SegVersion) doc个数(SegSize) 是否符合文档格式(IsCompoundF

Solr4.8.0源码分析(4)之Eclipse Solr调试环境搭建

Solr4.8.0源码分析(4)之Eclipse Solr调试环境搭建 由于公司里的Solr调试都是用远程jpda进行的,但是家里只有一台电脑所以不能jpda进行调试,这是因为jpda的端口冲突.所以只能在Eclipse 搭建Solr的环境,折腾了一小时终于完成了. 1. JDPA远程调试 搭建换完成Solr环境后,对${TOMCAT_HOME}/bin/startup.sh 最后一行进行修改,如下所示: 1 set JPDA_ADDRESS=7070 2 exec "$PRGDIR"

Solr4.8.0源码分析(19)之缓存机制(二)

Solr4.8.0源码分析(19)之缓存机制(二) 前文<Solr4.8.0源码分析(18)之缓存机制(一)>介绍了Solr缓存的生命周期,重点介绍了Solr缓存的warn过程.本节将更深入的来介绍下Solr的四种缓存类型,以及两种SolrCache接口实现类. 1.SolrCache接口实现类 前文已经提到SolrCache有两种接口实现类:solr.search.LRUCache 和 solr.search.LRUCache. 那么两者具体有啥区别呢? 1.1 solr.search.LR

Solr4.8.0源码分析(17)之SolrCloud索引深入(4)

Solr4.8.0源码分析(17)之SolrCloud索引深入(4) 前面几节以add为例已经介绍了solrcloud索引链建索引的三步过程,delete以及deletebyquery跟add过程大同小异,这里暂时就不介绍了.由于commit流程较为特殊,那么本节主要简要介绍下commit的流程. 1. SolrCloud的commit流程 SolrCloud的commit流程同样分为三步,本节主要简单介绍下三步过程. 1.1 LogUpdateProcessor LogUpdateProces

Solr4.8.0源码分析(14)之SolrCloud索引深入(1)

Solr4.8.0源码分析(14) 之 SolrCloud索引深入(1) 上一章节<Solr In Action 笔记(4) 之 SolrCloud分布式索引基础>简要学习了SolrCloud的索引过程,本节开始将通过阅读源码来深入学习下SolrCloud的索引过程. 1. SolrCloud的索引过程流程图 这里借用下<solrCloud Update Request Handling 更新索引流程>流程图: 由上图可以看出,SolrCloud的索引过程主要通过一个索引链过程来实

Solr4.8.0源码分析(12)之Lucene的索引文件(5)

Solr4.8.0源码分析(12)之Lucene的索引文件(5) 1. 存储域数据文件(.fdt和.fdx) Solr4.8.0里面使用的fdt和fdx的格式是lucene4.1的.为了提升压缩比,StoredFieldsFormat以16KB为单位对文档进行压缩,使用的压缩算法是LZ4,由于它更着眼于速度而不是压缩比,所以它能快速压缩以及解压. 1.1 存储域数据文件(.fdt) 真正保存存储域(stored field)信息的是fdt文件,该文件存放了压缩后的文档,按16kb或者更大的模块大

Solr4.8.0源码分析(11)之Lucene的索引文件(4)

Solr4.8.0源码分析(11)之Lucene的索引文件(4) 1. .dvd和.dvm文件 .dvm是存放了DocValue域的元数据,比如DocValue偏移量. .dvd则存放了DocValue的数据. 在Solr4.8.0中,dvd以及dvm用到的Lucene编码格式是Lucene45DocValuesFormat.跟之前的文件格式类似,它分别包含Lucene45DocValuesProducer 和Lucene45DocValuesConsumer来实现该文件的读和写. 1 @Ove

Solr4.8.0源码分析(7)之Solr SPI

Solr4.8.0源码分析(7)之Solr SPI 查看Solr源码时候会发现,每一个package都会由对应的resources. 如下图所示: 一时对这玩意好奇了,看了文档以后才发现,这个services就是java SPI机制.首先介绍下java SPI机制,然后再结合Solr谈一下SPI. 1. JAVA SPI 当服务的提供者,提供了服务接口的一种实现之后,在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件.该文件里就是实现该服务接口的具体实现类.而