Solr分布式搜索技术实现分析
2013-04-09 13:29
387 查看
原文出处:/article/4741563.html
Solr从1.3版本开始,自带了分布式搜索(Distributed Search)。这个功能使得Solr能够通过多服务器进行横行扩展,对数据进行水平拆分,从而支持海量数据的搜索功能。
Solr-3.6.1版本对分布式搜索的支持功能如下:
由于业务功能和时间的缘故,本文将只讨论Query component的技术实现逻辑。
schema.xml中定义的unique key必须保存在索引中。因为Solr在进行2nd phrase搜索时需要使用这个unique
key进行数据一致性的二次确认与获取搜索要求查询的字段数据。
分布在不同服务器中的索引文件中包含的unique key不要有重复。因为Solr在进行1st phrase搜索时需要根据这些unique
key进行排序与去重,如果unique key有重复,包含相同unique key的doc结果将随机返回。
搜索结果不要有过多的翻页。因为Solr的分布式搜索中,会将需要翻页排序后的总结果全部返回给proxy solr server进行汇总排序,如果翻页过多,那么对网络带宽将会照成一定的压力。(英文原文:Makes
it more inefficient to use a high "start" parameter. For example, if you request start=500000&rows=25 on an index with 500,000+ docs per shard, this will currently result in 500,000 records getting sent over the network from the shard to the coordinating Solr
instance. If you had a single-shard index, in contrast, only 25 records would ever get sent over the network. (Granted, setting start this high is not something many people need to do.),解释:start值过大就意味着翻页很多次,为什么第一个shard会传500000个docs到第二个shard?因为要对分值进行排序,返回分值最高的25条,所以要将shard1和shard2的结果集合并,在合并后的结果集里返回分值最高的25条。
注意HTTP连接数。因为Solr的分布式搜索中,服务器可能既是search server又是proxy
server,一遍等待http请求应答有一遍处理http请求,多台服务器之间就可能会出现死锁。
客户端发送搜索请求给Solr集群中的任意一台服务器SP。
SP服务器处理分布式查询请求
Phase One
构建查询请求,只获取查询Doc的unique key与sort field字段。
将构建好的请求通过HTTP发送给每一个Solr Shard节点。
等待Solr Shard节点返回查询结果。
根据排序规则,逐个合并Solr Shard节点返回的查询结果。
Phase Two
构建查询请求,根据unique key查询客户端查询的相关字段数据。
将构建好的请求通过HTTP发送给每一个需要请求的Solr Shard节点。
等待Solr Shard节点返回查询结果。
逐个合并Solr Shard节点返回的查询结果,构建本次查询的最终结果。
SP服务器将分布式查询结果返回给客户端
注意:当前的版本中,分布式查询中如果有某一个Shard异常,整体的查询将失败。
http://wiki.apache.org/solr/WritingDistributedSearchComponents
http://wiki.apache.org/solr/DistributedSearchDesign
Solr-3.6.1源码
看完这篇分析总体来说觉得分布式搜索还存在许多弊端,但是是4.0版本以前唯一的处理大数据搜索的方式了,将索引库分片单独存储,比如按省分片存储商家数据等等,有效的降低索引库的大小。对于其中某一个SHARD异常导致查询失败的情况,可以用TOMCAT集群来处理,通过索引的replication在多个TOMCAT之间同步索引,当一个群组瘫痪时,将请求发送到另外一个群组,不过分片过多的话,用到的TOMCAT服务器也越多,架构太复杂不便于维护了。
所以感觉实在是逼不得已才去使用分布式搜索。
去研究一下4.X版本的solrCloud看看对这些问题能不能解决。
概述
Solr单机支持的搜索数据量是有一定上限的,这个取决于搜索的复杂程度,服务器的硬件配置与业务的要求等等,所以将搜索功能分布化将是对于大数据搜索的一个必然趋势。Solr从1.3版本开始,自带了分布式搜索(Distributed Search)。这个功能使得Solr能够通过多服务器进行横行扩展,对数据进行水平拆分,从而支持海量数据的搜索功能。
Solr-3.6.1版本对分布式搜索的支持功能如下:
搜索功能模块 | 是否支持分布式搜索 |
Query component | Y |
Facet component | Y |
Highlighting component | Y |
Spell Check Component | Y |
Terms Component | Y |
Stats component | Y |
Term Vector Component | Y |
Debug component | Y |
Grouping component | Y |
QueryElevationComponent | N |
MoreLikeThis | N |
Join | N |
注意事项
在使用Solr进行分布式搜索的时候,需要注意以下细节:schema.xml中定义的unique key必须保存在索引中。因为Solr在进行2nd phrase搜索时需要使用这个unique
key进行数据一致性的二次确认与获取搜索要求查询的字段数据。
分布在不同服务器中的索引文件中包含的unique key不要有重复。因为Solr在进行1st phrase搜索时需要根据这些unique
key进行排序与去重,如果unique key有重复,包含相同unique key的doc结果将随机返回。
搜索结果不要有过多的翻页。因为Solr的分布式搜索中,会将需要翻页排序后的总结果全部返回给proxy solr server进行汇总排序,如果翻页过多,那么对网络带宽将会照成一定的压力。(英文原文:Makes
it more inefficient to use a high "start" parameter. For example, if you request start=500000&rows=25 on an index with 500,000+ docs per shard, this will currently result in 500,000 records getting sent over the network from the shard to the coordinating Solr
instance. If you had a single-shard index, in contrast, only 25 records would ever get sent over the network. (Granted, setting start this high is not something many people need to do.),解释:start值过大就意味着翻页很多次,为什么第一个shard会传500000个docs到第二个shard?因为要对分值进行排序,返回分值最高的25条,所以要将shard1和shard2的结果集合并,在合并后的结果集里返回分值最高的25条。
注意HTTP连接数。因为Solr的分布式搜索中,服务器可能既是search server又是proxy
server,一遍等待http请求应答有一遍处理http请求,多台服务器之间就可能会出现死锁。
分布式搜索逻辑实现
Query component的实现原则为:Multi-phased approach, allowing for inconsistency,具体的实现细节如下:客户端发送搜索请求给Solr集群中的任意一台服务器SP。
SP服务器处理分布式查询请求
Phase One
构建查询请求,只获取查询Doc的unique key与sort field字段。
将构建好的请求通过HTTP发送给每一个Solr Shard节点。
等待Solr Shard节点返回查询结果。
根据排序规则,逐个合并Solr Shard节点返回的查询结果。
Phase Two
构建查询请求,根据unique key查询客户端查询的相关字段数据。
将构建好的请求通过HTTP发送给每一个需要请求的Solr Shard节点。
等待Solr Shard节点返回查询结果。
逐个合并Solr Shard节点返回的查询结果,构建本次查询的最终结果。
SP服务器将分布式查询结果返回给客户端
注意:当前的版本中,分布式查询中如果有某一个Shard异常,整体的查询将失败。
参考文档
http://wiki.apache.org/solr/DistributedSearchhttp://wiki.apache.org/solr/WritingDistributedSearchComponents
http://wiki.apache.org/solr/DistributedSearchDesign
Solr-3.6.1源码
看完这篇分析总体来说觉得分布式搜索还存在许多弊端,但是是4.0版本以前唯一的处理大数据搜索的方式了,将索引库分片单独存储,比如按省分片存储商家数据等等,有效的降低索引库的大小。对于其中某一个SHARD异常导致查询失败的情况,可以用TOMCAT集群来处理,通过索引的replication在多个TOMCAT之间同步索引,当一个群组瘫痪时,将请求发送到另外一个群组,不过分片过多的话,用到的TOMCAT服务器也越多,架构太复杂不便于维护了。
所以感觉实在是逼不得已才去使用分布式搜索。
去研究一下4.X版本的solrCloud看看对这些问题能不能解决。
相关文章推荐
- Solr分布式搜索技术实现分析
- SOLR分布式搜索技术实现分析
- Solr分布式搜索技术实现分析
- 分布式缓存技术redis学习系列(五)——spring-data-redis与JedisPool的区别、使用ShardedJedisPool与spring集成的实现及一致性哈希分析
- Solrflux源码分析-Sql Support within Solr-类Sql的solr搜索实现(2)
- 分布式网络爬虫关键技术分析与实现一网络爬虫相关知识介绍
- 使用 Apache Lucene 和 Solr 4 实现下一代搜索和分析
- 分布式缓存技术redis学习系列(五)——spring-data-redis与JedisPool的区别、使用ShardedJedisPool与spring集成的实现及一致性哈希分析
- 分布式文件快速搜索-技术细节分析(开源/并行)
- 分布式网络爬虫关键技术分析与实现——分布式网络爬虫体系结构设计
- Solr1.4.0源码分析二 Solr分布式搜索中URL的正确用法和原理
- 前端实现搜索记录功能-技术分析
- 分布式缓存技术redis学习系列(五)——spring-data-redis与JedisPool的区别、使用ShardedJedisPool与spring集成的实现及一致性哈希分析
- 使用 Apache Lucene 和 Solr 4 实现下一代搜索和分析
- solr分布式搜索源码分析
- 分布式网络爬虫关键技术分析与实现系列
- 使用 Apache Lucene 和 Solr 4 实现下一代搜索和分析
- 分布式事务 TCC-Transaction 源码分析 —— TCC 实现
- HTTP Live Streaming直播(iOS直播)技术分析与实现
- 用腾讯的技术实现自己的搜索和大数据分析