Elasticsearch索引分片的数量及大小分配策略

本文围绕Elasticsearch的分片展开,介绍了分片基本认知,包括主分片和副本分片。阐述了分片创建、分配策略,强调数量和大小决策要点,如避免分片过多、合理容量为10GB - 50GB等。还介绍了重要配置,以及索引分片分配的多种策略,如均衡、延迟、过滤等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、分片的基本认知

Shard即数据分片,是ES的数据载体。在ES中数据分为primary shard(主分片)和replica shard(副本分片),每一个primary承载单个索引的一部分数据,分布于各个节点,replica为某个primary的副本,即备份。分片分配的原则是尽量均匀的分配在集群中的各个节点,以最大程度降低部分shard在出现意外时对整个集群乃至服务造成的影响。

每个分片就是一个Lucene的实例,具有完整的功能。

2、分片创建策略

分片产生的目的是为了实现分布式,而分布式的好处之一就是实现“高可用性”(还包括高性能如提高吞吐量等会再后面内容展开讲),分片的分配策略极大程度上都是围绕如何提高可用性而来的,如分片分配感知强制感知等。

互联网开发没有“银弹”,分片的数量分配也没有适用于所有场景的最佳值,创建分片策略的最佳方法是使用您在生产中看到的相同查询和索引负载在生产硬件上对生产数据进行基准测试。分片的分配策略主要从两个指标来衡量:即数量和单个分片的大小。

3、分片分配的基本策略

  • ES使用数据分片(shard)来提高服务的可用性,将数据分散保存在不同的节点上以降低当单个节点发生故障时对数据完整性的影响,同时使用副本(repiica)来保证数据的完整性。关于分片的默认分配策略,在7.x之前,默认5个primary shard,每个primary shard默认分配一个replica,即5主1副,而7.x之后,默认1主1副
  • ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是,实际情况取决于集群拥有的分片和索引的数量以及它们的大小,不一定总是能均匀地分布。
  • Paimary只能在索引创建时配置数量,而replica可以在任何时间分配,并且primary支持读和写操作,而replica只支持客户端的读取操作,数据由es自动管理,从primary同步。
  • ES不允许Primary和它的Replica放在同一个节点中,并且同一个节点不接受完全相同的两个Replica
  • 同一个节点允许多个索引的分片同时存在。

4、分片的数量分配多少

  • 避免分片过多:大多数搜索会命中多个分片。每个分片在单个 CPU 线程上运行搜索。虽然分片可以运行多个并发搜索,但跨大量分片的搜索会耗尽节点的搜索线程池。这会导致低吞吐量和缓慢的搜索速度。
  • 分片越少越好:每个分片都使用内存和 CPU 资源。在大多数情况下,一小组大分片比许多小分片使用更少的资源。

5、分片的大小决策

  • 分片的合理容量:10GB-50GB。虽然不是硬性限制,但 10GB 到 50GB 之间的分片往往效果很好。根据网络和用例,也许可以使用更大的分片。在索引的生命周期管理中,一般设置50GB为单个索引的最大阈值。
  • 堆内存容量和分片数量的关联:小于20分片/每GB堆内存,一个节点可以容纳的分片数量与节点的堆内存成正比。例如,一个拥有 30GB 堆内存的节点最多应该有 600 个分片。如果节点超过每 GB 20 个分片,考虑添加另一个节点。

查询当前节点堆内存大小:

GET _cat/nodes?v=true&h=heap.current
  • 避免重负载节点:如果分配给特定节点的分片过多,会造成当前节点为重负载节点

6、重要的配置

6.1 自定义属性

node.attr.{attribute}

如何查看节点属性?

GET _cat/nodeattrs?v

6.2 索引级配置

  • index.routing.allocation.include.{attribute}:表示索引可以分配在包含多个值中其中一个的节点上。
  • index.routing.allocation.require.{attribute}:表示索引要分配在包含索引指定值的节点上(通常一般设置一个值)。
  • index.routing.allocation.exclude.{attribute}:表示索引只能分配在不包含所有指定值的节点上。
//索引创建之前执行
PUT <index_name>
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "index.routing.allocation.include._name": "node1"
  }
}

6.3 集群级配置

elasticsearch修改集群范围设置提供两种方式,

  • persistent:永久性修改,persistent相关的修改保存在了/path.data/cluster.name/nodes/0/_state/global-n.st,如果想删除设置,删除此文件即可。
  • transient:集群重启后失效。
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "rack_id"
  }
}

7、索引分片分配:Index Shard Allocation

7.1 分片均衡策略:shard rebalance

当集群在每个节点上具有相同数量的分片而没有集中在任何节点上的任何索引的分片时,集群是平衡的。Elasticsearch 运行一个称为rebalancing 的自动过程,它在集群中的节点之间移动分片以改善其平衡。重新平衡遵循所有其他分片分配规则,例如分配过滤强制意识,这可能会阻止它完全平衡集群。在这种情况下,重新平衡会努力在您配置的规则内实现最平衡的集群。如果您使用数据层然后 Elasticsearch 会自动应用分配过滤规则将每个分片放置在适当的层中。这些规则意味着平衡器在每一层内独立工作。

cluster.routing.rebalance.enable

(动态) 为特定类型的分片启用或禁用重新平衡:

  • all -(默认)允许对所有类型的分片进行分片平衡。
  • primaries - 只允许主分片的分片平衡。
  • replicas - 仅允许对副本分片进行分片平衡。
  • none - 任何索引都不允许进行任何类型的分片平衡。

cluster.routing.allocation.allow_rebalance

(动态) 指定何时允许分片重新平衡:

  • always - 始终允许重新平衡。
  • indices_primaries_active - 仅当集群中的所有主节点都已分配时。
  • indices_all_active -(默认)仅当集群中的所有分片(主分片和副本)都被分配时。

7.2 延迟分配策略(默认1m):

当节点出于任何原因(有意或无意)离开集群时,主节点会做出以下反应

  • 将副本分片提升为主分片以替换节点上的任何主分片。
  • 分配副本分片以替换丢失的副本(假设有足够的节点)。
  • 在其余节点之间均匀地重新平衡分片。

这些操作旨在通过确保尽快完全复制每个分片来保护集群免受数据丢失。即使我们在节点级别集群级别限制并发恢复 ,这种“分片洗牌”仍然会给集群带来很多额外的负载,如果丢失的节点可能很快就会返回,这可能是不必要的

7.3 分片过滤:即(Shard allocation filtering,控制那个分片分配给哪个节点)。

  • index.routing.allocation.include.{attribute}:表示索引可以分配在包含多个值中其中一个的至少节点上。
  • index.routing.allocation.require.{attribute}:表示索引要分配在包含索引指定值的节点上(通常一般设置一个值)。
  • index.routing.allocation.exclude.{attribute}:表示索引只能分配在不包含所有指定值的节点上。

7.4 分片分配感知策略:Shard Allocation Awareness

Shard Allocation Awareness的设计初衷是为了提高服务的可用性,通过自定义节点属性作为感知属性,让 Elasticsearch 在分配分片时将物理硬件配置考虑在内。如果 Elasticsearch 知道哪些节点位于同一物理服务器上、同一机架中或同一区域中,则它可以分离主副本分片,以最大程度地降低在发生故障时丢失数据的风险。

启用分片感知策略

配置节点属性

node.attr.rack_id: rack1

通过以下设置告诉主节点在分配分片的时候需要考虑哪些属性。这些信息会保存在每个候选节点的集群状态信息中

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "rack_id"
  }
}

7.5 强制感知策略:Forced awareness

默认情况下,如果一个区域发生故障,Elasticsearch 会将所有故障的副本分片分配给其他区域。但是剩余区域可能没有足够的性能冗余来承载这些分片。

为了防止在发生故障时单个位置过载,您可以设置为cluster.routing.allocation.awareness.force不分配副本,直到另一个位置的节点可用。

部署强制感知策略

设置强制感知策略,告诉主节点当前通过某个属性来划分区域,并且告知区域有哪些值

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2 
<think>嗯,用户想了解Elasticsearch分片分配策略以及如何选择合适的方法。首先,我需要回忆一下Elasticsearch分片的基本概念。分片分为主分片和副本分片,主分片用于存储数据,副本分片用于备份和查询负载均衡。分片分配策略可能涉及如何分布这些分片到不同的节点上,以优化性能、可靠性和资源利用。 接下来,用户提到的分片分配策略可能包括集群层面的设置,比如动态分配、数据层划分、节点角色分离等。动态分配策略允许Elasticsearch自动决定分片的分布,这可能根据节点的负载、磁盘空间等因素进行调整。而数据层划分可能是将热数据、温数据和冷数据存储在不同类型的节点上,比如使用SSD存储热数据,HDD存储冷数据,这样可以优化存储成本和访问速度。 节点角色分离也是一个重要策略,将主节点、数据节点、协调节点分开,这样可以避免资源竞争,提高集群的稳定性。比如,主节点负责集群管理,数据节点处理存储和查询,协调节点处理请求分发。这样各司其职,提高效率。 然后,用户想知道如何选择正确的分片策略。可能需要考虑的因素包括数据量、读写压力、节点硬件配置、容灾需求等。比如,对于大索引,可能需要更多的分片来分散压力,但分片过多也会带来管理开销。另外,副本分片数量会影响查询性能和容灾能力,增加副本可以提高可用性,但也会占用更多存储和资源。 在分片分配策略中,还有一些高级设置,比如分片分配过滤、强制感知和分片重新平衡策略分片分配过滤可以根据节点属性(如区域、机架)来分配分片,确保分片分布在不同的物理位置,提高容灾能力。强制感知策略可以防止同一分片的主副本在同一区域,避免单点故障。分片重新平衡策略则是在节点增减时如何调整分片分布,保持集群的均衡。 用户可能还关心容量规划,比如如何根据数据增长和业务需求调整分片方案。例如,参考中的例子,用户为不同的索引选择了不同的分片方案,比如1x1、3x2,这可能基于索引大小、增长速度和重要性。比如产品索引可能数据量大且重要,所以需要更多分片和副本。 此外,分片大小的最佳实践也很重要,比如每个分片推荐在10GB到50GB之间,但具体还要看使用场景。分片过多会导致资源浪费,过少则可能成为性能瓶颈。 用户可能在实际应用中遇到问题,比如分片分配不均导致某些节点压力大,或者分片数量过多影响查询性能。这时候需要根据监控数据调整分片策略,比如调整分片数量、重新分配节点角色,或者使用索引生命周期管理(ILM)自动管理数据的分片策略。 最后,生成相关问题时需要考虑用户可能进一步想了解的内容,比如如何监控分片分配、具体的配置步骤、分片策略调整后的影响,或者如何处理分片分配失败的情况。这些问题可以帮助用户更深入地理解和应用分片策略。</think>### Elasticsearch 分片分配策略及选择方法 #### 1. 分片分配基础概念 - **分片类型**:分为主分片(Primary Shard)和副本分片(Replica Shard),主分片存储数据,副本分片提供冗余和查询负载均衡。 - **分片分配目标**:通过合理分配分片,实现负载均衡、高可用性和性能优化[^1]。 #### 2. 分片分配策略 **(1) 动态分配策略(默认)** - Elasticsearch 自动根据节点的负载、磁盘使用率和分片分布情况分配分片。 - 适用场景:小型集群或对性能要求不高的场景。 **(2) 数据层划分策略** - 将节点划分为热(Hot)、温(Warm)、冷(Cold)层: - **热层**:高性能硬件(如 SSD),存储高频访问数据。 - **温层/冷层**:低性能硬件(如 HDD),存储低频或归档数据。 - 通过索引生命周期管理(ILM)自动迁移数据。 **(3) 节点角色分离** - 区分主节点、数据节点、协调节点: - **主节点**:管理集群状态。 - **数据节点**:存储分片。 - **协调节点**:处理请求分发。 - 优势:减少资源竞争,提升稳定性。 **(4) 分片分配过滤** - 根据节点属性(如 `zone`、`rack`)分配分片,避免分片集中在单一物理区域。 - 示例配置: ```json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.include.zone": "east,west" } } ``` #### 3. 如何选择分片策略? | **考量因素** | **策略选择** | |----------------------|----------------------------------| | 数据规模与增长 | 动态分配 + 分片数量优化(如 3x2)| | 读写性能需求 | 数据层划分 + 热层高配硬件 | | 容灾需求 | 分片分配过滤 + 多副本(≥2) | | 硬件资源限制 | 节点角色分离 + 分片分配过滤 | #### 4. 分片分配高级配置 **(1) 强制感知策略** - 确保主分片和副本分片不在同一物理区域: ```json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.awareness.attributes": "zone", "cluster.routing.allocation.awareness.force.zone.values": "east,west" } } ``` **(2) 分片重新平衡策略** - 控制分片在节点间的迁移频率: ```json PUT _cluster/settings { "persistent": { "cluster.routing.rebalance.enable": "primaries" } } ``` #### 5. 最佳实践 - **分片大小**:推荐单个分片容量为 $10\text{GB} \leq V \leq 50\text{GB}$,避免过大或过小。 - **分片数量公式**: $$N = \frac{\text{总数据量}}{\text{单分片容量}} \times (1 + \text{副本数})$$ - **监控工具**:使用 Elasticsearch 的 `_cat/shards` API 或 Kibana 监控分片状态。
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Elastic开源社区

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值