PostgreSQL 用游标优化的一个例子

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介:
一位PG社区的朋友提到的一个应用场景,目前遇到性能问题。
数据结构大概是这样的,包含一个主键,一个数组,一个时间,其他字段。
请求分析:
有检索需求,比较频繁。查找数组中包含某些元素的记录,并按时间排序输出所有符合条件的记录,检索到的符合条件的记录可能上万条,也可能较少。
有插入需求,量不大。
有更新需求,一条记录最多一天会被更新一次,当然也可能不会被更新。
无删除需求。
数据量在千万级别。

这个应用场景的不安定因素来自于一些热点值。
例如,当输出的数据量较大时,排序对CPU的开销较大。而这些热点值可能也是查询的热点。
对于检索的条件是数组,这个可以用GIN索引来解决,只有排序是无法解决的。

测试,生成300万测试记录:
postgres=# create table test(id int primary key,info int[],crt_date date);
CREATE TABLE
postgres=# insert into test select generate_series(1,3000000), ('{'||round(random()*1000)||','||round(random()*1000)||','||round(random()*1000)||'}')::int[], current_date+round(random()*1000)::int;
INSERT 0 3000000
postgres=# create index idx_test_info on test using gin(info);
CREATE INDEX
当输出记录较少时,效率还是可以的,例如以下:
postgres=# explain (analyze,verbose,buffers,timing) select info,crt_date from test where info @> '{1,8}'::int[] order by crt_date desc;
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=101.23..101.29 rows=22 width=37) (actual time=1.668..1.672 rows=21 loops=1)
   Output: info, crt_date
   Sort Key: test.crt_date DESC
   Sort Method: quicksort  Memory: 26kB
   Buffers: shared hit=26
   ->  Bitmap Heap Scan on public.test  (cost=16.17..100.74 rows=22 width=37) (actual time=1.609..1.647 rows=21 loops=1)
         Output: info, crt_date
         Recheck Cond: (test.info @> '{1,8}'::integer[])
         Heap Blocks: exact=21
         Buffers: shared hit=26
         ->  Bitmap Index Scan on idx_test_info  (cost=0.00..16.17 rows=22 width=0) (actual time=1.595..1.595 rows=21 loops=1)
               Index Cond: (test.info @> '{1,8}'::integer[])
               Buffers: shared hit=5
 Planning time: 0.224 ms
 Execution time: 1.722 ms
(15 rows)
返回21行,算上排序需要1.7毫秒。
但是如果返回记录数上万之后,来看看结果:
postgres=# explain (analyze,verbose,buffers,timing) select info,crt_date from test where info @> '{1}'::int[] order by crt_date desc;
                                                            QUERY PLAN                                                             
-----------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=7737.83..7754.58 rows=6700 width=37) (actual time=17.726..18.856 rows=8896 loops=1)
   Output: info, crt_date
   Sort Key: test.crt_date DESC
   Sort Method: quicksort  Memory: 1080kB
   Buffers: shared hit=5028
   ->  Bitmap Heap Scan on public.test  (cost=59.93..7312.04 rows=6700 width=37) (actual time=3.722..13.585 rows=8896 loops=1)
         Output: info, crt_date
         Recheck Cond: (test.info @> '{1}'::integer[])
         Heap Blocks: exact=5025
         Buffers: shared hit=5028
         ->  Bitmap Index Scan on idx_test_info  (cost=0.00..58.25 rows=6700 width=0) (actual time=2.620..2.620 rows=8896 loops=1)
               Index Cond: (test.info @> '{1}'::integer[])
               Buffers: shared hit=3
 Planning time: 0.151 ms
 Execution time: 19.637 ms
(15 rows)
返回8896行,算上排序需要19.6毫秒。(这是返回所有记录的时间,如果是分页的话,第一页会很快返回)

优化建议。
1. 如果遇到排序带来的CPU负载过高的问题,可以创建热值partial index
对于热值,创建partial index。例如以上热值:
postgres=# create index idx_test_info_1 on test (crt_date) where info @> '{1}'::int[];
CREATE INDEX
禁止排序
postgres=# set enable_sort=off;
SET
postgres=# explain (analyze,verbose,buffers,timing) select * from test where info @> '{1}'::int[] order by crt_date desc;
                                                                   QUERY PLAN                                                       
             
------------------------------------------------------------------------------------------------------------------------------------
-------------
 Index Scan Backward using idx_test_info_1 on public.test  (cost=0.29..18253.53 rows=6700 width=41) (actual time=0.013..9.147 rows=8
896 loops=1)
   Output: id, info, crt_date
   Buffers: shared hit=8909
 Planning time: 0.253 ms
 Execution time: 9.911 ms
(5 rows)
当然这么做有很大的弊端,因为如果热值比较多,我们要为各种热值相关的查询条件创建很多的索引。

2. 因为一条记录一天最多更新一次,所以完全可以使用应用层缓存,或者pgmemcache这样的缓存插件,降低数据库的负担。

3. 使用游标,我们注意到用户使用了分页显示,但是对于用户来说,可能只会看第一页或前几页的内容,所以每次都全部取到程序端是没有必要的,用游标会更好。(注意不要使用order by limit x offset x这种方式分页,会冗余扫描多次,请使用cursor,但是记得用完关闭。)详见驱动API,如pg-jdbc。

压力测试:
测量类似分页,我这里只取第一页的内容(使用热值partial index)。
注意这种用法不是游标的用法。只是方便这里测试的。
vi test.sql
select * from test where info @> '{1}'::int[] order by crt_date desc limit 10;
性能非常可观:
pg95@db-172-16-3-150-> pgbench -M prepared -n -r -f ./test.sql -P 1 -c 16 -j 16 -T 30
progress: 1.0 s, 72844.1 tps, lat 0.213 ms stddev 0.119
progress: 2.0 s, 73691.9 tps, lat 0.215 ms stddev 0.019
progress: 3.0 s, 73603.7 tps, lat 0.216 ms stddev 0.018
progress: 4.0 s, 73501.3 tps, lat 0.216 ms stddev 0.063
progress: 5.0 s, 73433.2 tps, lat 0.216 ms stddev 0.049
progress: 6.0 s, 73645.1 tps, lat 0.216 ms stddev 0.023
progress: 7.0 s, 73551.0 tps, lat 0.216 ms stddev 0.060
progress: 8.0 s, 73640.9 tps, lat 0.216 ms stddev 0.018
progress: 9.0 s, 73650.8 tps, lat 0.216 ms stddev 0.027
progress: 10.0 s, 73753.5 tps, lat 0.215 ms stddev 0.068
对比一次取完所有数据的性能:
pg95@db-172-16-3-150-> vi test.sql
select * from test where info @> '{1}'::int[] order by crt_date desc;

pg95@db-172-16-3-150-> pgbench -M prepared -n -r -f ./test.sql -P 1 -c 16 -j 16 -T 30
progress: 1.0 s, 219.9 tps, lat 68.165 ms stddev 7.355
progress: 2.0 s, 233.8 tps, lat 67.849 ms stddev 15.181
progress: 3.0 s, 238.4 tps, lat 68.023 ms stddev 10.556
progress: 4.0 s, 233.9 tps, lat 68.030 ms stddev 4.459
progress: 5.0 s, 233.6 tps, lat 68.019 ms stddev 4.131
progress: 6.0 s, 235.5 tps, lat 67.472 ms stddev 3.204
progress: 7.0 s, 237.7 tps, lat 67.627 ms stddev 3.257
progress: 8.0 s, 233.5 tps, lat 67.779 ms stddev 4.815
progress: 9.0 s, 238.7 tps, lat 67.723 ms stddev 7.603
progress: 10.0 s, 232.0 tps, lat 68.098 ms stddev 13.948

[参考]
1. http://www.postgresql.org/docs/9.4/static/functions-array.html
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
8月前
|
SQL 关系型数据库 测试技术
沉浸式学习PostgreSQL|PolarDB 20: 学习成为数据库大师级别的优化技能
在上一个实验《沉浸式学习PostgreSQL|PolarDB 19: 体验最流行的开源企业ERP软件 odoo》 中, 学习了如何部署odoo和polardb|pg. 由于ODOO是非常复杂的ERP软件, 对于关系数据库的挑战也非常大, 所以通过odoo业务可以更快速提升同学的数据库优化能力, 发现业务对数据库的使用问题(如索引、事务对锁的运用逻辑问题), 数据库的代码缺陷, 参数或环境配置问题, 系统瓶颈等.
868 1
|
14天前
|
关系型数据库 分布式数据库 数据库
【PolarDB开源】PolarDB资源隔离技术:在多租户环境中的应用与优化
【5月更文挑战第29天】PolarDB,阿里云的云原生数据库,在多租户环境中通过逻辑(Schema/Partition隔离)和物理(分布式存储计算节点)隔离保障数据安全和资源独占。它支持动态资源分配,适应不同租户需求,处理大规模并发,提供租户管理及数据访问控制功能。通过优化资源分配算法、提升事务处理能力和强化监控告警,PolarDB确保性能和稳定性,满足多租户的高效数据库服务需求。
52 1
|
6天前
|
SQL 存储 关系型数据库
PolarDB产品使用合集之有的sql里面有自定义存储函数 如果想走列存有什么优化建议吗
PolarDB是阿里云推出的一种云原生数据库服务,专为云设计,提供兼容MySQL、PostgreSQL的高性能、低成本、弹性可扩展的数据库解决方案,可以有效地管理和优化PolarDB实例,确保数据库服务的稳定、高效运行。以下是使用PolarDB产品的一些建议和最佳实践合集。
|
15天前
|
存储 监控 关系型数据库
关系型数据库数据库设计优化
【5月更文挑战第18天】关系型数据库数据库设计优化
31 1
|
15天前
|
SQL 缓存 监控
关系型数据库优化查询语句
【5月更文挑战第18天】
25 2
|
15天前
|
关系型数据库 MySQL 数据库
关系型数据库索引设计优化
【5月更文挑战第18天】
24 1
|
16天前
|
SQL 关系型数据库 分布式数据库
【PolarDB开源】PolarDB Proxy配置与优化:提升数据库访问效率
【5月更文挑战第27天】PolarDB Proxy是阿里云PolarDB的高性能数据库代理,负责SQL请求转发和负载均衡。其关键配置包括:连接池管理(如最大连接数、空闲超时时间),负载均衡策略(轮询、权重轮询、一致性哈希),以及SQL过滤规则。优化方面,关注监控与调优、缓存策略、网络优化。通过这些措施,可提升数据库访问效率和系统稳定性。
123 1
|
17天前
|
负载均衡 关系型数据库 分布式数据库
【PolarDB开源】PolarDB读写分离实践:优化读取性能与负载均衡策略
【5月更文挑战第26天】PolarDB是云原生关系型数据库,通过读写分离优化性能和扩展性。它设置主节点处理写操作,从节点处理读操作,异步复制保证数据一致性。优化读取性能的策略包括增加从节点数量、使用只读实例和智能分配读请求。负载均衡策略涉及基于权重、连接数和地理位置的分配。实践示例中,电商网站通过主从架构、只读实例和负载均衡策略提升商品查询效率。PolarDB的读写分离与负载均衡为企业应对大数据和高并发提供了有效解决方案。
133 0
|
18天前
|
存储 关系型数据库 分布式数据库
【PolarDB 开源】PolarDB 存储引擎优化:PolarStore 的深度解析与优化
【5月更文挑战第25天】PolarDB的PolarStore存储引擎以其高效索引和优化的压缩算法提升数据存储与访问性能。通过并发控制保证事务正确性,同时支持数据压缩和索引优化。在实际应用中,优化包括调整索引结构、数据分区、事务管理及定期数据库维护。结合业务需求进行深度优化,可最大化PolarStore的性能潜力,推动数据库系统发展。
106 0
|
19天前
|
SQL 监控 关系型数据库
【PolarDB开源】PolarDB SQL优化实践:提升查询效率与资源利用
【5月更文挑战第24天】PolarDB是高性能的云原生数据库,强调SQL查询优化以提升性能。本文分享了其SQL优化策略,包括查询分析、索引优化、查询重写、批量操作和并行查询,以及性能监控与调优方法。通过这些措施,可以减少响应时间、提高并发处理能力和降低成本。文中还提供了相关示例代码,展示如何分析查询和创建索引,帮助用户实现更高效的数据库管理。
45 1

相关产品

  • 云原生数据库 PolarDB