规格容量评估

注意事项

本文根据实际测试结果和用户使用经验提供评估方法。由于不同用户在数据结构、查询复杂度、数据量大小、性能及数据变化等方面的需求不同，本文的评估不一定适用于所有用户。建议您在条件允许的情况下，通过实际的数据和使用场景测试出适合自己的集群规格容量规划。

评估集群存储空间

影响ES集群存储空间大小的因素主要包括：

• 源数据的大小。

• 索引的副本数量：每个索引至少需要1个副本。

• 索引开销：通常比源数据大10%。

  例如，存储X-Pack组件用于异常分析的监控类索引，主要包含：

  • .monitoring-es-6-*：占用空间相对比较大，默认保留最近7天的索引数据。

  • .monitoring-kibana-6-*：索引数越大占用空间也越大，默认保留最近7天的索引数据。

  • .watcher-history-3-*：占用空间相对比较小，如果开启，需要您手动删除。

• ES实例内部开销：段合并、日志等内部操作，预留20%。

  存储集群日志（包括运行日志、访问日志和慢日志）随着查询或推送访问量的增加，空间占比不断增大，默认保留最近7天的日志，不支持修改。

• 操作系统预留空间：默认操作系统会保留5%的文件系统供您处理关键流程、系统恢复以及磁盘碎片等。

• 安全阈值：通常至少预留15%的安全阈值。

根据以上因素得到建议集群存储空间：

集群存储空间 = 源数据 *（1 + 副本数量）* 索引开销 /（1 - 操作系统预留空间）/（1 - ES实例内部开销）/（1 - 安全阈值）
             = 源数据 *（1 + 副本数量）* 1.7
             = 源数据 * 3.4

主分片数量不会影响磁盘空间占用：增加主分片时，数据会在分片之间重新分布，总数据量不变，因此不会增加磁盘空间占用。增加副本数量会按比例增加磁盘使用：每增加一个副本，都会完整复制一份源数据，对应上述公式中的（1 + 副本数量）因子，副本数量越多，磁盘占用越大。

因此，当单个分片存储量过大时，建议通过增加主分片来解决，而不是增加副本。可以通过 _split API 拆分索引，或者重建索引（reindex）来调整分片数量。

评估节点规格和节点数量

数据节点

• 最大节点数量 = 单节点CPU大小 * 5。

• 业务场景不同，单节点最大承载数据量也不同：

  • 通用场景：单节点最大存储空间 = 单节点内存大小（GiB）* 30。

  • 搜索场景（数据库加速、查询聚合等）：单节点最大存储空间 = 单节点内存大小（GiB）* 10。

  • 日志分析场景（日志写入、离线分析等）：单节点最大存储空间 = 单节点内存大小（GiB）* 50。

根据以上计算方式，得到部分节点规格的最大节点数量和单节点最大存储空间：

集群存储空间=单节点存储空间*节点数量，您可以根据单节点最大存储空间和最大节点数量选择满足业务要求的节点规格。

专有主节点

如果集群的数据节点较多，建议您开启专有主节点，以保证集群稳定性。

专有主节点规格选择：

• 初始规格：2 核8 GiB

• 超过10个数据节点：4 核16 GiB

• 超过30个数据节点：8 核32 GiB

• 超过50个数据节点：16 核64 GiB

协调节点

使用独立的协调节点，可以对最终的结果进行reduce操作，这样即使reduce阶段出现GC严重的现象，也不会影响数据节点。

如果开启协调节点，建议协调节点与数据节点个数的比例为1:5（协调节点2个起购），协调节点建议选择1:4或1:8规格族。例如，10个8核32 GiB的数据节点，建议配置2个8核32 GiB的协调节点。

评估Shard

Shard存储量和数量是影响阿里云ES集群稳定性和性能的重要因素之一。ES集群中任何一个索引都需要进行合理的Shard规划，防止因业务不明确导致分片庞大消耗ES本身性能，或导致负载不均衡，例如节点间磁盘使用率差距很大，节点CPU使用率呈现明显的负载不均衡。

基于以上问题，下文对Shard规划提供了一些建议。这些建议仅供参考，实际业务中还需根据需求进行调整：

• Shard存储量

  • 建议单个Shard存储量保持在30 GiB以内（最优），特殊情况下可以提升到50 GiB以内。

  • 对于日志分析或者超大索引场景，建议单个Shard存储量不要超过100 GiB。

• Shard数量

  • 在分配Shard前，建议对ES进行数据测试。

    • 数据量很大时，需要减少写入量的大小，降低ES压力，建议选择多主1副本。

    • 数据量较小，且写入量也较小时，建议使用单主多副本或者单主1副本。

    说明

    • 7.x及以上版本实例默认一个索引创建1个主分片和1个副本分片。7.x以下版本实例默认一个索引创建5个主分片，并分别为每个主分片创建1个副本分片。

    • Shard存储量低于30 GiB的业务，可以使用单主多副本的策略进行负载均衡。例如，20 GiB的单索引，分布在5个数据节点中，可以考虑单主4副本的Shard规划。

  • 建议Shard个数（包括主分片和副本分片）尽可能等于数据节点数，或者是数据节点数的整数倍。

  • 建议单个节点上同一索引的Shard个数不要超过5个。

  • 建议按照以下说明，评估单个节点上全部索引的Shard数量。

    • 小规格实例参考：单个数据节点的Shard数量 = 当前节点的内存大小 * 30

    • 大规格实例参考：单个数据节点的Shard数量 = 当前节点的内存大小 * 50

    说明

    • 评估Shard数量时，还需结合数据量进行分析，建议TiB级别以下的数据量参考小规格实例进行评估。

    • 7.x版本ES实例默认的单节点Shard上限为1000个（官方不建议调整），您可以通过增加或扩容节点数量来调整单节点的Shard数量。

    • Shard个数不是越多越好。主分片越多ES性能开销也会越大，shard数量太多极易引起文件句柄耗尽，导致集群故障。

当集群中同时存在多个业务索引时，上述建议需要按索引逐个落到具体的主分片数。您可以按以下步骤规划：

1. 统计每个索引的现状与增长趋势。使用GET _cat/indices?v&bytes=b查看各索引当前的存储大小，并结合每日增量和数据保留周期，估算每个索引在保留周期内的预计存储量。日志类按天或按周滚动的索引，按单个滚动周期的数据量估算，不按累计量估算。

2. 按单个Shard存储量计算主分片数。以单个Shard存储量30 GiB以内为最优目标，特殊情况下可放宽到50 GiB以内，即主分片数 = 索引预计存储量 ÷ 单个Shard目标存储量，结果向上取整。存储量低于30 GiB的小索引保持1个主分片，通过增加副本分片做负载均衡。

3. 用数据节点数量校正主分片数。调整上一步的结果，使该索引的Shard总数（主分片数 × (1 + 副本分片数)）等于数据节点数或其整数倍，同时保证单个节点上同一索引的Shard个数不超过5个。例如某索引预计存储量360 GiB，按30 GiB目标得到12个主分片，集群有6个数据节点，12是6的整数倍，配置1个副本分片后Shard总数为24，仍为6的整数倍，规划成立。

4. 汇总校验单节点Shard总量。把所有索引的Shard数量相加后除以数据节点数，与本文给出的单个数据节点Shard数量上限（小规格实例为节点内存大小 × 30，大规格实例为节点内存大小 × 50，7.x版本实例默认单节点上限1000个）比对。超出上限时优先合并或清理低价值的小索引，其次通过增加或扩容节点数量提升上限。

5. 让规划生效。主分片数只能在创建索引时指定，因此规划结果需要区分新索引和已有索引落地：新索引在实例详情的ES集群配置 > 场景化配置 > 索引模板配置中写入分片设置，该模板仅在创建索引时应用，更改模板不会影响已有索引；已有索引需要通过_splitAPI拆分或者reindex重建索引来调整主分片数。

规划落地后，如果出现节点间磁盘使用率或CPU使用率差距较大的现象，或在事件中心看到节点CPU负载不均衡事件，说明问题在Shard分布而不是Shard总量，可以按集群负载不均分析中的方法定位到具体的索引和节点后再调整。

关于评估Shard的更多信息，请参见How to size your shards。

相关文档

• 了解不同地域和版本支持的节点规格或购买ES实例，请参见购买页。

• 了解不同节点规格的性能，可以参考阿里云ES实例不同规格和版本的压测实验结果，请参见产品性能。

• 如果您对选择实例类型（通用商业版、内核增强型）或实例版本有疑问，请参见版本特性。

• 对于已存在的集群，您可以根据评估结果调整节点规格、节点存储空间、节点数量等。具体操作和限制，请参见升配集群和降配集群。

• 主分片的数量只能在创建索引时指定，并且创建索引后不能更改。创建索引，请参见创建索引。

• 对于已存在的索引，如果Shard超过推荐存储量，建议通过reindex重建索引。具体操作，请参见阿里云ES间跨集群reindex。

  说明

  reindex能保证不停机，但是比较耗时。

• 集群负载不均问题的分析方法及解决方案。

• 通过手动迁移shard均匀分布热点数据的解决方案。

• 如果开启了自动创建索引功能，建议启用索引生命周期管理，或者通过ES API脚本删除过期的索引。

• 建议及时清理小索引，小索引同样会占用ES堆内存。

ES索引存储空间差异大的常见原因

不同索引之间的存储空间可能存在较大差异，常见原因及排查方法如下：

• 分词器设置不同：ngram分词器将文本切分为指定长度的字符组合，产生的token数量远多于standard分词器，导致倒排索引更大。例如相同文档使用ngram（min_gram=1, max_gram=4）分词器的索引存储约为standard分词器的3.4倍。

• 字段类型和mapping设置不同：text类型字段会构建倒排索引，keyword类型不会。不同mapping配置直接影响存储占用。

• 副本数量不同：number_of_replicas参数设置越高，总存储占用越大。

• 压缩方式不同：best_compression使用DEFLATE算法，压缩比高于default的LZ4算法，但读写性能略有降低。

排查存储差异的方法：

• 使用GET _cat/indices?v&bytes=b查看各索引的存储大小。

• 使用POST <index>/_disk_usage?run_expensive_tasks=true分析字段级存储分布，定位占比较大的字段。

常见问题

如何判断ES实例是否需要扩容，以及IOPS、磁盘带宽是否存在风险？

先用监控指标判断整体资源是否接近边界，再用事件判断磁盘IO是否已成为瓶颈，最后按短期和长期两条路径处置。

判断是否需要扩容

在实例详情的集群监控 > 基础监控中，把时间范围切到7天，观察节点CPU使用率（%）、节点磁盘使用率（%）、节点HeapMemory使用率（%）、节点load_1m四条资源类曲线，并结合集群状态、集群写入QPS（Count/Second）和集群查询QPS（Count/Second）判断压力来源。资源类指标长期处于高位（经验参考：持续高于80%）时，即使没有收到告警，集群也已经接近容量边界，写入和查询延迟会随流量波动放大，建议考虑升配。水位参考值可以对齐一键报警的默认规则：节点磁盘使用率超过75%、节点JVM Heap使用率超过85%即视为异常。存储维度还可以用本文「评估集群存储空间」的公式和「数据节点」章节的单节点最大存储空间反推当前规格还能承载多少数据。

识别IOPS与磁盘带宽风险

基础监控提供的是上述7个指标，不包含独立的IOPS曲线和磁盘带宽（吞吐量）曲线，因此磁盘IO是否触及上限需要通过事件判断。在事件中心按发生时间和事件等级（信息、警告、严重）筛选，重点关注以下事件：

云盘的IOPS与吞吐量上限随存储类型和单节点存储空间变化，选型阶段可以在购买页或升配页的存储类型说明中确认各类云盘的适用场景：SSD云盘适合拥有高IOPS、数据响应度较高的在线分析和搜索场景，高效云盘面向大规模数据量的日志及分析场景。

处置建议

• 短期缓解：优化查询，减少不必要的聚合、深分页和通配符前缀查询；对存储量已经偏大的索引，按业务重要性下调副本分片数量以降低写入与磁盘压力；按本文「评估Shard」重新核对分片规划。需要注意主分片数量只能在创建索引时指定，已有索引只能通过_splitAPI或者reindex重建索引调整，不能在线修改。

• 长期扩容：在实例列表中通过行操作升配提升节点规格、增加节点数量或扩容存储空间，具体操作和限制请参见升配集群。开发者规格实例升配期间服务会中断，且升配到普通规格后无法降回开发者规格，请安排在业务低峰期操作。

• 如果只有部分节点资源高位、其余节点空闲，先按集群负载不均分析排查负载不均，扩容无法解决分布不均带来的性能问题。

• 开启一键报警，在磁盘使用率、JVM Heap使用率和集群状态出现异常时提前收到通知，避免等到查询超时才发现容量不足。