每天5分钟PG聊通透第17期,为什么有些逻辑建议放在存储过程里?
P
digoal约 4 分钟
digoal约 4 分钟参考文档点击文末 阅读原文 打开; 推荐 《最好的PostgreSQL学习镜像 》 ;
每天5分钟PG聊通透第17期,为什么有些逻辑建议放在存储过程里?
背景
-
问题说明(现象、环境) -
分析原因 -
结论和解决办法
链接、驱动、SQL
17、为什么说有些逻辑应该交给数据库存储过程来做?
https://www.bilibili.com/video/BV1pL4y1E7t8/
1、一般的业务处理流程如下:
sql1 -- 数据库处理很快(0.0x ms), 但是网络延迟相对很高(2ms)
业务处理逻辑, 计算量不大
sql2 -- 数据库处理很快(0.0x ms), 但是网络延迟相对很高(2ms)
业务处理逻辑, 计算量不大
...
业务处理的计算量不大, 可以交给数据库进行计算.
以上情况, 可以考虑将业务逻辑封装到数据库存储过程或函数中执行, 减少业务与数据库的交互次数, 降低整个过程的网络RT开销.
2、当业务操作有原子性诉求时, 除了使用事务, 将逻辑封装到函数或存储过程中也是可行的.例如T+1的数据分析, 有比较多的计算过程, 逐条记录的处理过程等, 封装在函数或存储过程中可以保证原子性, 同时支持非常丰富的pl语法: 例如游标、LOOP、exception处理等.
以上两个例子都考虑了避免长事务不要与同时产生大量垃圾的其他事务在同一个时间段执行. 否则会导致垃圾无法回收, 增加扫描消耗和膨胀的可能性.
-
第一个例子是小事务, 因为计算量很小, 很快. -
第二个例子通常是半夜处理T+1的分析, 业务低谷, 不会有大量产生垃圾的业务同时存在.
《每天5分钟,PG聊通透 - 系列1 - 热门问题 - 链接、驱动、SQL - 第16期 - 为什么说有些排序操作建议让业务来做?》
《每天5分钟,PG聊通透 - 系列1 - 热门问题 - 链接、驱动、SQL - 第13期 - 为什么长时间等待业务处理的情况不建议封装在一个长事务中进行处理?》
本期彩蛋 - 数据库生态工具&信创开源数据库
用好周边工具, 数据库管理水平战胜90%老司机
1、管控软件 云猿生开源的 kubeblocks , 如果你要管理很多套并且种类很多的数据库产品, 推荐选择.-
https://github.com/apecloud/kubeblocks
-
https://www.csudata.com/
-
https://pigsty.cc/zh/
2、审计监控诊断优化
海信聚好看的 DBdoctor , 采用ebpf技术, 在对数据库几乎没有影响的情况下实时监控数据库和服务器的各项指标, 发现和诊断问题根因非常方便.-
https://www.dbdoctor.cn/
-
https://bytebase.cc/docs/introduction/what-is-bytebase/
-
https://www.modb.pro/db/567140
3、数据同步&迁移&备份恢复
NineData , 老领导出去创业做的产品, 产品涵盖了数据同步、迁移、备份、比对、devops、chatDBA等.-
https://www.ninedata.cloud/home
-
https://www.dsgdata.com/
通过信创并且开源的数据库:
PolarDB for PostgreSQL-
https://github.com/ApsaraDB/PolarDB-for-PostgreSQL
感谢关注我的github (https://github.com/digoal/blog) 及视频号:彩蛋2 : 全国大学生数据库创新设计赛 点击报名