【DB吐槽大会】第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都对应一个独立的客户, 能反应更加精准意义的业务指标, 有业务价值的功能就是好功能.