`
须等待
  • 浏览: 210496 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

Solr 全文索引详解(一)

    博客分类:
  • Java
阅读更多

本系列文章系翻译整理官方文档,结合实践的总结而来。



1. 概述
Solr是一个基于lucene的开源全文索引引擎。具有良好的伸缩性,并且具有良好的可编程性,支持多种插件。本文档提供简单的基础技术支持,包含了部署的步骤、solr数据类型定义、索引与基础数据操作、搜索等方面。
本文档介绍的内容基本属于Solr4.x(1.4)。

2. 部署Solr
Solr的部署非常简单,并且支持StandAlone/Cloud方式部署。所需要的部署文件包括标准化的solr的war包,和一个带有solr配置文件的solr主文件夹(sol.home)。

2.1 Solr的部署目录简析
Solr的部署文件包含一个war包,和一个solr主文件夹。

2.1.1 Solr的war包
war包里包含有http的接口,是所有的操作solr的入口,需要被部署到servlet容器上。入口基于servlet,可以被部署到任何的servlet容器上。

2.1.2 Solr的主文件夹
主文件夹里包含有Solr需要的配置文件和数据文件。

[img]http://dl2.iteye.com/upload/attachment/0099/4651/3dbf9ab9-07de-34ac-927d-9bb1c02a816b.png" alt="[/img]

 bin目录。
 collection1。装载的核心的目录
[img]http://dl2.iteye.com/upload/attachment/0099/4655/ddcc1c55-0654-339c-a999-6217bddbf5c1.png" alt="[/img]
     conf目录。这个目录里存放了核心的配置文件,包括schema.xml等
     core.properties。配置核心的名字等属性
     data。存放所有的数据文件和索引文件
 lib目录。核心引用的自定义函数的包路径

2.2 StandAlone模式的部署
StandAlone模式是单机模式。
 将solr.war包部署到容器下。


 将solr.home文件夹部署到节点上。


 启动容器的同时指定solr.home的位置。一般使用-Dsolr.solr.home=%SOLR_HOME%方法来指定,也可以通过JNDI的方式来指定。


 启动容器之后就可以直接在浏览器中验证solr的部署情况了。


2.3 SolrCloud模式的部署
SolrCloud模式是以集群的方式部署Solr。集群方式基于ZooKeeper(zk)做节点的管理,允许部署主备机,自动分片(Sharding)。

 将solr.war包部署到容器下。


 将solr.home文件夹部署到节点上。



 启动容器的同时指定solr.home的位置。指定的方式和StandAlone模式一样。与之不同的是,需要指定zk服务的ip和端口,以便各节点可以通过zk来交互。

 依次启动的节点将使用zk上的集中式配置,节点的角色(leader、slave、shard)将由solr自动分配。

2.4 StandAlone与SolrCloud的核心概念
在Solr中,有几个概念是StandAlone模式与SolrCloud模式互通的。但有些概念在不同模式下的表现形式可能又有差距。

 Node 节点。 server
 Index 索引。 Index概念可以理解为由很多Document(文档)组成的Logic Index(逻辑索引)
 Collection 数据集。 从抽象上来看,Collection可以理解为一个逻辑索引在Solr里的表现,以及被索引的数据。
 Core 核心。 从抽象上来看,Core可以理解为一个Node上的一个管理一个逻辑索引的实例。
2.4.1 StandAlone模式中的概念
在单节点的情况下,一个Core,装载了一个单一的Index,组成一个单一的Collection,如果你想要多个索引,则必须有多个核心。solr 1.3以后支持在一个solr实例中运行多个核心,这为管理多个索引提供了方便快捷的处理方式,而不是尝试去启动多个solr实例。

2.4.2 SolrCloud模式中的概念
 Shard 分片。 在SolrCloud模式中,数据可以被按照某种算法切分而分布到不同的节点上,从而实现负载的分发。但是SolrCloud中分片数量是预定义的,不支持动态扩展,这种实现方式意味着如果分片数量想要增加,则必须停机修改配置,然后把所有数据全部重新索引一次,以便分布到正确的节点上。
 Replication 复制。 SolrCloud提供简单的数据冗余以增加Fault Tolerance(容错性)和High Availability(HA、可用性)。某个Shard下可以有多个节点提供服务,其中的某个节点将会成为leader,其他的节点成为Replication提供冗余服务,数据通过log的形式在节点之间进行同步。
 Leader 主机。 分片以后的集群,将有多个节点装载同一个分片的数据,但是这些节点中只有一个节点为主节点,负责处理例如写请求这样的请求,这个主节点就叫Leader。Leader由多个节点选举产生,选举算法由zk提供支持,这里不多做介绍。

在SolrCloud模式下,一个Index、Collection将由分布在多个节点上的多个Core组成,这是与StandAlone模式的一大不同。

2.5 SolrCloud中的一些机制
集群模式的Solr提供的服务与单机相比,主要区别在于数据是分布式的,存储在多个节点上,这样的机制使得整个集群向外暴露的服务具有一定的容错性、高可用性。
2.5.1 分布式集群的管理
Solr 集群依赖于ZooKeeper提供的管理服务,其中包括:
 集中式的配置中心。 Solr中的所有配置将在第一个Solr节点启动的时候上传到zk,以后的启动,如果不需要修改配置,则不需要提供任何额外的参数,直接从zk中读取配置。
 节点状态管理。 zk提供心跳服务,可以随时监控集群中节点的健康状况。每一个节点连接上zk时将创建一个EPHEMERAL(临时)的节点,当节点宕机失去联系,节点将消息,而其他监听的节点将收到消息。
 选举服务。 zk提供简单的选举支持,Solr分片中的Leader由此而来。

2.5.2 配置文件的管理
Solr的配置文件存储在zk上,所以要求第一个节点第一次启动的时候需要上传配置文件。
如果配置文件需要修改,则需要从zk上down下来,修改完之后再手动上传。
这里需要正确理解配置文件与core的关系。配置文件与core并不是绑定的关系,二者是独立的,可以独立管理。core只是简单的引用被上传的配置文件。

2.5.3 数据路由机制
集群存在的一大意义就是分散系统的负载,其中一个核心问题就是:数据是如何分布的。
SolrCloud里提供两种数据分布的策略:
 hash 分布。根据索引请求中的documentId做简单的hash分布,分布到预定义的shardNum分片里。
 根据特征前缀分布。将具有特定前缀的documentId分布到预定义的shard里
2.5.4 请求路由机制
SolrCloud的客户端是轻量级的客户端,并不负责计算数据分布,而是简单的将请求发送到集群,由集群来决定由哪个节点来处理请求。
SolrCloud也允许请求中限定处理请求的shard,既只需要搜索部分数据。
 读请求
读请求比较简单,只需要被转发到每个shard,搜索后将结果组装成为响应,然后返回。

 写请求
     客户端从zk中获取到一个节点的地址
     如果这个节点是一个replica,请求被转发到leader
     如果这个节点是leader,则计算出正确的shard,转发到正确的shard-leader
     请求到了正确的leader,索引之,并将数据同步到此shard上所有的replica
2.5.5 集群的读写容错性
 读容错性
默认情况下,一个搜索请求需要搜索所有的shard,然后将各个shard上搜索的结果合并形成一个完整的数据集作为响应。如果某个shard上的搜索任务失败了,那么整个请求都将失败,这种策略将浪费在其他shard上已经消费的计算能力,所以Solr允许返回部分搜索结果,忽略失败的部分。需要显示声明shards.tolerant=true。如果出现了部分失败的情况,返回结果里将出现一个标识"partialResults": true。
 写容错性
Solr 使用transaction log进行leader与replica之间的数据同步,当leader宕机了,replica将重新选举出一个拥有最新版本数据的节点成为leader,由于transaction log的存在,可以最大范围的保证数据的安全。














  • 大小: 8.7 KB
  • 大小: 5.8 KB
  • 大小: 9.5 KB
  • 大小: 8.7 KB
  • 大小: 1.4 KB
  • 大小: 9.5 KB
  • 大小: 8.7 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics