简单的来说,over sharding 是分片过度的意思。理解这个问题,需要从elasticsearch的分片机制说起。

一个索引可以存储超出单个结点硬件限制的大量数据。比如,一个具有10亿文档的索引占据1TB的磁盘空间,而任一节点都没有这样大的磁盘空间,或者单个节点处理搜索请求,响应太慢。

为了解决这个问题,Elasticsearch提供了将索引划分成多份的能力,这些份就叫做分片。当你创建一个索引的时候,你可以指定想要的分片的数量。每个分片本身也是一个功能完善并且独立的“子索引”,这个“子索引”可以被放置到集群中的任何节点上。

分片之所以重要,主要有两方面的原因:

  • 允许用户水平分割/扩展系统的内容容量
  • 允许用户在分片(潜在地,位于多个节点上)之上进行分布式的、并行的操作,进而提高性能/吞吐量。至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由Elasticsearch管理的,对于作为用户来说,这些都是透明的。

在一个网络/云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于离线状态,或者由于任何原因消失了,这种情况下,有一个故障转移机制是非 常有用并且是强烈推荐的。为此目的,Elasticsearch允许你创建分片的一份或多份拷贝,这些拷贝叫做副本分片。副本分片之所以重要,有两个主要原因:

  • 在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到副本分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。
  • 扩展系统的搜索量/吞吐量,因为搜索可以在所有的复制上并行运行。

总之,每个索引可以被分成多个分片。一个索引也可以被复制0次(意思是没有副本)或多次。一旦复制了,每个索引就有了主分片(作为复制源的原来的分片)和 副本分片(主分片的拷贝)之别。

主分片和副本分片的数量可以在索引创建的时候指定。在索引创建之后,你可以在任何时候动态地改变副本分片的数量,但是绝不能改变主分片的数量。

在7.0版本之前,默认情况下,Elasticsearch中的每个索引被分片5个主分片和1个复制,这意味着,如果你的集群中至少有两个节点,你的索引将会有5个主分片和另外5个副本分片,这样的话每个索引总共就有10个分片。

而在7.0版本之后,默认的主分片数从5改为1,避免分片过度。分片也是一种资源,分片过多会影响集群的稳定性。因为分片过多,元信息会变多,这些元信息会占用堆内存。分片过多也会影响读写性能,因为每个读写请求都需要一个线程。所以,如果索引没有很大的数据量,不需要设置很多分片。

标签: none

添加新评论