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

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 
  • 9
    点赞
  • 45
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 7
    评论
1、Elasticsearch 7.X 进阶实战大纲10个大选题来源于实战业务场景的提炼、总结。Elasticsearch 全貌认知Elasticsearch 索引创建和搜索原理Elasticsearch 集群规划及节点角色规划最佳实践Elasticsearch 集群性能调优及原理Elasticsearch 数据建模实例讲解与实战技巧Elasticsearch 冷温热架构讲解与实战Elasticsearch ILM 索引生命周期管理讲解与实战Elasticsearch CCS 跨集群搜索讲解与实战Elasticsearch 分片分配策略讲解与实战Elasticsearch 安全特性讲解与使用2、课程特色来源于项目实战、应用于实战项目。实战项目经验总结,属于基础后的进阶系列。基于 7.13 版本讲解,市面上教程都没有完整体现过该版本。近 10 个小时的视频,力求相对完整、体系、通透。 3、讲解方式干货凝练总结、侧重原理、深入浅出。每一讲脚本都可以提供下载,跟着学、学的会。视频共11大讲,每讲可以独立成课,方便大家地铁、公交车学习。录播方式,非直播。4、讲师:铭毅天下介绍Elastic认证工程师、Elastic中国合作培训讲师(有世界500强企业用户企业内训经验);阿里云MVP;死磕Elasticsearch知识星球发起人,全球付费用户1200人+(含中国台湾、美国硅谷、加拿大球友),已带领 60人+ 通过Elasticsearch 认证考试(中国仅通过100人左右);可能是中国最大Elastic技术公众号——铭毅天下Elasticsearch作者。CSDN博客专家、CSDN2020年度优秀创作者、CSDN2016年、2013年博客征文大赛特等奖得主;CSDN博客地址:elastic.blog.csdn.net;CSDN博客排名:近前150,阅读量近500,0000+;CSDN持续写作近十年(几乎每月都有输出,几乎从未间断),累计使用 Elasticsearch 超过 10000小时;Elastic中文社区日报责任编辑,2018年Elastic中文社区杰出贡献者、社区排名 TOP5;高级工程师、计算机应用技术硕士、近十年工作经验;理想主义者、终身学习者、终身成长者;笃信坚持、积累的力量;自1997年——至今20年+持续思考、积累、总结,从未间断;个人信条:自由不是你想干什么就干什么,而是你不想干什么就有能力不干什么!人因为梦想而伟大,机遇永远属于那些有准备、立即行动并能坚持到底的人!

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

Elastic开源社区

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

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

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

打赏作者

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

抵扣说明:

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

余额充值