ElasticSearch Shard——本质上是做分布式扩展,副本对于集群的稳定性有很强的影响-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

ElasticSearch Shard——本质上是做分布式扩展,副本对于集群的稳定性有很强的影响

简介:

什么是一个Shard?

Shard就是一个Lucene Index,参照文章(深入理解Shard和Lucene Index)。

Index需要多少个Shard?

回答这个问题,我们需要先谈谈节点,一个集群有多个节点,具体需要多少个节点合适,是另外一个问题,但是这个数字也会影响我们对Shard数的设置。

Shard数 = Node数?

总体上说,当我们节点数和Shard数相等时,ElasticSearch集群的性能可以达到最优。即,对于一个3节点集群,我们为每个集群节点分配一个Shard,总共3个Shard。但是由于ElasticSearch的不可变性(Immutable)的限制,系统无法对Shard进行重新拆分分配,除非重新索引这个文件集合。所以,当我们需要增加更多节点的时候,又希望Shard能利用到增加节点带来的系统性能提升时,我们就不得不进行重新索引,由于重索引开销巨大,这是我们不希望看到的。

StackExchange用ElasticSearch支持它的搜索,当前(2016-3-1日),它网站的ElasticSearch索引占用440GB。

如果需要重新建立索引,将会是一个巨大的开销,为了支持未来可能的水平扩展,我们会为集群分配比node数更多的shard数,也就是说每个节点会有多个Shard。

如果单个node分配多个shard,就会引入另外一系列的性能问题,我们知道对于任意一次完整的搜索,ElasticSearch会分别对每个shard进行查询,最后进行汇总。当节点数和shard数是一对一的时候,所有的查询可以并行运行。但是,对于具有多个shard的节点,如果磁盘是15000RPM或SSD,可能会相对较快,但是这也会存在等待响应的问题,所以通常不推荐一个节点超过2个shard。

3节点6shard,即每个节点2shard,这可以使我们在未来轻松的横向扩展到6个节点,应对许多极端的场景。

Replicas数呢?

Replica也是Shard,与shard不同的是,replica只会参与读操作,同时也能提高集群的可用性。对于Replica来说,它的主要作用就是提高集群错误恢复的能力,所以replica的数目与shard的数目以及node的数目相关,与shard不同的是,replica的数目可以在集群建立之后变更,切代价较小,所以相比shard的数目而言,没有那么重要。

Replica的故事(宕机)

3 node, 3 shard, 0 replica

一个节点宕机

整个服务不可用

3 node, 3 shard, 1 replica (each)

一个节点宕机

两个节点宕机

服务仍然可用

3 node, 3 shard, 2 replica (each)

当存储费用较低时,可以考虑

 

摘自:http://www.cnblogs.com/richaaaard/p/5231905.html















本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/7454214.html,如需转载请自行联系原作者


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: