在使用阿里云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。
- 单节点磁盘最大容量
使用场景不同,单节点最大承载数据量也会不同,具体如下:
- 数据加速、查询聚合等场景:单节点磁盘最大容量 = 单节点内存大小(GB)* 10。
- 日志写入、离线分析等场景:单节点磁盘最大容量 = 单节点内存大小(GB)* 50。
- 通常情况:单节点磁盘最大容量 = 单节点内存大小(GB)* 30。
本文以下表的集群规格为例,按照以上计算方式,得到的单节点最大数据量如下表所示。
规格 | 最大节点数 | 单节点磁盘最大容量(查询) | 单节点磁盘最大容量(日志) | 单节点磁盘最大容量(通常) |
---|---|---|---|---|
2核4 GB | 10 | 40 GB | 200 GB | 120 GB |
2核8 GB | 10 | 80 GB | 400 GB | 240 GB |
4核16 GB | 20 | 160 GB | 800 GB | 480 GB |
8核32 GB | 40 | 320 GB | 1.5 TB | 960 GB |
16核64 GB | 80 | 640 GB | 3 TB | 1.9 TB |
更多集群的规格信息,请参见阿里云Elasticsearch定价。
Shard评估
Shard大小和数量是影响阿里云Elasticsearch集群稳定性和性能的重要因素之一。Elasticsearch集群中任何一个索引都需要有一个合理的shard规划。合理的shard规划能够防止因业务不明确,导致分片庞大消耗Elasticsearch本身性能的问题。
说明 Elasticsearch 7.0以下版本的索引默认包含5个主shard,1个副shard;Elasticsearch 7.0及以上版本的索引默认包含1个主shard,1个副shard。
在进行shard规划前,请先考虑以下几个问题:
- 当前单个索引的数据多大
- 数据是否会持续增长
- 购买的实例规格多大
- 是否会定期删除或者合并临时索引
基于以上问题,下文对shard规划提供了一些建议。这些建议仅供参考,实际业务中还需根据需求进行调整:
- 建议在分配shard前,对Elasticsearch进行数据测试。当数据量很大时,要减少写入量的大小,降低Elasticsearch压力,建议选择多主1副本;当数据量较小,且写入量也比较小时,建议使用单主多副本或者单主1副本。
- 建议一个shard的存储量保持在30 GB以内(最优),特殊情况下,可以提升到50 GB以内。如果评估结果超过该容量,建议在创建索引前,合理进行shard分配,后期进行reindex,虽然能保证不停机,但是比较耗时。
说明 对于评估数据量低于30 GB的业务,也可以使用1主多备的策略进行负载均衡。例如20 GB的单索引,在5个数据节点中,可以考虑1主4副本的shard规划。
- 对于日志分析或者超大索引场景,建议单个shard大小不要超过100 GB。
- 建议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 GB的数据节点,建议配置2个8核32 GB的独立协调节点。
说明 使用独立的协调节点,可以对最终的结果进行reduce操作,这样即使reduce阶段出现GC严重的现象,也不会影响数据节点。
- 如果开启了自动创建索引功能,建议启用索引生命周期管理,或者通过Elasticsearch API脚本删除过期的索引。
- 建议及时清理小索引(同样会占用Elasticsearch堆内存)。