在使用阿里云Elasticsearch前,请先评估集群所需的资源容量,包括磁盘容量、集群规格、shard大小和数量等。本文根据实际测试结果和用户使用经验,提供了相对通用的评估方法。您可以参考本文的内容,初步规划集群的规格容量,以此为依据购买或升配集群。
注意事项
由于不同用户在数据结构、查询复杂度、数据量大小、性能及数据变化等方面的需求不同,所以本文的评估不一定适用于所有用户。建议您在条件允许的情况下,通过实际的数据和使用场景测试出适合自己的集群规格容量规划。
磁盘容量评估
影响阿里云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堆内存)。