一、ES集群的磁盘空间评估

影响ES磁盘空间的因素有以下几点：

• 副本数量。至少1个副本。
• 索引开销。通常比源数据大10%（_all等未计算）。
• 操作系统预留。操作系统默认会保留**5%**的文件系统供用户处理关键流程、系统恢复以及磁盘碎片等。
• ES内部开销。段合并、日志等内部操作，预留20%。
• 安全阈值。通常至少预留**15%**的安全阈值。

根据以上因素得到：最小磁盘总大小 = 源数据大小 * 3.4。

磁盘总大小 = 源数据 * (1 + 副本数量) * (1 + 索引开销) / (1 - 操作系统预留空间) / (1 - ES内部开销) / (1 - 安全阈值) = 源数据 * (1 + 副本数量) * 1.7 = 源数据 * 3.4

注意

• 对于**_all**这项参数，如果在业务使用上没有必要，通常建议您禁止或者有选择性地添加。
• 对于需要开启这个参数的索引，其开销也会随之增大。根据测试结果和使用经验，建议您在上述评估的基础上额外增加一半的空间，即：磁盘总大小 = 源数据 * (1 + 副本数) * 1.7 * (1 + 0.5) = 源数据 * 5.1

二、集群节点规模评估

ES的单机规格可能会对集群的能力有所限制，因此在使用Elasticsearch服务前，首先需要对集群规格进行评估，并根据评估结果进行扩容、升配等操作。本文档根据测试结果和使用经验给出如下建议。

• 集群最大节点数：集群最大节点数 = 单节点CPU * 5。
• 单节点最大承载的数据量：使用场景不同，单节点最大承载的数据量也会不同，具体如下。
  • 数据加速、查询聚合等场景：单节点最大数据量 = 单节点Mem(G) * 10。
  • 日志写入、离线分析等场景：单节点最大数据量 = 单节点Mem(G) * 50。
  • 通常情况：单节点最大数据量 = 单节点Mem(G) * 30。

单节点最大磁盘（查询）单节点最大磁盘（日志）单节点最大磁盘（通常）2C 4G1040 GB200 GB100 GB2C 8G1080 GB400 GB200 GB4C 16G20160 GB800 GB512 GB8C 32G40320 GB1.5 TB1 TB16C 64G50640 GB2 TB2 TB

三、分片Shard评估

shard大小和个数是影响Elasticsearch集群稳定性和性能的重要因素之一。Elasticsearch集群中任何一个索引都需要有一个合理的shard规划（默认为5个）。

• 建议在小规格节点下单shard大小不要超过30GB。更高规格的节点单shard大小不要超过50GB。
• shard的个数（包括副本）要尽可能匹配数据节点数，等于数据节点数，或者是节点数的整数倍，比如集群单中心的数据节点有10个，那么分片最佳分片数建议为10，保证每个节点上都均分一个分片。
• 建议单节点上同一索引的shard个数不要超过5个。

说明

• 由于不同用户在数据结构、查询复杂度、数据量大小、性能要求以及数据的变化等诸多方面是不同的，因此本文的评估仅供参考，不一定适用于所有用户。
• 在条件允许的情况下，您可以通过实际的数据和使用场景测试出适合自己的集群资源规划。

ES集群配置最佳实践

1.磁盘选择

• 尽可能使用使用SSD，ES最大的瓶颈往往是磁盘读写性能，SSD要比SATA查询快5-10倍，所以查询要求高的业务建议选择SSD或者PCIE，查询要求不那么高的业务可以选择SATA
• 对于数据节点建议使用单机器500G以上的磁盘
• 对于协调节点，200G足矣，协调节点不存数据，只做转发和聚合

2.内存选择

• 尽可能选择16G以上，由于ES的段文件(索引文件)存储在缓存中，尽量满足所有的段文件都存在缓存中，提高查询的效率
• ES JVM配置机器一半的内存，但是不要超过32G
• 内存和磁盘1：10

3.集群角色配置

• 数据节点和协调节点隔离，避免协调节点因数据问题down机之后导致整个集群崩溃
• 集群尽量配置固定数量的协调节点（一般3个足矣），数据节点可以扩展

4.分片和副本设置

• 每个数据节点上都尽量分配某个索引的一个分片，使数据足够均匀
• 每个索引分片不要超过30G
• 单节点数据控制再2T以内
• 单索引size小于1g的，主分片数量不得大于5
• 单集群索引数量不得大于3k
• 单集群（总）分片数量不得大于1w

5.调大refresh interval调高

ES的refresh操作：是将index-buffer中文档（document）解析完成的segment写到filesystem cache中的过程

1. ES 默认每个分片每秒钟都会进行一次refresh，刷新的过程其实就是文档从索引到被搜索的过程，刷新后会生成新的段，这会产生大量的段文件

2. 如果业务对数据的实时性要求不高，可以调高

   PUT /twitter/_settings
   {
     "index" : {
     "refresh_interval" : "1s" 
     } 
   }
   

6.translog同步改异步

translog的作用是用于恢复数据，数据在被索引之前会被先加入至translog中，默认情况下translog是每写一次就刷盘一次，可以改成异步刷新

PUT /my_index/_settings 
{
  "index.translog.durability": "async", 
  "index.translog.sync_interval": "5s" 
}

7.定期进行段文件合并

注意ES得索引倒排索引文件是存在segment中，segment是存在内存中，由于每次refresh都会生产新的segment，如果segment过多会消耗较大内存，定期进行段合并有几个好处

1. 减少内存消耗

2. 加快查询性能，每次搜索请求都需要依次检查每个段。段越多，查询越慢。

3. 合并段的同时会把释放已删除的索引空间，业务如果使用delete by id进行索引删除，es只是把数据标记为已删除，并没有释放空间，在segment合并时会把这些数据进行清理

   如下：这里的max_num_segments是希望最终合并成多少个段

   POST /twitter/_forcemerge/max_num_segments=1

8.使用索引模板

如果索引未来的增长比较快，并且存在明显的 冷热区分(旧索引访问热度低或者无访问)，那烦请使用索引模板，按日期方式创建，索引，这样对应旧索引可以方便的删除或者隔离

随着业务不断发展，集群的节点和shard数量瓶颈问题日益严重，业务不得不通过删除索引、横向扩展集群数量来缓解瓶颈问题。

集群分片数量合理性配置

1 合理的集群分片配置

目前在索引社区在扩展性配置主要是：

1、Aim for shard sizes between 10GB and 50GB

2、Aim for 20 shards or fewer per GB of heap memory

3、cluster.max_shards_per_node default 1000

4、集群合理的shard数控制在3K以内。

2 集群索引或分片数量过大，引起的扩展性问题

1、创建索引耗时长（6W分片耗时超过5s）

2、pending task 堆积，导致集群被打爆。

3、节点数受限。

4、集群资源碎片化，运维成本高

5、重启效率低下

6、监控统计接口导致集群内存堆积，影响集群稳定性