作者来自 Elastic Gustavo LlermalyElasticsearch 没有硬性的大小限制但有一些明确的信号表明你已经超出了当前架构的承载能力。了解如何为分片设定大小、管理节点限制、按分层选择存储以及使用 AutoOps 在问题发生之前进行检测。Elasticsearch 新手欢迎参加我们的 Elasticsearch 入门网络研讨会。你也可以开始免费云试用或现在就在你的本地机器上尝试 Elastic。Elasticsearch 没有硬性的大小限制。生产集群可以运行在 PB 级规模。但“过大”通常体现在三个方面查询速度慢到超出你的服务级别协议 SLA 某个节点达到其分片上限或者由于所有数据都存放在同一高成本存储层而导致存储成本失控。本指南将介绍这些信号、关键指标以及应对方法。真正重要的三个限制在节点层面没有硬性的存储上限。Elastic 曾演示单个节点查询 1 PiB 数据。在早期版本中每个分片的开销较高因此曾有经验法则每 GB 堆内存不超过 20 个分片。超过该限制会导致垃圾回收压力增大、集群状态更新变慢以及节点不稳定。在 7.x 和 8.x 版本中通过一系列优化更紧凑的元数据序列化、更高效的缓存、堆外数据结构以及压缩的集群状态每个分片的开销显著降低这一经验法则在 8.3 中被废弃取而代之的是基于字段密度的容量规划方法。真正决定上限的是工作负载类型。例如配置为 31 GB 堆内存、20 TB 存储的冷节点可以轻松处理审计和数据保留类工作负载因为其访问模式较少且以聚合为主。而相同配置在高并发文档搜索场景下则可能难以应对。需要重点关注的三个方面分片大小过大的单个分片会导致查询变慢以及恢复时间延长。每节点分片数每个节点都有上限而索引生命周期管理 ILM 会自动创建分片即使你没有主动跟踪。存储层不匹配数据在高成本快速存储层中保留时间过长。分片大小每个分片建议在 10 GB 到 50 GB 之间。官方建议将 ILM 的 rollover 触发点设置为每个主分片 50 GB并以 10 GB 作为建议下限。每个分片应控制在 2 亿个文档以内。分片过小会带来不必要的开销为主节点增加更多元数据、消耗更多堆内存、增加网络流量。分片过大则会导致查询执行变慢并且在节点故障后的恢复时间变长因为 Elasticsearch 一次只恢复一个分片。有一条规则可以不再使用“每 GB 堆内存不超过 20 个分片” 的经验法则已在 Elasticsearch 8.3 中被废弃。新的建议更简单关注下面的每节点 1000 个分片限制并将分片大小保持在 10–50 GB或 2 亿文档范围内。如何监控# size per shard GET _cat/shards?hindex,storev分片预算每个非冻结数据节点最多支持 1000 个分片。ILM 会自动为你创建分片。如果你的策略是按天 rollover并且有 5 个主分片和 1 个副本那么每天会产生 10 个分片。在不做任何调整的情况下一个节点大约在 100 天内就会被填满。当接近上限时的应对选项更长的 rollover 周期如果在时间触发之前分片没有达到 50 GB可以改为按周或按月 rollover。减少每个索引的分片数对于较小的每日数据量通常 1 到 2 个主分片就足够。如果需要重新平衡现有索引可以调整主分片数量。增加节点如果数据量确实需要按天 rollover 且分片数量较多可以通过增加节点来分摊负载。对于主节点建议按每 3000 个索引分配 1 GB 堆内存进行规划。如何监控# shards per node GET _cat/allocation?hnode,shardsv存储搜索速度指南建议将至少一半的系统内存分配给操作系统文件系统缓存并使用直连存储。远程存储通常性能较差。索引速度指南也强调了这一点建议在写入密集型工作负载中在多个本地 SSD 上使用 RAID 0。对于热数据不要使用网络附加存储 NAS 。NAS 会在每次读取时增加延迟而且一些 NAS 系统没有正确实现 POSIX 文件系统语义这可能导致数据损坏。应使用本地 SSD。各存储层适用方案分层存储原因热层本地 SSD DAS 高 I/O、低延迟、安全的文件系统语义温层HDD 可接受查询压力较低无活跃写入冷层可搜索快照无需副本约节省 50% 存储空间冻结层可搜索快照相比温层最多可降低 20 倍成本 Enterprise 许可证 如何监控# disk usage per node and role GET _cat/allocation?hnode,node.role,disk.used,disk.avail,disk.percentv在 Elastic Cloud 上可以跳过这一部分。你可以为每个分层选择硬件配置文件由 Elastic 负责存储配置。数据分层与 ILM索引生命周期管理 ILM 会自动在不同分层之间移动数据热、温、冷、冻结、删除。数据从热层向后移动得越远存储成本就越低。冷层和冻结层使用可搜索快照冷层完全挂载性能接近普通索引无需副本比温层约便宜 50%。冻结层部分挂载相比温层最多可减少 20 倍存储成本查询较慢需要 Enterprise 许可证。在规模化场景下成本差异非常显著。Search Labs 的一项基准测试对 90 TB 数据进行了测量全热层架构每月成本为 28,222 美元而热 冻结架构降至 3,290 美元。一个用于时间序列数据、热窗口为 14 天的典型 ILM 策略如下{ policy: { phases: { hot: { actions: { rollover: { max_primary_shard_size: 50gb } } }, warm: { min_age: 14d, actions: { shrink: { number_of_shards: 1 } } }, cold: { min_age: 30d, actions: { searchable_snapshot: { snapshot_repository: my_repository } } }, frozen: { min_age: 90d, actions: { searchable_snapshot: { snapshot_repository: my_repository } } }, delete: { min_age: 365d, actions: { delete: {} } } } } }根据你的查询模式调整 min_age 值。每周查询的数据可以比每天查询的数据更早转移到冷层。AutoOps截至 2026 年 2 月AutoOps 对所有 Elasticsearch 用户免费开放不受许可证等级限制。在 Elastic Cloud 上它已默认启用。对于 Elastic Self-Managed、Elastic Cloud Enterprise ECE 以及 Elastic Cloud on Kubernetes ECK 部署通过 Cloud Connect使用轻量级 Elastic Agent 连接集群大约 5 分钟即可完成。需要互联网连接不支持离线 air-gapped 部署。AutoOps 每 10 秒采样数百个指标并通过根因分析和修复命令提示问题。但它不会自动应用修复操作。对于大规模部署它可以检测分片大小超过推荐范围的增长情况。没有 ILM 策略且已增长过大的索引。节点之间的分片不均衡。在触发分配失败之前的磁盘水位线违规情况。索引拒绝与摄取瓶颈问题。大规模聚合导致的慢查询与 circuit breaker 触发。它内置超过 100 个可自定义告警并可将通知路由到 PagerDuty、Slack、Teams 或任何 webhook。结论关注分片大小10–50 GB在 ILM 运行过程中跟踪每节点分片预算将热数据放在本地 SSD 上并对很少查询的数据使用冷层和冻结层。在 Elastic Cloud 上硬件配置文件和 AutoOps 会帮你处理大部分这些问题。对于自建部署这是一份检查清单而通过 Cloud Connect 使用 AutoOps 则是你的早期预警系统。如果你不确定你的节点在特定工作负载下能承载多少数据可以在最终确定硬件规格前使用 Rally 用自己的数据进行基准测试。参考分片大小规划数据分层Elasticsearch 分片与副本指南如何减少分片数量如何增加主分片数量优化磁盘空间与使用可搜索快照基准测试AutoOps 文档RallyElastic 用于测试集群规模的基准框架Elastic 存储效率优化网络研讨会 Christian Dahlqvist 和 Alan Woodward 使用 Rally 进行集群规模规划网络研讨会 Christian Dahlqvist 和 Daniel Mitterdorfer关于基准测试方法论 原文https://www.elastic.co/search-labs/blog/elasticsearch-node-shard-size-best-practices