老板问你数据库在“瞎忙”还是“真忙”？怎么回答？
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第40期吐槽:PG 缺少qps计数器
1、产品的问题点
PG 缺少qps计数器
2、问题点背后涉及的技术原理
qps: 包括insert, update, select, delete.
通常需要支持 nestloop、top选择(由于function 有内置sql的存在).
3、这个问题将影响哪些行业以及业务场景
通用
4、会导致什么问题?
无法统计qps, 缺少展现业务吞吐的指标. 其他指标无法直接反映业务吞吐.
CPU负载、IOPS无法体现业务指标. 不能说负载高业务吞吐就高(有可能是SQL没有优化导致的瞎忙)
TPS可以, 但是只算commit、rollback两个维度, 并且不包括只读的事务, 体现维度较弱. (而且纯粹的查询无法通过tps反映)
索引扫描了多少条目、表扫描了多少行数、插入行数、删除行数、更新行数.
《PostgreSQL tuples_returned , tuples_fetched 说明》
blks_read | bigint | | |
blks_hit | bigint | | |
tup_returned | bigint | | |
tup_fetched | bigint | | |
tup_inserted | bigint | | |
tup_updated | bigint | | |
tup_deleted
5、业务上应该如何避免这个坑
通过 pg_stat_statements 的calls进行计算, 但是无法完美计算qps, 因为记录的sql容量有限(参数控制)
《PostgreSQL 实时健康监控 大屏 - 低频指标 - 珍藏级》
《PostgreSQL 实时健康监控 大屏 - 高频指标(服务器) - 珍藏级》
《PostgreSQL 实时健康监控 大屏 - 高频指标 - 珍藏级》
或者自己写个插件,改一下pg_stat_statement也能支持qps.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
qps监控指标的获取非常麻烦, 而且不准确, 而且可能重复统计, 例如function和sql. 同时区分 insert,update,delete,select 需要做文本匹配, 有性能损耗.
7、数据库未来产品迭代如何修复这个坑
建议内核层支持qps指标. 在pg_stat_database中支持insert,update,delete,select各项指标.
支持到database特别有意义, 因为很多saas类或者dbaas类业务每个database都对应一个独立的客户, 能反应更加精准意义的业务指标, 有业务价值的功能就是好功能.
本期彩蛋-招商中,有需要的小伙伴可联系嵌入...
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: