背景
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都对应一个独立的客户, 能反应更加精准意义的业务指标, 有业务价值的功能就是好功能.
