在Lucene/Solr的SVN trunk中的SolrCloud已经可用, 在即将发布的4.0版本中将正式包含.
目前SolrCloud已经成熟, 可以支持分布式索引和分布式搜索. 下面是我们一个项目采用新的SolrCloud的部署结构图:
[align=center][img]http://sematext.files.wordpress.com/2012/01/distributedsolr-arch.png[/img][/align]
看起来是否非常简单? 下面我们看看内部的一些实现细节.
[b]SolrCloud功能和架构[/b]
下面是SolrCloud一些不错的功能:
[list]
[*]中心化集群配置
[*]自动容灾
[*]近实时搜索
[*]领导选举
[*]索引持久化
[/list]
另外SolrCloud也能被配置成:
分片(shard)索引
每个shard可以有一个或多个副本(replica)
多个shard和replica可以组成一个Collection(从图中可以看出就是一个SolrCloud), 多个Collection可以部署到一个SolrCloud集群. 而一个搜索请求可以同时搜索多个Collection. 其工作流程就像下图中那样.
[img]http://sematext.files.wordpress.com/2012/01/distributedsolr-shardsreplicas.png[/img]
[b]SolrCloud Shard, Replica, Replication[/b]
就像上图那样, 一个新的doc将发送到一个SolrCloud集群中任何一个节点. doc能自动选择发送到哪一个Shard, 如果Shard有多个副本, doc会自动进行同步, 与原来的master/slave结构有所不同, 数据同步是实时的(原来则是定期批量同步).
[b]集群配置[/b]
SolrCloud集群的所有的配置存储在ZooKeeper. 一旦一个SolrCloud节点启动, 该节点的配置信息将发送到ZooKeeper上存储.
Shard Replica除了作为容灾备份存在, 另外一个作用就是分散查询请求, 提高整个集群的查询能力.
[b]索引处理[/b]
索引文档的更新在Shard和Replica之间是自动和实时的. 因为不存在master server, doc可以发送到任何一个SolrCloud(也就是一个Collection), 然后由SolrCloud完成剩下的事情. 这样就不再存在以前master/slave的单点问题.
[b]搜索方式[/b]
有三种不同的搜索方式:
在单个Solr实例上搜索
在单个Collection上搜索(即在一个Collection的多个Shard上搜索)
在指定的Shard上搜索
在多个Collection上搜索, 并将最后merge的结果返回.
[b]运维管理[/b]
除了原来的标准core admin, 还增加了其他方式:
在一个Collection上创建一个Shard
新建一个Collection
增加节点.
[b]下一步计划[/b]
[url=http://wiki.apache.org/solr/NewSolrCloudDesign]这里[/url]有新的SolrCloud设计方案.
参考原文:[url]http://blog.sematext.com/2012/02/01/solrcloud-distributed-realtime-search/[/url]
目前SolrCloud已经成熟, 可以支持分布式索引和分布式搜索. 下面是我们一个项目采用新的SolrCloud的部署结构图:
[align=center][img]http://sematext.files.wordpress.com/2012/01/distributedsolr-arch.png[/img][/align]
看起来是否非常简单? 下面我们看看内部的一些实现细节.
[b]SolrCloud功能和架构[/b]
下面是SolrCloud一些不错的功能:
[list]
[*]中心化集群配置
[*]自动容灾
[*]近实时搜索
[*]领导选举
[*]索引持久化
[/list]
另外SolrCloud也能被配置成:
分片(shard)索引
每个shard可以有一个或多个副本(replica)
多个shard和replica可以组成一个Collection(从图中可以看出就是一个SolrCloud), 多个Collection可以部署到一个SolrCloud集群. 而一个搜索请求可以同时搜索多个Collection. 其工作流程就像下图中那样.
[img]http://sematext.files.wordpress.com/2012/01/distributedsolr-shardsreplicas.png[/img]
[b]SolrCloud Shard, Replica, Replication[/b]
就像上图那样, 一个新的doc将发送到一个SolrCloud集群中任何一个节点. doc能自动选择发送到哪一个Shard, 如果Shard有多个副本, doc会自动进行同步, 与原来的master/slave结构有所不同, 数据同步是实时的(原来则是定期批量同步).
[b]集群配置[/b]
SolrCloud集群的所有的配置存储在ZooKeeper. 一旦一个SolrCloud节点启动, 该节点的配置信息将发送到ZooKeeper上存储.
Shard Replica除了作为容灾备份存在, 另外一个作用就是分散查询请求, 提高整个集群的查询能力.
[b]索引处理[/b]
索引文档的更新在Shard和Replica之间是自动和实时的. 因为不存在master server, doc可以发送到任何一个SolrCloud(也就是一个Collection), 然后由SolrCloud完成剩下的事情. 这样就不再存在以前master/slave的单点问题.
[b]搜索方式[/b]
有三种不同的搜索方式:
在单个Solr实例上搜索
在单个Collection上搜索(即在一个Collection的多个Shard上搜索)
在指定的Shard上搜索
在多个Collection上搜索, 并将最后merge的结果返回.
[b]运维管理[/b]
除了原来的标准core admin, 还增加了其他方式:
在一个Collection上创建一个Shard
新建一个Collection
增加节点.
[b]下一步计划[/b]
[url=http://wiki.apache.org/solr/NewSolrCloudDesign]这里[/url]有新的SolrCloud设计方案.
参考原文:[url]http://blog.sematext.com/2012/02/01/solrcloud-distributed-realtime-search/[/url]