solr 主从模式和solrcloud集群模式
2016-06-24 11:52
375 查看
主从模式
主节点有单点故障问题:没有主从自动切换,没有failover,主机down掉了的话,整个数据变成只读。并且需要一台机单独做索引,浪费资源,所有数据都需要在这台机器上单独存在一份,索引变化较大的时候同步会占用很大的带宽和资源。
配置文件改动:改动了solrconfig.xml最终还是要手动上传至从机,而且没有做xml相关的有效性验证,上传后有可能配置出错就直接覆盖原来的配置了,而且也没有提示。
提供了两种路由算法:compositeId和implicit
在创建Collection时,需要通过router.name指定路由策略,默认为compositeId路由。
利用solrJ新建索引时,需要在代码中指定索引具体落在哪个shard上,添加代码:
同时在schema.xml添加字段
具体表现:文档->任意replica->不是leader的话,转发至同shard的leader->转发给本shard的replica->基于路由规则不是本shard,会转发到对应shard的leader->对应shard的replica
整体逻辑:旧shard此时继续提供服务并把旧索引转到新的shard上
旧shard同时继续索引新文档
旧shard同时把新文档转发给新shard,新shard索引新文档
旧索引全部迁移到新shard之后,旧shard关闭,新文档直接转发到新的shard上了
implicit路由:只要创建Shard即可: 新建索引时,将索引建到新建Shard上,查询操作,指定collection名称,得到的仍是整个集群返回的结果。
compositeId路由:实现上述需求稍微麻烦一下,通过分裂(SPLITSHARD)操作实现。如下图,对Shard1进行分裂,分裂URL为:
http://10.21.17.200:9580/solr-4.10.0-web/admin/collections?action=SPLITSHARD&collection=log4j201503&shard=shard1此时Shard1的数据会平均分布到shard1_0和shard1_1上,在利用DELETESHARD API删除Shard1,即可保证数据不冗余
SolrCloud对于单条document的Hash值的获取提出了以下两个要求:
1、hash计算速度必须快,因为hash计算是分布式建索引的第一步。
2、hash值必须能均匀的分布于每一个shard,如果有一个shard的document数量大于另一个shard,那么在查询的时候前一个shard所花的时间就会大于后一个,SolrCloud的查询是先分后汇总的过程,也就是说最后每一个shard查询完毕才算完毕,所以SolrCloud的查询速度是由最慢的shard的查询速度决定的。
基于以上两点,SolrCloud采用了MurmurHash 算法以提高hash计算速度和hash值的均匀分布。
CloudSolrServer,SolrCloud批量添加索引的时候,建议在客户端提前做好document的路由,内部进行文档路由,开销较大。
2.提交频率
commit越频繁越会生成小且多的segment,于是merge出现的更频繁,越耗资源,目前互联网中很多项目中采用缓存机制来弥补这个实时性。
查询速度
1.跟业务相结合,数据量不大并发不大时就采用非hash路由,数据量集中,一次查询也不用后面多个节点,多个十几个shard去合并查询,浪费时间和资源!
[b]配置文件:schema[/b]
[b]positionIncrementGap[/b]用于短语检索控制
positionIncrementGap is used for phrase query of multi-value fields e.g. doc1 has two titles.
> title1: ab cd
> title2: xy zz
if your positionIncrementGap is 0, then the position of the 4
terms are 0,1,2,3. if you search phrase "cd xy", it will hit. But you
may think it should not match so you can adjust positionIncrementGap to a
larger one. e.g. 100. Then the positions now are 0,1,100,101. the
phrase query will not match it.
positionIncrementGap:0
ab cd xy zz
positionIncrementGap:100
ab cd xy zz
ab cd在第一种情况能命中,第二种情况不能命中
[b]precisionStep[/b]:
precisionStep 数值类型的值转换成字符串类型的值时,影响切分之后term的个数!
precisionStep
越小那么被“切”成的的字符串就会多。precisionStep
越小则value被“切”成的term就越多,也就是说索引体积将会增大。被“切”分的term越多则可能在NumericRangeQuery中被细分
的小区间中存在的可能性也就越高,那么查询遍历的次数也就越少,性能也就越好。因此,理想的precisionStep只能依据自己的测试而获取。同时请注意如果只是对其进行sort而不需要范围查询可以将precisionStep=Integer.MAX_VALUE。这样只会生成一个term,从而不会增大索引体积。
普通检索类型:
[code]k1:v1 AND
全文检索框架
阿里妈妈:mdrill
腾讯:Hermes
google:Dremel
Facebook:Presto
impala是c++开发的,不支持多数据源,只能针对hive元数据
阿里巴巴:Druid
parquet:Twitter和Cloudera
CarbonData:华为
实时处理框架:
Twitter替代Storm的方案:Heron
大数据可视化框架:
Nanocubes
查询客户端:
Airpal
主节点有单点故障问题:没有主从自动切换,没有failover,主机down掉了的话,整个数据变成只读。并且需要一台机单独做索引,浪费资源,所有数据都需要在这台机器上单独存在一份,索引变化较大的时候同步会占用很大的带宽和资源。
配置文件改动:改动了solrconfig.xml最终还是要手动上传至从机,而且没有做xml相关的有效性验证,上传后有可能配置出错就直接覆盖原来的配置了,而且也没有提示。
1.索引
一条数据到分发到哪个shard-》具体的replica-》shard大到一定程度之后如何扩容1.1路由规则
SolrCloud中对于文档分布在哪个shard上提供了两种路由算法:compositeId和implicit
在创建Collection时,需要通过router.name指定路由策略,默认为compositeId路由。
compositeId
该路由为一致性哈希路由,shards的哈希范围从80000000~7fffffff。初始创建collection是必须指定numShards个数,compositeId路由算法根据numShards的个数,计算出每个shard的哈希范围,因此路由策略不可以扩展shard。implicit
该路由方式指定索引具体落在路由到哪个Shard,这与compositeId路由方式索引可均匀分布在每个shard上不同。同时只有在implicit路由策略下才可创建shard。利用solrJ新建索引时,需要在代码中指定索引具体落在哪个shard上,添加代码:
doc.addField("_route_", "shard_X");
同时在schema.xml添加字段
<field name="_route_" type="string"/>
1.2索引过程
整体逻辑:路由规则定位所属shard->所属shard的leader->replica具体表现:文档->任意replica->不是leader的话,转发至同shard的leader->转发给本shard的replica->基于路由规则不是本shard,会转发到对应shard的leader->对应shard的replica
1.3分片(纵向扩容还有:[b]升级硬件)[/b]
shard-》shard1、shard2整体逻辑:旧shard此时继续提供服务并把旧索引转到新的shard上
旧shard同时继续索引新文档
旧shard同时把新文档转发给新shard,新shard索引新文档
旧索引全部迁移到新shard之后,旧shard关闭,新文档直接转发到新的shard上了
implicit路由:只要创建Shard即可: 新建索引时,将索引建到新建Shard上,查询操作,指定collection名称,得到的仍是整个集群返回的结果。
compositeId路由:实现上述需求稍微麻烦一下,通过分裂(SPLITSHARD)操作实现。如下图,对Shard1进行分裂,分裂URL为:
http://10.21.17.200:9580/solr-4.10.0-web/admin/collections?action=SPLITSHARD&collection=log4j201503&shard=shard1此时Shard1的数据会平均分布到shard1_0和shard1_1上,在利用DELETESHARD API删除Shard1,即可保证数据不冗余
1.4增加机器(横向扩容)
1.5索引速度
1.一致性哈希SolrCloud对于单条document的Hash值的获取提出了以下两个要求:
1、hash计算速度必须快,因为hash计算是分布式建索引的第一步。
2、hash值必须能均匀的分布于每一个shard,如果有一个shard的document数量大于另一个shard,那么在查询的时候前一个shard所花的时间就会大于后一个,SolrCloud的查询是先分后汇总的过程,也就是说最后每一个shard查询完毕才算完毕,所以SolrCloud的查询速度是由最慢的shard的查询速度决定的。
基于以上两点,SolrCloud采用了MurmurHash 算法以提高hash计算速度和hash值的均匀分布。
CloudSolrServer,SolrCloud批量添加索引的时候,建议在客户端提前做好document的路由,内部进行文档路由,开销较大。
2.提交频率
commit越频繁越会生成小且多的segment,于是merge出现的更频繁,越耗资源,目前互联网中很多项目中采用缓存机制来弥补这个实时性。
2.查询
含有该collection的任意机器-》任意replica-》基于shard个数,启动一个shard对应一个replica的分布式查询-》由最初的replica合并后面启动的多个子查询的结果-》返回给客户查询速度
1.跟业务相结合,数据量不大并发不大时就采用非hash路由,数据量集中,一次查询也不用后面多个节点,多个十几个shard去合并查询,浪费时间和资源!
[b]配置文件:schema[/b]
[b]positionIncrementGap[/b]用于短语检索控制
positionIncrementGap is used for phrase query of multi-value fields e.g. doc1 has two titles.
> title1: ab cd
> title2: xy zz
if your positionIncrementGap is 0, then the position of the 4
terms are 0,1,2,3. if you search phrase "cd xy", it will hit. But you
may think it should not match so you can adjust positionIncrementGap to a
larger one. e.g. 100. Then the positions now are 0,1,100,101. the
phrase query will not match it.
positionIncrementGap:0
ab cd xy zz
positionIncrementGap:100
ab cd xy zz
ab cd在第一种情况能命中,第二种情况不能命中
[b]precisionStep[/b]:
precisionStep 数值类型的值转换成字符串类型的值时,影响切分之后term的个数!
precisionStep
越小那么被“切”成的的字符串就会多。precisionStep
越小则value被“切”成的term就越多,也就是说索引体积将会增大。被“切”分的term越多则可能在NumericRangeQuery中被细分
的小区间中存在的可能性也就越高,那么查询遍历的次数也就越少,性能也就越好。因此,理想的precisionStep只能依据自己的测试而获取。同时请注意如果只是对其进行sort而不需要范围查询可以将precisionStep=Integer.MAX_VALUE。这样只会生成一个term,从而不会增大索引体积。
普通检索类型:
key:value
key:"term"
[code]k1:v1 AND
k2:v2
k2:v2NOT k3:v3
k2:v2OR k3:v3
+k2:v2AND-k3:v3
全文检索框架
阿里妈妈:mdrill
腾讯:Hermes
google:Dremel
Facebook:Presto
impala是c++开发的,不支持多数据源,只能针对hive元数据
阿里巴巴:Druid
parquet:Twitter和Cloudera
CarbonData:华为
实时处理框架:
Twitter替代Storm的方案:Heron
大数据可视化框架:
Nanocubes
查询客户端:
Airpal
相关文章推荐
- spark on yarn 安装
- Mysql大数据量存储及访问的设计讨论-设计
- 离线安装Chrome插件
- 操作系统面试—死锁
- MiniGUI实践之PhotoView
- Mac 抓包工具Charles
- position里absolute和relative属性浅析
- linux下mysql数据库基础及客户端命令详解
- NLog日志记录
- MAX函数和GROUP BY 语句一起使用的一个误区
- Debug:This kind of launch is configured to openthe debug perspective when it解决办法
- CSS+DIV:父DIV相对定位+子DIV绝对定位
- PHP手册-语言参考-类型-Float 浮点型
- VS2010自带的性能分析工具分析.NET程序的性能
- JSON格式化
- OpenGL的视图变换与OSG漫游器
- Sqoop 1.99.6 安装和使用
- B-树 C++模板类封装(有图有真相)
- Java 获取各时区时间,获取当前时间到格林威治时间1970年01月01日00时00分00秒的秒数
- 理解dubbo和zookeeper联系