Hawkeye:TopN慢query的获取与优化

本文涉及的产品
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
OpenSearch LLM智能问答版免费试用套餐,存储1GB首月+计算资源100CU
推荐全链路深度定制开发平台,高级版 1个月
简介: 之前的文章介绍了Hawkeye的底层分析系统(待补充文章),其中讲到了基于Blink的Batch任务实现方法,前段时间在优化慢query查询的过程中开发了应用TopN慢query获取的分析任务,其中用到的分析方法适用于其他类似求TopN的问题中。

Hawkeye的底层分析系统基于Blink进行大数据分析,前段时间在优化慢query查询的过程中开发了应用TopN慢query获取的分析任务,其中用到的分析方法适用于其他类似求TopN的问题中。本文的TopN问题属于批处理范畴。

一、背景

经过hawkeye之前的慢query分析,每个应用不同程度的存在慢query,大量的慢query大大影响了引擎的性能,也会带来机器资源的浪费。为了优化Ha3的查询性能,我们将分析更深入了一步,分为如下三部分进行慢query的优化。。

  • 应用TopN慢query的获取:获取top50的慢query,并分析出查询各阶段耗时占比;
  • 各阶段耗时优化&验证:几种常见的优化手段,这些优化手段均是通过验证有效的方法;
  • 优化收益评估:经过优化带来的价值主要体现在慢查询数的减少和容量预估的增加。

二、TopN慢查询获取流程

慢query数据来自应用的访问日志,query数量和应用的访问量有关,通常在千万甚至亿级别。从海量日志中获取TopN慢query属于大数据分析范畴。我们借助Blink的大数据分析能力,采用分治+hash+小顶堆的方式进行获取,即先将query格式进行解析,获取其查询时间,将解析后的k-v数据取md5值,然后根据md5值做分片,在每一个分片中计算TopN慢query,最后在所有的TopN中求出最终的TopN。下面图示为慢query任务的处理过程。

image.png

定时任务每天执行一次,将应用昨天的AccessLog按照上述流程处理一遍,从而获取应用的Top50慢query,从获取的top50慢query可以分析出一些应用访问不合理的地方,虽然不能完全代表高频慢query,但对于Top级的query优化也可以持续的对应用进行优化,提高查询性能,节约机器资源。

三、慢query的优化手段

按照平台用户易优化的原则,根据分析的结论数据提供了四种不同的query优化手段,按照阶段分为:

粗排阶段三种:

  • rank_size数过大,建议减少rank_size数量,可能会影响效果,需业务方评估;
  • rank_size数量合理,但粗排阶段耗时占比超过50%,检查海选插件的性能;
  • 正排过滤改为倒排召回,对于特定场景有很大作用,第四部分会讲到具体case;

精排阶段一种:

  • 战马耗时占比超过50%,建议检查战马相关插件的性能。

目前的优化手段在tisplus2平台上进行透出,点击优化可以看到诊断具体慢query的优化建议,如果上述四条建议条件均不满足,则需要联系平台管理员具体诊断下慢的原因了。

四、优化的收益

第四部分介绍下采用上述优化带来的效果,某应用采用正排过滤改为倒排召回的优化,采用此优化的前提是:1.swift消息无update消息;2.对应字段是可枚举类型;3.非子doc并且seek数远大于match数。采用此优化之后,慢query数直线下降,由百万级别降到0,且容量预估提升了8倍(即相同资源可抗的访问量上涨了8倍)。

五、总结

目前慢query的优化功能已上线,用户可以自行查看应用的访问状况和访问较慢的query,并针对性的进行分析和初步的优化,相比较之前是一个从无到有的过程。但是目前的慢query分析还有很多可以优化的地方,比如优化建议的丰富、慢query的自动优化以及实时慢query的分析等,目前的慢query分析已经能起到一定的问题诊断和优化的作用了,未来还需要持续的挖掘和深入。如果你对数据分析和引擎优化方面有心得,欢迎与我交流,也欢迎有才的你加入搜索事业部。

image.png

目录
打赏
0
0
0
0
162
分享
相关文章
冗余数据JOIN导致的慢SQL优化一例
CASE 一个这样的查询,每个表都只有几千条数据,但是查询非常慢,几十秒不出结果。 select distinct abc.pro_col1, abc.col3 from t0 p INNER JOIN t1 abc on p.id=abc.par_col2
4859 0
MySQL数据库——SQL优化(3/3)-limit 优化、count 优化、update 优化、SQL优化 小结
MySQL数据库——SQL优化(3/3)-limit 优化、count 优化、update 优化、SQL优化 小结
332 0
利用SQL Profiler处理开销较大的查询
原文:利用SQL Profiler处理开销较大的查询   当SQL Server的性能变差时,最可能发生的是以下两件事: 首先,某些查询产生了系统资源上很大的压力。这些查询影响整个系统的性能,因为服务器无法足够快速地服务其他SQL查询。
1181 0
SQL为什么预估执行计划与真实执行计划会有差异?
SQL为什么预估执行计划与真实执行计划会有差异?http://www.bieryun.com/3149.html 一 问题概要 对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的 Runtime Plan 真实执行计划,偶尔会发现两边有不一致的情况,为什么呢?为什么预估执行计划会不准确?怎样才能避免这种情况的发生? 二 问题解答 这是执行计划相关中会被经常问道的问题,也是困扰自己很长时间的问题。
1503 0
从执行计划的预估行数看执行计划是否正确
  从执行计划的预估行数可以看出执行计划是否正确,作为优化的你曾经注意到了么?   今天在监控系统垃圾sql语句的时候发现一个sql语句跑了10个小时了,凭直觉这个sql肯定哪里出现问题了,好吧,...
815 0
PostgreSQL pageinspect 诊断与优化GIN (倒排) 索引合并延迟导致的查询性能下降问题
标签 PostgreSQL , brin索引 , gin索引 , 合并延迟 , gin_pending_list_limit , 查询性能下降 背景 GIN索引为PostgreSQL数据库多值类型的倒排索引,一条记录可能涉及到多个GIN索引中的KEY,所以如果写入时实时合并索引,会导致IO急剧增加,写入RT必然增加。
1926 0
不可置信!SQL 优化终于干掉了“distinct”
sql 优化之多表联合查询干掉 “distinct” 去重关键字 在我提交了代码的时候,架构师给我指出我这个sql这样写会有问题。因为在分库分表的时候,是不支持子查询的。 所以需要把多表的子查询的 sql 结构进行优化。 是不是挺恐怖的;(此处为了脱敏,我把相关的 sql 关键词都给打码掉了)