记录一次线上优化过程,一行代码结构化输出 es查询监控

1. 架构

前端 uni-app
后端 springboot +es +mysql
运维,算法,数据,后端,前端
分开,所以难以定位

2. 解决思路

是否运维机器配置问题
是否前端渲染问题
是否前端请求问题

1. 首先打开前端调式,从前端到后端,查看接口调用,及其不规律, 有时快有时慢

2. 加日志节点,切换日志级别

3. 加切面 结构化输出es 查询 , 定位问题代码

Strings.toString(queryBuilder, true, true);

上面第一个是业务需求必须多个属性一起查询 ,不过因为数据量比较小,所以性能还算可以
第二个明显是问题关键了,这个表中很慢,看查询语句我这里使用的是must + 结合 ,我这里不关心得分应该换成filter

更换之后发现效果并不明显,显然不是主要原因

直接在kibana中查询 文档中的总条数,已经达到了千万级,但是es 作为大数据时代的索引数据库,虽然一个文档的内容过多,但是性能不应该只是这样

接着找运维分析es的集群结构,发现虽然硬盘与内存都还有很大的空余,由于是测试库,使用的是单节点… 所以到此,问题关键已经很明显

性能差的主要原因有以下几点:

1. 首先,语句层,如果不关心得分应该使用filter
2. 其次,逻辑层,es 中应该只存放索引关键属性,而不是作为存储主力,数据量大可以考虑更换为 es+hbase
3. 然后,数据层可以考虑采取集群搭建es , 会比单机版性能提升很高