Solr集群架构概述及delta-import详细配置

背景

由于项目原因,重新熟悉了下Solr,版本为3.6,搭建了主从Solr服务,并使用DIH从RDBMS数据源增量更新索引。

其实也没什么技术含量,就是简单做个总结,分别从部署架构增量更新两个方面说明下。

Solr Replication

solr的主从其实是他的replication集群,从本质上说是通过ReplicationHandler来实现的,除了solr server之间可以互相同步之外,每个solr实例内部的core之间也是可以实现同步的,而能自身同步自身的实例称为Repeater,它的存在是为了分担master的同步开销,即由它来同步master里需要向外同步的core,然后所有的slave都从Repeater处同步相应的core。

具体配置方面,master的solrconfig.xml里的requestHandler配置为:

<requestHandler name="/replication" class="solr.ReplicationHandler">
	<lst name="master">
		<str name="replicateAfter">startup</str>
		<str name="replicateAfter">commit</str>
		<str name="backupAfter">optimize</str>
		<str name="confFiles">schema.xml,stopword.dic,db-data-config.xml,dataimport.properties</str>
		<str name="commitReserveDuration">00:01:00</str>
	</lst>
</requestHandler>

在confFiles里可以指定在同步过程中,slave需要一并同步过去的文件。slave端 solrconfig.xml里的配置为:

<requestHandler name="/replication" class="solr.ReplicationHandler">
	<lst name="slave">
		<str name="masterUrl">http://yf-rd-crm-cdc-db06.yf01.baidu.com:8888/solr/core0/replication</str>
		<str name="pollInterval">00:00:20</str>
		<str name="compression">internal</str>
		<str name="httpConnTimeout">5000</str>
		<str name="httpReadTimeout">10000</str>
	</lst>
</requestHandler>

其中pollInterval是发出同步请求的间隔时间,上述配置为每20s会去sync一次。后面的http参数都是默认值。对slave和master来说,主要的配置不同就在这个handler里,其他部分可以一致。我的solr主从比较简单,大致如下。

如果对solr的搜索还有分片和负载均衡的要求,可以参考下solr4.0之后支持的SolrCloud,适合 high scale, fault tolerant, distributed indexing and search capabilities。我没有选择SolrCloud,主要原因是数据量也不是很大,不需要分片。本来想参考SolrCloud,看能不能为请求的负载均衡提供些什么优势,后来还是放弃了,负载这块在solrj的搜索服务里简单做了下轮训。网上看到也有人用Nginx为多个Tomcat容器做负载均衡,不过这个出发点和架构上的层次又有些不一样。

Solr DataImportHandler

DataImportHandler可以为solr的索引配置数据源,我的数据源是mysql,基本配置可以参考SolrDoc里的内容。不重复。

主要的坑在需要在web.xml里添加下面这个配置

<listener>
   <listener-class>org.apache.solr.handler.dataimport.scheduler.ApplicationListener</listener-class>
</listener>

但是这个类并不存在于solr的主要几个包里,需要额外导入,包下载链接在这里。需要在webapps/solr.war下的WEB-INF/lib里添加这个包,还要添加下dist下的两个dataimporthandler有关的两个jar。此外把上面的listener配置添加到WEB-INF/web.xml内。特别注意的是,需要jdk7才能正常启动,否则会报错。

具体DIH相关的配置再详细列一下,首先在solrconfig.xml里配置Handler:

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
	<lst name="defaults">
		<str name="config">db-data-config.xml</str>
	</lst>
</requestHandler>

具体db-data-config.xml里是sql逻辑和映射field,放在core/conf内,

<dataConfig>
	<dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver"
		url="jdbc:mysql://ip:port/db_name"
		user="root" password="root" />
	<document name="tb_core">
		<entity name="tb_core_table" pk="table_id"
			query="select table_id, code, name, description, freq_id, bytes, first_date, owner, secret_level, charset_id, field_term,
                            line_term, null_format, subj_id, gmt_modify from tb_core_table"
			deltaQuery="select table_id, code, name, description, freq_id, bytes, first_date, owner, secret_level, charset_id, field_term,
                            line_term, null_format, subj_id, gmt_modify from tb_core_table where gmt_modify > '${dataimporter.last_index_time}'">
			<field column="table_id" name="table_id" />
			<field column="code" name="code" />
			<field column="name" name="name" />
			<field column="description" name="description" />
			<field column="description" name="subject_path" />
			<field column="freq_id" name="freq_id" />
			<field column="bytes" name="bytes" />
			<field column="first_date" name="first_date" />
			<field column="owner" name="owner" />
			<field column="secret_level" name="secret_level" />
			<field column="charset_id" name="charset_id" />
			<field column="field_term" name="field_term" />
			<field column="line_term" name="line_term" />
			<field column="null_format" name="null_format" />
			<field column="subj_id" name="subj_id" />
			<field column="gmt_modify" name="entity_modify" />
			<entity name="tb_core_column" pk="col_id"
				query="select col_id, table_id, code, name, description, gmt_modify from tb_core_column where table_id='${tb_core_table.table_id}'"
				deltaQuery="select col_id, table_id, code, name, description, gmt_modify from tb_core_column where gmt_modify > '${dataimporter.last_index_time}'"
				parentDeltaQuery="select table_id, code, name, description, freq_id, bytes, first_date, owner, secret_level, charset_id, field_term,
                                    line_term, null_format, subj_id, gmt_modify from tb_core_table where table_id = ${tb_core_column.table_id}">
				<field column="col_id" name="column_id" />
				<field column="code" name="column_code" />
				<field column="name" name="column_name" />
				<field column="description" name="column_description" />
				<field column="gmt_modify" name="column_modify" />
			</entity>
		</entity>
	</document>
</dataConfig>

上面的逻辑里,table和column是一对多的关系,而两个table内都有最近更新时间字段(gmt_modify),任何一方的更新都要触发整个索引的增量更新,所以这是一个嵌套的例子。在SolrDoc里也有类似的嵌套写法,相对而言属于delta-import稍微高级些的写法。大家可以参考下。

<dataConfig>
    <dataSource driver="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:/temp/example/ex" user="sa" />
    <document>
            <entity name="item" pk="ID" query="select * from item"
                deltaImportQuery="select * from item where ID=='${dih.delta.id}'"
                deltaQuery="select id from item where last_modified > '${dih.last_index_time}'">
                <entity name="feature" pk="ITEM_ID"
                    query="select DESCRIPTION as features from FEATURE where ITEM_ID='${item.ID}'"
                    deltaQuery="select ITEM_ID from FEATURE where last_modified > '${dih.last_index_time}'"
                    parentDeltaQuery="select ID from item where ID=${feature.ITEM_ID}"/>
            <entity name="item_category" pk="ITEM_ID, CATEGORY_ID"
                    query="select CATEGORY_ID from item_category where ITEM_ID='${item.ID}'"
                    deltaQuery="select ITEM_ID, CATEGORY_ID from item_category where last_modified > '${dih.last_index_time}'"
                    parentDeltaQuery="select ID from item where ID=${item_category.ITEM_ID}">
                <entity name="category" pk="ID"
                        query="select DESCRIPTION as cat from category where ID = '${item_category.CATEGORY_ID}'"
                        deltaQuery="select ID from category where last_modified > '${dih.last_index_time}'"
                        parentDeltaQuery="select ITEM_ID, CATEGORY_ID from item_category where CATEGORY_ID=${category.ID}"/>
            </entity>
        </entity>
    </document>
</dataConfig>

最重要的是,在solr_home/conf内需要一个负责调度的文件:dataimport.properties(不同于core/conf下的dataimport.properties,那个dataimport.properties会自动生成,记录的是最近一次更新的时间)

#################################################
#                                               #
#       dataimport scheduler properties         #
#                                               #
#################################################

#  是否同步功能
#  1 - 开启 ; 否则不开启
syncEnabled=1

# 需要同步的solr core
syncCores=core0

#  solr server名称或ip地址
#  默认为localhost
server=localhost

#  solr server端口
#  默认80
port=8888

# webapp name
webapp=solr

#  application context
# webapp=metadata-search

#  同步URL参数
params=/dataimport?command=delta-import&clean=false&commit=true

#  调度区间
#  默认30分钟
interval=1

这部分就需要开头讲的

org.apache.solr.handler.dataimport.scheduler.ApplicationListener

的配置,否则启动后,之前的xml是不生效的。

Solr Server服务架构

结合Solr更新、主从和内部的一些主要模块,画了一个服务架构图如下。

(全文完)

时间: 2024-09-14 06:25:06

Solr集群架构概述及delta-import详细配置的相关文章

Solr集群搭建,zookeeper集群搭建,Solr分片管理,Solr集群下的DataImport,分词配置。

1   什么是SolrCloud SolrCloud(solr 云)是Solr提供的分布式搜索方案,当你需要大规模,容错,分布式索引和检索能力时使用 SolrCloud.当一个系统的索引数据量少的时候是不需要使用SolrCloud的,当索引量很大,搜索请求并发很高,这时需要使 用SolrCloud来满足这些需求. SolrCloud是基于Solr和Zookeeper的分布式搜索方案,它的主要思想是使用Zookeeper作为集群的配置信息中心. 它有几个特色功能: 1)集中式的配置信息 2)自动容

Haproxy负载均衡集群架构设计的例子

公司最近有一个项目由于用户担心一台单机无法承担最多用户量的使用,要求上应用集群.我们根据应用情况设计了应用集群架构. 架构图如下: 部署应用集群的特点: 1. 前端代理负载均衡 因用户环境基础架构采用虚拟化集群平台,服务器均采用虚拟机实现,所以设计时采用单台Haproxy来实现. 前端选用haproxy:有一最大的特点HTTP第7层键康状态检查,与我们实际需要一致,因经常有应用压力大,应用无法响应的情况,正好通过这一个特性进行健康状态检查,保证用户透明访问.之前有采用haporxy的主备模式做双

一步一个脚印:解密唯品会中Redis集群架构演进与功能定制

在2016杭州云栖大会的"开源数据库之Redis专场"上,来自唯品会的高级数据工程师申政带来了题为<Redis在唯品会的应用实践>的精彩分享.分享中,他主要介绍Redis集群架构演进.Redis使用经验以及唯品会对Redis二次开发实践积累三部分,干货满满,精彩不容错过. 以下内容根据演讲PPT及现场分享整理. Redis集群架构演进 目前在唯品会内对Redis的使用属于重量级别,目前在唯品会内大概有8000个Redis实例.1000台物理机.500个应用. 上图是唯品会对

mysql基于RHCS、Gtid主从复制的高性能、LB、HA集群架构

mysql基于RHCS.Gtid主从复制的高性能.LB.HA集群架构 本文基于2个角度进行 1:mysql主从复制,读写分离部分 2:RHCS实现mysql-proxy.mysql-master.lvs高可用 架构图 可能会用到的yum源 http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.r

Haproxy负载均衡集群架构设计一例

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://koumm.blog.51cto.com/703525/1282152 公司最近有一个项目由于用户担心一台单机无法承担最多用户量的使用,要求上应用集群.我们根据应用情况设计了应用集群架构. 架构图如下: 部署应用集群的特点: 1. 前端代理负载均衡 因用户环境基础架构采用虚拟化集群平台,服务器均采用虚拟机实现,所以设计时采用单台Haproxy来实现. 前端选用haproxy:有一

Galera Cluster:一种新型的高一致性MySQL集群架构

1. 何谓Galera Cluster 何谓Galera Cluster?就是集成了Galera插件的MySQL集群,是一种新型的,数据不共享的,高度冗余的高可用方案,目前Galera Cluster有两个版本,分别是Percona Xtradb Cluster及MariaDB Cluster,都是基于Galera的,所以这里都统称为Galera Cluster了,因为Galera本身是具有多主特性的,所以Galera Cluster也就是multi-master的集群架构,如图1所示: 图1

HeartBeat 集群组件概述

Heartbeat 是一个基于Linux开源的高可用集群系统.主要包括心跳服务和资源接管两个高可用集群组件.心跳监测服务可以通过网络链路和串口进行,而且支持冗余链路, 它们之间相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的报文,那么就认为对方失效,这时需启动资源接管模块来接管运行在对方主机上的资源或者服务.本文简要描述了heartbeat v2集群架构组件及其相关概念,供大家参考. 一.高可用集群的特点 高可用服务 通常使用集群方式实现,这也是集群的最大作用和体现. 其

搜索服务Solr集群搭建 使用ZooKeeper作为代理层

上篇文章搭建了zookeeper集群 那好,今天就可以搭建solr搜服服务的集群了,这个和redis 集群不同,是需要zk管理的,作为一个代理层 安装四个tomcat,修改其端口号不能冲突.8080~8083 如果是正式环境下,则分别使用4台linux作为节点 修改server.xml文件修改端口号,总共3个 以上步骤,在tomcat03,tomcat04上重复执行,但是3个端口一定要注意不能重复 向tomcat下部署solr 把单机版的solr工程复制到tomcat下即可 solr在别的机子上

阿里Hadoop集群架构及服务体系

阿里Hadoop集群架构及服务体系 梁李印   阿里巴巴集团-海量数据 1.集群发展现状 2.集群服务模式及挑战 3.Hadoop版本特性 4.集群用户门户 5.集群核心业务架构 temp_12121008097521.pdf