分布式全文检索系统SolrCloud简介

前言

本文简单描述SolrCloud的特性，基本结构和入门，基于Solr4.5版本。

Lucene是一个Java语言编写的利用倒排原理实现的文本检索类库。Solr是以Lucene为基础实现的文本检索应用服务。

SolrCloud是Solr4.0版本开发出的具备开创意义的基于Solr和Zookeeper的分布式搜索方案，或者能够说，SolrCloud是Solr的一种部署方式。Solr能够以多种方式部署，例如单机方式，多机Master-Slaver方式，这些方式部署的Solr不具备SolrCloud的特点功能。

特点

SolrCloud有几个特点功能：

1. 集中式的配置信息

   使用ZK进行集中配置。启动时能够指定把Solr的相关配置文件上传Zookeeper，多机器共用。这些ZK中的配置不会再拿到本地缓存，Solr直接读取ZK中的配置信息。配置文件的变更，全部机器均可以感知到。

   另外，Solr的一些任务也是经过ZK做为媒介发布的。目的是为了容错。接收到任务，但在执行任务时崩溃的机器，在重启后，或者集群选出候选者时，能够再次执行这个未完成的任务。

2. 自动容错

   SolrCloud对索引分片，并对每一个分片建立多个Replication。每一个Replication均可以对外提供服务。一个Replication挂掉不会影响索引服务。

   更强大的是，它还能自动的在其它机器上帮你把失败机器上的索引Replication重建并投入使用。

3. 近实时搜索

   当即推送式的replication（也支持慢推送）。能够在秒内检索到新加入索引。

4. 查询时自动负载均衡

   SolrCloud索引的多个Replication能够分布在多台机器上，均衡查询压力。若是查询压力大，能够经过扩展机器，增长Replication来减缓。

5. 自动分发的索引和索引分片

   发送文档到任何节点，它都会转发到正确节点。

6. 事务日志

   事务日志确保更新无丢失，即便文档没有索引到磁盘。

其它值得一提的功能有：

1. 索引存储在HDFS上

   索引的大小一般在G和几十G，上百G的不多，这样的功能或许很难实用。可是，若是你有上亿数据来建索引的话，也是能够考虑一下的。我以为这个功能最大的好处或许就是和下面这个“经过MR批量建立索引”联合实用。

2. 经过MR批量建立索引

   有了这个功能，你还担忧建立索引慢吗？

3. 强大的RESTful API

   一般你能想到的管理功能，均可以经过此API方式调用。这样写一些维护和管理脚本就方便多了。

4. 优秀的管理界面

   主要信息一目了然；能够清晰的以图形化方式看到SolrCloud的部署分布；固然还有不可或缺的Debug功能。

概念

• Collection：在SolrCloud集群中逻辑意义上的完整的索引。它经常被划分为一个或多个Shard，它们使用相同的Config Set。若是Shard数超过一个，它就是分布式索引，SolrCloud让你经过Collection名称引用它，而不须要关心分布式检索时须要使用的和Shard相关参数。

• Config Set: Solr Core提供服务必须的一组配置文件。每一个config set有一个名字。最小须要包括solrconfig.xml (SolrConfigXml)和schema.xml (SchemaXml)，除此以外，依据这两个文件的配置内容，可能还须要包含其它文件。它存储在Zookeeper中。Config sets能够从新上传或者使用upconfig命令更新，使用Solr的启动参数bootstrap_confdir指定能够初始化或更新它。

• Core: 也就是Solr Core，一个Solr中包含一个或者多个Solr Core，每一个Solr Core能够独立提供索引和查询功能，每一个Solr Core对应一个索引或者Collection的Shard，Solr Core的提出是为了增长管理灵活性和共用资源。在SolrCloud中有个不一样点是它使用的配置是在Zookeeper中的，传统的Solr core的配置文件是在磁盘上的配置目录中。

• Leader: 赢得选举的Shard replicas。每一个Shard有多个Replicas，这几个Replicas须要选举来肯定一个Leader。选举能够发生在任什么时候间，可是一般他们仅在某个Solr实例发生故障时才会触发。当索引documents时，SolrCloud会传递它们到此Shard对应的leader，leader再分发它们到所有Shard的replicas。

• Replica: Shard的一个拷贝。每一个Replica存在于Solr的一个Core中。一个命名为“test”的collection以numShards=1建立，而且指定replicationFactor设置为2，这会产生2个replicas，也就是对应会有2个Core，每一个在不一样的机器或者Solr实例。一个会被命名为test_shard1_replica1，另外一个命名为test_shard1_replica2。它们中的一个会被选举为Leader。

• Shard: Collection的逻辑分片。每一个Shard被化成一个或者多个replicas，经过选举肯定哪一个是Leader。

• Zookeeper: Zookeeper提供分布式锁功能，对SolrCloud是必须的。它处理Leader选举。Solr能够之内嵌的Zookeeper运行，可是建议用独立的，而且最好有3个以上的主机。

架构

• 索引（collection）的逻辑图

• 索引和Solr实体对照图

• 建立索引过程

• 检索过程

• Shard Splitting

入门

安装配置

前提，你须要先安装好Java，6.0+。 假设咱们有5台机器要安装Solr。

1. 安装外部zookeeper

   Solr默认是用内置的Zookeeper，为了方便管理和维护，建议使用外部Zookeeper。

   1 2 3 4 5 6 7 8 9 10 11 12

   wget http : //apache.dataguru.cn/zookeeper/zookeeper-3.4.3/zookeeper-3.4.3.tar.gz tar - zxvf zookeeper - 3.4.3.tar.gz Java的程序解压后就能够运行，不须要安装。 修改或者建立配置文件 $ ZOOKEEPER_HOME / conf / zoo . cfg，内容以下： # 注意修改成你的真实路径 dataDir = / home / hadoop / zookeeper - 3.4.3 / data clientPort = 2181 # 编号从1开始，solr1-3每一个是一台主机，共3个 server . 1 = solr1 : 2888 : 3888 server . 2 = solr2 : 2888 : 3888 server . 3 = solr3 : 2888 : 3888

   在3台机器上都一样安装。

   另外，还须要在$dataDir中配置myid，zookeeper是以此文件肯定本机身份。

   1 2 3 4 5

   # 注意每台机器上的不同 echo "1" > myid #在solr1上 echo "2" > myid #在solr2上 echo "3" > myid #在solr3上

   启动， 须要在3台机器上分别启动

   1 2 3 4

   $ ZOOKEEPER_HOME / bin / zkServer . sh start # 查看状态，确认启动成功 $ ZOOKEEPER_HOME / bin / zkServer . sh status

2. Solr安装下载

   在5台机上作一样操做

   1 2 3 4 5 6 7 8 9 10

   wget http : //apache.mirrors.pair.com/lucene/solr/4.5.0/solr-4.5.0.tgz tar - xzf solr - 4.5.0.tgz cd solr - 4.5.0 cp - r example node1 cdo node1 # 第一条solr机器 java - Dbootstrap_confdir = . / solr / collection1 / conf - Dcollection . configName = myconf - DnumShards = 2 - DzkHost = solr1 : 2181 , solr2 : 2181 , solr3 : 2181 - jar start . jar # 其它solr机器 java - DzkHost = solr1 : 2181 , solr2 : 2181 , solr3 : 2181 - jar start . jar

   启动成功后，你能够经过浏览器8983看到solr的Web页面。

3. 索引

   1 2 3

   cd $ SOLR_HOME / node1 / exampledocs java - Durl = http : //solr1:8983/solr/collection1/update -jar post.jar ipod_video.xml

4. 检索

   你能够在web界面选定一个Core，而后查询。solr有查询语法文档。

5. 若是要想把数据写到HDFS

   在$SOLR_HOME/node1/solr/collection1/conf/solrconfig.xml 增长

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   < directoryFactory name = "DirectoryFactory" class = "solr.HdfsDirectoryFactory" >      < str name = "solr.hdfs.home" > hdfs : //mycluster/solr</str>      < bool name = "solr.hdfs.blockcache.enabled" > true < / bool >      < int name = "solr.hdfs.blockcache.slab.count" > 1 < / int >      < bool name = "solr.hdfs.blockcache.direct.memory.allocation" > true < / bool >      < int name = "solr.hdfs.blockcache.blocksperbank" > 16384 < / int >      < bool name = "solr.hdfs.blockcache.read.enabled" > true < / bool >      < bool name = "solr.hdfs.blockcache.write.enabled" > true < / bool >      < bool name = "solr.hdfs.nrtcachingdirectory.enable" > true < / bool >      < int name = "solr.hdfs.nrtcachingdirectory.maxmergesizemb" > 16 < / int >      < int name = "solr.hdfs.nrtcachingdirectory.maxcachedmb" > 192 < / int >      < str name = "solr.hdfs.confdir" > $ { user . home } / local / hadoop / etc / hadoop < / int > < / directoryFactory >

   从新启动

   1 2	java - Dsolr . directoryFactory = HdfsDirectoryFactory - Dsolr . lock . type = hdfs - Dsolr . data . dir = hdfs : //mycluster/solr -Dsolr.updatelog=hdfs://mycluster/solrlog -jar start.jar

   能够增长以下参数设定直接内存大小，优化Hdfs读写速度。

   1 2	- XX : MaxDirectMemorySize = 1g

其它

• NRT 近实时搜索

  Solr的建索引数据是要在提交时写入磁盘的，这是硬提交，确保即使是停电也不会丢失数据；为了提供更实时的检索能力，Solr设定了一种软提交方式。

  软提交（soft commit）：仅把数据提交到内存，index可见，此时没有写入到磁盘索引文件中。

  一个一般的用法是：每1-10分钟自动触发硬提交，每秒钟自动触发软提交。

• RealTime Get 实时获取

  容许经过惟一键查找任何文档的最新版本数据，而且不须要从新打开searcher。这个主要用于把Solr做为NoSQL数据存储服务，而不只仅是搜索引擎。

  Realtime Get当前依赖事务日志，默认是开启的。另外，即使是Soft Commit或者commitwithin，get也能获得真实数据。 注：commitwithin是一种数据提交特性，不是马上，而是要求在必定时间内提交数据

参考文档

• Solr查询语法
• 入门
• 详细入门文档
• 详细文档
• solrCloud 索引更新逻辑学习笔记
• 官方文档
• SolrReplication

您可能感兴趣的文章

• zookeeper c 客户端使用情景分析(1.总体框架)
• Zookeeper开发常见问题
• Storm：最火的流式处理框架