ElasticSearch性能优化篇

目录

一、 架构的设计

1.1   一个节点只承担一个角色的配置

1.2  主节点设计

二、 索引的设计

2.1 冷热数据分离

  1. 在配置文件中标记节点

2. 设置索引分配到热节点上

2.2 节点数的选择

2.3 索引的拆分

2.4 索引分片的设计


一、 架构的设计

1.1   一个节点只承担一个角色的配置

有条件的情况下一个节点只承担一个角色的配置:

  •   低 CPU、RAM 和磁盘的机器做 master 节点
  •   高性能 CPU、中等配置的 RAM 做 ingest 节点
  •   高性能 CPU、RAM、磁盘节点做 data 节点。

1.2  主节点设计

 一个实时的master节点,多个备用master节点。避免脑裂的同时又做到高可用。

二、 索引的设计

2.1 冷热数据分离

   将热点数据存储在磁盘性能较好的机器上,如固态硬盘,而冷数据存储在磁盘性能较差的机器上,具体操作如下:

  1. 在配置文件中标记节点

# 标记节点为热节点
node.tag: hot
# 标记节点为冷节点
node.tag: cold
node.max_local_storage_nodes: 2   #允许每个机器启动两个es进程(可选)

2. 设置索引分配到热节点上

PUT /_template/logstash
{
        "order": 0,
        "template": "logstash*",
        "settings": {
            "index.routing.allocation.include.tag": "hot",
            "index.refresh_interval": "30s",
            "index.number_of_replicas": "1",
            "index.number_of_shards": "1",
            "index.translog.flush_threshold_ops": "30000"
        }
}

“index.routing.allocation.include.tag”: “hot“: 表示新建索引将分配到 node.tag = hot 的节点下 

3. 设置定时任务,定期将索引迁移到冷节点上

PUT /index_name/_settings
{
   "index.routing.allocation.include.tag" : "cold"
}

这样旧索引数据会自动迁移到 cold 集群上。

2.2 节点数的选择

  节点数的选择与集群的用途相关,一般从用途上可分为两类:

     搜索:  固定大小的数据集

  • 搜索的数据集增长相对比较缓慢

     日志: 基于时间序列的数据

  • 使用ES存放日志与性能指标。数据每天不断写入,增长速度较快
  • 结合Warm Node 做数据的老化处理

硬件配置:

  • 选择合理的硬件,数据节点尽可能使用SSD
  • 搜索等性能要求高的场景,建议SSD按照1∶10-20的比例配置内存和硬盘
  • 日志类和查询并发低的场景,可以考虑使用机械硬盘存储,按照1:50的比例配置内存和硬盘
  • 单节点数据建议控制在2TB以内,最大不建议超过5TB
  • JVM配置机器内存的一半,JVM内存配置不建议超过32G
  • 不建议在一台服务器上运行多个节点

内存大小要根据Node 需要存储的数据来进行估算

  • 搜索类的比例建议: 1:16
  • 日志类: 1:48——1:96之间

假设总数据量1T,设置一个副本就是2T总数据量

  • 如果搜索类的项目,每个节点31*16 = 496 G,加上预留空间。所以每个节点最多400G数据,至少需要5个数据节点
  • 如果是日志类项目,每个节点31*50= 1550 GB,2个数据节点即可

2.3 索引的拆分

当索引数据量较大时,我们可以结合索引的业务特性进行拆分

  • 如果索引的数据随着时间推移,热度消退,比如日志类的索引,那么,可以考虑按时间命名索引。这样既能减少索引的大小,又能做到冷热数据分离处理。
  • 如果索引的数据属于均匀分布,与时间无关,则应考虑根据查询特性,是否能根据某个常用的查询条件进行拆分。比如各个地域的订单统计,可以考虑根据地域查询索引。
  • 如果某个常用的查询条件的值不固定,则可考虑启用Routing 功能,按照filter 字段的值分布到集群中不同的shard,降低查询时相关的shard数提高CPU利用率
# 将相同字段值的数据路由到同一个分片中,不仅可以减少查询时CPU的计算消耗,还能增加聚合、算分等操作结果的准确性
# es分片路由的规则:
shard_num = hash(_routing) % num_primary_shards
# _routing字段的取值,默认是_id字段,可以自定义。
 
PUT /users
{
  "settings": {
     "number_of_shards":2
  }
}
 
POST /users/_create/1?routing=lmj
{
  "name":"lmj"
}

 2.4 索引分片的设计

索引的分类

  索引分片可以分为两类:

  •  主分片: 主分片相当于将原有索引的数据拆分成若干个分片,起到水平分担压力的作用,主分片可读可写。
  •  副本分片:副本分片是主分片的数据备份,如果将索引的副本数设置为1,意味着该索引的每个主分片都有1个副本。副本分片只支持读取操作,不支持写入。

 主分片数的影响

    对于单个主分片来讲,一个请求过来,这个请求的压力只会打到某一个节点上,不能最大限度的发挥出集群的性能特性。但单个主分片在做聚合查询、评分时,不存在结果偏差,而多个主分片的索引可能会存在这种问题。如果将索引设置为多个主分片,在索引数据量比较大,单个请求比较耗性能时,这样设置会起到提升性能的作用,但会牺牲聚合查询、评分的结果准确性。而且,CPU的消耗随着主分片的线性递增,同时master节点管理分片的压力线性递增。所以在主分片过多的情况下集群的吞吐量可能反而下降。

副本分片的影响:

    副本分片起到数据备份和分担查询压力的作用,一般至少要有一个副本分片,避免数据丢失。副本数有限的增加会提升集群的查询吞吐量(原理同主分片增加一致),但会牺牲写入的性能,因为数据从主分片同步到副本分片也有性能消耗。

主副分片数设计的原则:

   从使用场景分析:

  • 搜索类应用,单个分片不要超过20 GB
  • 日志类应用,单个分片不要大于50 GB

  从堆内存的角度分析:

  •  在一个节点中的分片数小于20分片/每GB堆内存

  在数据量较大时使用分片不仅能提升性能,在某个节点下线丢失副本时也能更快的恢复。同时主分片时在设计之初就要考虑数据的增长速度,因为主分片数一旦设定后续不可动态调整。对于副本分片,应当保证至少有一个副本分片,避免主分片数据丢失后无法恢复,同时,主副分片总数尽可能的略微大于节点总数,这样不仅能最大限度的发挥集群性能,还能保证在集群新增节点时,有多余的副本可用,不会导致索引在某一个时刻不可用。

      本人近十年JAVA架构设计经验,长期从事IT技术资源整合。有志于自我技术提升、需要最新IT技术课程的小伙伴,可私信联系我 ,粉丝一律白菜价 

你可能感兴趣的:(ELK技术栈,elasticsearch,性能优化,大数据)