solrcloud2

分片的原因

由于底层Lucene的限制,每个solr索引中包含的文档数不能超过231个,大约是21亿个。但是solr分片一般不是基于这个的原因,因为一般没有到这个峰值的之后,solr的各中性能问题就暴露出来了。分片一般是为了提高性能,提高吞吐量。

复制策略

solr的复制策略和大部分的NOSQL数据库的复制策略不同,不是通过事务日志进行同步的,而是每次写操作都有leader节点分发到每个replication上去。也就是说,solr更加注重一致性。但是这样牺牲了一定的可用性。

solr的分片策略

solr使用文档路由组件来确定文档应该被分配到那个分片上。solr支持两种文档路由组件:compositeID(默认)和隐式路由(个性化定制分配策略)。

我们只说默认的compositeID策略:

  • 计算文档唯一ID字段的数值散列值。
  • 将文档分配至hash值区间包含上述计算的散列值的分片。

solr计算散列值使用的是MurmurHash算法,与其它流行的哈希函数相比,对于规律性较强的key,MurmurHash的随机分布特征表现更良好。

ZooKeeper的作用

ZooKeeper在solr中主要负责:

  • 集中化配置文件的存储和分发。
  • 检测和提醒集群的状态改变。
  • 确定分片大小。

每个solr实例将会在ZooKeeper下注册一个ZNode,每个ZNode使用ZooKeeper提供的接口与ZooKeeper通信,如果超过一定的时间(默认是15秒)没有接收到通信,那么ZooKeeper就认为这个节点故障了。节点故障之后ZooKeeper会通知其他solr实例(其实是其他solr实例注册成为了相关ZNode的watcher),这样solr就可以知道哪些节点故障了,如果是replication节点故障了,那么leader节点将不会再转发更新请求到它的身上,如果是leader节点故障了,ZooKeeper会选举一个新的leader节点,然后通知所有相关的solr实例。

solr中leader的作用

在查询操作中,leader和replication具有一样的作用。

对于更新操作来说,leader具有一些责任是replication没有的:

  • 为整个分片接收更新请求
  • 在更新后的文档上加上_version字段。
  • 将文档写入更新日志。
  • 以并行的方式将更新请求发送到当前分片的每个replication中,直到收到响应。

solr分布式索引(SolrCloud)的局限性:

  • 计算相关度的时候,需要用到文档频次,但是分片之后,文档频次只能计算到所在节点的频次,不是真个集群的频次,所以一定程度上影响了相关度的计算,可能造成偏差。
  • 除非使用隐式路由实现个性化配置,如果使用默认的compositionID路由的话,不能使用join和分组(我没有用到,类似于实现sql中的Group by)功能。

分片分割

为集群扩展replication非常简单,只要使用增加完solrcore之后使用命令就可以了。但是如果要增加分片,如原来有2个分片,要增加1个,就很麻烦了,因为分片的内容是根据hash区间确定的,如果我们重新分配Hash区间,那么区间中的数据就需要重新分配。而solr又不能像redis那样,缓存可以经得起丢失,所以solr使用的是分片分割的策略来扩展分片。

分片分割是将一个分片分割为两个的策略。这样不会丢失数据,又可以扩展这个分片。它的缺陷也很明显,如果不能直接扩展分片个数*2,那么就不能均衡的分配分片的hash区间。

这是solr当前的分片扩展策略,还不够成熟,新的版本可能会有更加完善的方案出来。

posted on 2017-09-02 10:56  张小贱1987  阅读(209)  评论(0编辑  收藏  举报

导航