数栈优化案例:物流客户Elasticsearch集群性能优化

2021/4/19 18:29:58

本文主要是介绍数栈优化案例:物流客户Elasticsearch集群性能优化,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

一、客户背景

客户使用ES来进行数据存储、快速查询业务订单记录,但是经常会出现业务高峰期ES集群的cpu负载、内存使用均较高,查询延迟大,导致前端业务访问出现大量超时的情况,极大影响其客户使用体验。

部分监控如下图:

1、 集群架构如下:

集群节点配置:8数据节点(16C64G);3主节点(8C32G)


2、 集群存在问题分析

  • 业务层面

    与客户业务人员沟通,业务处理中有几个聚合查询会占用较多的内存,且这类查询对准确性要求较高,需精确统计所有匹配结果。

  • 架构层面

      存在4-5T的单个较大索引,该索引字段多达2000+,分片大小普遍60G+,最高达到130G+,是制约查询性能的一个较大瓶颈,另外集群在业务高峰期还会出现经常的fullgc,这是出现访问超时的直接原因。 

 如图:


二、Elasticsearch集群优化

与客户开发人员沟通了解集群在业务上存在的问题,结合我们在ES这块的服务经验,从语句参数、索引、架构等多个角度给客户提出调优建议。

1、语句、参数调优

客户已提供4个慢查询语句,语句中聚合查询使用"execution_hint": "map",该执行策略会把命中的记录都捞回内存中,一旦查询结果较大就会占用大量内存。建议使用terminator_after,此方法可以控制查询结果数量,另外将不参与聚合、排序的字段设置为doc_values:false, 节省磁盘空间提升索引速度。

2、 集群架构优化:

在原有集群基础上添加协调节点或者扩容数据节点:

  • 添加协调节点:优点是可以减轻数据节点压力,变更较为容易,缓解fullgc频繁出现的问题;
  • 扩容数据节点:优点是可以减轻当前数据节点压力,也可以减小分片大小;但是增加索引分片需要重新创建索引,重新导入数据,且当前节点存储压力不大,同时增加数据节点对存储空间有一定的浪费。

结合客户业务特性,我们推荐客户使用添加协调节点的方式对集群架构进行优化。

3、 集群索引优化:

可以对集群进行索引拆分和使用别名两方面进行优化调整。

  • 拆分索引:对索引字段进行拆分并确认大小,可以解决当前索引分片过大的问题,提升查询性能。
  • 使用别名:根据日期定期创建新的索引(建议按月创建索引),根据业务对统一查询的索引创建统一别名,该方法可以彻底解决当前索引分片过大问题,优化查询性能。


三、集群优化效果

集群优化后整体性能有明显提升:

a. ES集群负载、内存较为平稳,业务高峰期不会有较大波动;

b. ES集群FullGC出现频次极大降低,降低对业务的影响;

c. ES聚合查询延迟减小,业务数据查询性能提升,速度达到百毫秒级别


四、写在最后

袋鼠云通过数据集成优化、任务调度优化、代码优化、全链路数据质量保障、故障紧急处理、大数据平台运维,为客户提供大数据系统运维保障服务。


本文整理自:袋鼠云技术荟 | 某物流客户Elasticsearch集群性能优化案例

数栈是云原生—站式数据中台PaaS,我们在github和gitee上有一个有趣的开源项目:FlinkX,FlinkX是一个基于Flink的批流统一的数据同步工具,既可以采集静态的数据,也可以采集实时变化的数据,是全域、异构、批流一体的数据同步引擎。大家喜欢的话请给我们点个star!star!star!

github开源项目:https://github.com/DTStack/flinkx

gitee开源项目:https://gitee.com/dtstack_dev_0/flinkx



这篇关于数栈优化案例:物流客户Elasticsearch集群性能优化的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程