baseball,
console game,
musical&classical&rock,
LEGO,
programmer.

ES容量预估最佳实践

一、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、监控统计接口导致集群内存堆积,影响集群稳定性