Greenplum 点查(按PK查询)性能与提升空间

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介:

标签

PostgreSQL , Greenplum , 点查 , 按PK查询


背景

点查,基于PK的查询或者OLTP类查询,实际上并不是GPDB 擅长的,GPDB擅长的是海量的OLAP。

不过在企业、政府等窗口服务类业务,并发实际上并不高,如果GPDB的点查性能达到一定的性能时,实际上也能满足这类场景的需求。

测试

下面是一组测试,造10亿条测试数据,按PK查询。

create table t_pk(id int primary key, info text, crt_time timestamp);  
  
postgres=# insert into t_pk select id, md5(random()::text), clock_timestamp() from generate_series(1,1000000000) t(id);  
INSERT 0 1000000000  

使用pgbench压测,GPDB点查性能如下,达到了接近1万TPS,实际上已经满足大多数的企业、政府等窗口服务类业务的查询需求。

transaction type: ./test.sql  
scaling factor: 1  
query mode: simple  
number of clients: 64  
number of threads: 64  
duration: 120 s  
number of transactions actually processed: 1076112  
latency average = 7.136 ms  
latency stddev = 16.734 ms  
tps = 8931.155844 (including connections establishing)  
tps = 8933.619173 (excluding connections establishing)  
script statistics:  
 - statement latencies in milliseconds:  
         0.002  \set id random(1,1000000000)  
         7.135  select * from t_pk where id=:id;  

同一台物理机,PostgreSQL的点查性能如下,超过了100万tps。

transaction type: ./test.sql  
scaling factor: 1  
query mode: prepared  
number of clients: 64  
number of threads: 64  
duration: 120 s  
number of transactions actually processed: 126137940  
latency average = 0.061 ms  
latency stddev = 0.032 ms  
tps = 1051029.358638 (including connections establishing)  
tps = 1051103.770277 (excluding connections establishing)  
script statistics:  
 - statement latencies in milliseconds:  
         0.001  \set id random(1,1000000000)  
         0.060  select * from t_pk where id=:id;  

当然,这里并不是要PK的意思,只是说GPDB还有很大的提升空间。

GPDB 5.x的版本,据说点查性能已经提升到5万+的tps了。

满足窗口类查询场景完全没有问题,GPDB可以作为一个OLTP+OLAP(偏OLAP)的数据库来使用,满足企业、政府等窗口服务类业务,海量数据的分析与实时查询的需求。

PG和GPDB如何选择?

《PostgreSQL 规格评估 - 微观、宏观、精准 多视角估算数据库性能(选型、做预算不求人)》

《数据库选型之 - 大象十八摸 - 致 架构师、开发者》

《数据库选型思考》

《空间|时间|对象 圈人 + 透视 - 暨PostgreSQL 10与Greenplum的对比和选择》

GPDB的写入性能与选择

《Greenplum insert的性能(单步\批量\copy) - 暨推荐使用gpfdist、阿里云oss外部表并行导入》

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
3月前
|
存储 Cloud Native 关系型数据库
PolarDB 并行查询问题之EXISTS子查询在并行查询中如何解决
PolarDB 并行查询问题之EXISTS子查询在并行查询中如何解决
30 1
|
SQL 弹性计算 关系型数据库
HTAP数据库 PostgreSQL 场景与性能测试之 3.1 - (OLAP) 大表JOIN统计查询-10亿 join 1亿 agg
标签 PostgreSQL , HTAP , OLTP , OLAP , 场景与性能测试 背景 PostgreSQL是一个历史悠久的数据库,历史可以追溯到1973年,最早由2014计算机图灵奖得主,关系数据库的鼻祖Michael_Stonebraker 操刀设计,PostgreSQL具备与Oracle类似的功能、性能、架构以及稳定性。 PostgreSQL社区的贡献者众多
2032 0
|
3月前
|
SQL 存储 关系型数据库
ADBPG&Greenplum成本优化问题之排查存在前缀字段相同的多个复合索引如何解决
ADBPG&Greenplum成本优化问题之排查存在前缀字段相同的多个复合索引如何解决
37 2
|
3月前
|
SQL 存储 关系型数据库
ADBPG&Greenplum成本优化问题之查询大表的dead tuple占比和空间如何解决
ADBPG&Greenplum成本优化问题之查询大表的dead tuple占比和空间如何解决
34 1
|
SQL 关系型数据库 MySQL
Mysql数据量统计:一条sql查询所有表的数据量、数据大小、索引大小
Mysql数据量统计:一条sql查询所有表的数据量、数据大小、索引大小
252 0
|
存储 Oracle 关系型数据库
[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率
[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率
178 0
[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率
|
关系型数据库 MySQL 索引
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(三)
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(三)
247 0
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(三)
|
关系型数据库 MySQL 索引
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(四)
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(四)
144 0
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(四)
|
关系型数据库 MySQL 索引
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(一)
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(一)
143 0
MYSQL性能调优05_覆盖索引、索引下推、如何选择合适的索引、Order by与Group by优化、索引设计原则(一)
下一篇
无影云桌面