在使用阿里云Elasticsearch前，请先评估集群所需的资源容量，包括磁盘容量、集群规格、shard大小和数量等。本文根据实际测试结果和用户使用经验，提供了相对通用的评估方法。您可以参考本文的内容，初步规划集群的规格容量，以此为依据购买或升配集群。
注意事项
快速选型
阿里云Elasticsearch基于不同的业务场景维度，为您提供了一款Elasticsearch集群选型工具。该工具的使用方式如下：
-
进入 Elasticsearch购买页 。
-
在页面右侧，单击 容量规划 。
-
按照业务场景填写数据，单击 进行测算 。
-
在 推荐配置 页面，单击 下载配置 ，下载并打开对应文件。
-
根据文件中的配置，选择集群配置，完成集群创建。
磁盘容量评估
影响阿里云Elasticsearch集群磁盘空间大小的因素包括：
-
副本数量：至少1个副本。
-
索引开销：通常比源数据大10%（
_all参数等未计算）。 -
操作系统预留空间：默认操作系统会保留5%的文件系统供您处理关键流程、系统恢复以及磁盘碎片等。
-
Elasticsearch内部开销：段合并、日志等内部操作，预留20%。
-
安全阈值：通常至少预留15%的安全阈值。
根据以上因素得到：最小磁盘总大小 = 源数据大小 * 3.4。计算方式如下。
磁盘总大小 = 源数据 *（1 + 副本数量）* 索引开销 /（1 - 操作系统预留空间）/（1 - Elasticsearch内部开销）/（1 - 安全阈值）
= 源数据 *（1 + 副本数量）* 1.7
= 源数据 * 3.4
说明
集群规格评估
阿里云Elasticsearch的单机规格在一定程度上限制了集群的能力，本文根据测试结果和使用经验给出如下建议：
-
集群最大节点数 = 单节点CPU * 5。
-
单节点磁盘最大容量
使用场景不同，单节点最大承载数据量也会不同，具体如下：
-
数据加速、查询聚合等场景：单节点磁盘最大容量 = 单节点内存大小（GiB）* 10。
-
日志写入、离线分析等场景：单节点磁盘最大容量 = 单节点内存大小（GiB）* 50。
-
通常情况：单节点磁盘最大容量 = 单节点内存大小（GiB）* 30。
-
本文以下表的集群规格为例，按照以上计算方式，得到的单节点最大数据量如下表所示。
|
规格 |
最大节点数 |
单节点磁盘最大容量（查询） |
单节点磁盘最大容量（日志） |
单节点磁盘最大容量（通常） |
|
2核4 GiB |
10 |
40 GiB |
200 GiB |
120 GiB |
|
2核8 GiB |
10 |
80 GiB |
400 GiB |
240 GiB |
|
4核16 GiB |
20 |
160 GiB |
800 GiB |
480 GiB |
|
8核32 GiB |
40 |
320 GiB |
1.5 TiB |
960 GiB |
|
16核64 GiB |
80 |
640 GiB |
3 TiB |
1.9 TiB |
更多集群的规格信息，请参见 阿里云Elasticsearch定价 。
Shard评估
Shard大小和数量是影响阿里云Elasticsearch集群稳定性和性能的重要因素之一。Elasticsearch集群中任何一个索引都需要有一个合理的shard规划。合理的shard规划能够防止因业务不明确，导致分片庞大消耗Elasticsearch本身性能的问题。
说明
Elasticsearch 7.0以下版本默认一个索引创建5个主分片，并分别为每个主分片创建1个副本分片；7.0及以上版本默认一个索引创建1个主分片和1个副本分片。
在进行shard规划前，请先考虑以下几个问题：
-
当前单个索引的数据多大
-
数据是否会持续增长
-
购买的实例规格多大
-
是否会定期删除或者合并临时索引
基于以上问题，下文对shard规划提供了一些建议。这些建议仅供参考，实际业务中还需根据需求进行调整：
-
建议在分配shard前，对Elasticsearch进行数据测试。当数据量很大时，要减少写入量的大小，降低Elasticsearch压力，建议选择多主1副本；当数据量较小，且写入量也比较小时，建议使用单主多副本或者单主1副本。
-
建议一个shard的存储量保持在30 GiB以内（最优），特殊情况下，可以提升到50 GiB以内。如果评估结果超过该容量，建议在创建索引前，合理进行shard分配，后期进行reindex，虽然能保证不停机，但是比较耗时。
说明对于评估数据量低于30 GiB的业务，也可以使用1主多备的策略进行负载均衡。例如20 GiB的单索引，在5个数据节点中，可以考虑1主4副本的shard规划。
-
对于日志分析或者超大索引场景，建议单个shard大小不要超过100 GiB。
-
建议shard的个数（包括副本）要尽可能等于数据节点数，或者是数据节点数的整数倍。
说明主分片不是越多越好，因为主分片越多，Elasticsearch性能开销也会越大。
-
建议单个节点上同一索引的shard个数不要超5个。
-
建议按照以下说明，评估单个节点上全部索引的shard数量：
-
单个数据节点的shard数量 = 当前节点的内存大小 * 30（小规格实例参考）
-
单个数据节点的shard数量 = 当前节点的内存大小 * 50（大规格实例参考）
重要-
在评估shard数量时，还需结合数据量进行分析，建议TB级别以下的数据量参考小规格实例进行评估。
-
在单节点上，7.x版本实例默认的shard的上限为1000个（官方不建议调整），建议在使用前通过扩容节点来调整单节点的shard数量。
-
-
建议按照1:5的比例添加独立的协调节点（2个起），CPU:Memory为1:4或1:8。例如10个8核32 GiB的数据节点，建议配置2个8核32 GiB的独立协调节点。
说明使用独立的协调节点，可以对最终的结果进行reduce操作，这样即使reduce阶段出现GC严重的现象，也不会影响数据节点。
-
如果开启了自动创建索引功能，建议启用 索引生命周期管理 ，或者通过Elasticsearch API脚本删除过期的索引。
-
建议及时清理小索引（同样会占用Elasticsearch堆内存）。