性能优化利器——预计算(含报表场景实践)

写在前面

很多人觉得工作像是无尽的CRUD,实际上工作场景中包含很多值得思考的可以性能优化的点。针对数据而言,比较常见的性能优化方式有两种,一种是 cache, 一种是预计算。本篇文章会介绍后者。

什么是预计算?

预计算和cache一样,都是在用空间换时间,顾名思义,将计算提前到更早的阶段(比如数据导入阶段),可以减少查询时的耗时与成本。

预计算在报表场景的实践

背景

报表是一个常见的业务场景,为了展示不同纬度的业务数据,我们需要在一个页面中展示不同维度不同展现形式的的报表。从技术角度,前端页面会同时发送多个请求至服务器,并接受服务器返回的结果。

以工单系统为例,我们可能需要查看一定时间内工单相关的数据(比如成功率、发起工单数),以及一定时间内用户相关的数据(比如每日使用次数、新增用户/留存率),假如这些数据存在一张表中,那我们可能会根据请求数据的不同编写不同的sql。

举个例子

然而同一时间的多个sql必然会带来耗时的增加,既然数据存在于一张表中,那是否可以只查询一次拿取所有需要的数据呢?

如图,通过一次性查询结果并根据请求的需要进行初步的计算再返回给浏览器,这样的好处是减少了因SQL查询而导致的网络传输的次数(网络传输向来是查询数据场景中耗时的大头)

不足之处

这里面有一个漏洞,就是多个请求其实是同时发送,那么让多个请求等待一次网络请求的结果本身也是一个耗时点,在第一个请求抢锁并查询数据的时间里,其他的请求其实都是阻塞等待的,而其他的请求不断的轮询本身也会造成CPU资源的挤占,需要根据场景设计等待时间

究其本质

前面说了,预计算和cache一样,都是在用空间换时间

如果我们在数据导入阶段就计算出不同的用户数据,那么虽然多个sql会增加网络传输耗时,但无论是DB还是Server的计算消耗却都没有了

写在最后

两种思路我觉得都有可取之处,有趣的是,究竞哪个思路查询更快并不是一个静止的答案,而是需要综合考虑自己的报表个数,查询数据量级等多个条件。

相关推荐
金銀銅鐵4 小时前
[Java] 用 GUI 展示 EnumSet 增减元素时的内部变化(上)
java·后端·ai编程
念何架构之路5 小时前
go-grpc设计思想
开发语言·后端·golang
system_error_x5 小时前
SpringBoot 集成 Thymeleaf 简洁入门
java·spring boot·后端
步行cgn7 小时前
Spring MVC 视图机制的核心接口与类
java·开发语言·后端·spring·mvc
码事漫谈8 小时前
AI 读你的提示词,其实很没耐心
后端
用户8356290780518 小时前
如何使用 Python 格式化 Excel 单元格中的长文本
后端·python
我命由我123458 小时前
Python 开发 - Python 的 pathlib
java·开发语言·后端·python·学习·java-ee·学习方法
IT_陈寒8 小时前
Java性能优化完全指南
前端·人工智能·后端
电子IT笔记9 小时前
对接群晖NAS,上传和删除踩坑记录
前端·后端
Mk598789 小时前
P4:把 Agent 的记忆搬进 Redis —— AgentScope-Java 工程化实战
后端