HTAP数据库 PostgreSQL 场景与性能测试之 3.1 - (OLAP) 大表JOIN统计查询-10亿 join 1亿 agg

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 标签 PostgreSQL , HTAP , OLTP , OLAP , 场景与性能测试 背景 PostgreSQL是一个历史悠久的数据库,历史可以追溯到1973年,最早由2014计算机图灵奖得主,关系数据库的鼻祖Michael_Stonebraker 操刀设计,PostgreSQL具备与Oracle类似的功能、性能、架构以及稳定性。 PostgreSQL社区的贡献者众多

标签

PostgreSQL , HTAP , OLTP , OLAP , 场景与性能测试


背景

PostgreSQL是一个历史悠久的数据库,历史可以追溯到1973年,最早由2014计算机图灵奖得主,关系数据库的鼻祖Michael_Stonebraker 操刀设计,PostgreSQL具备与Oracle类似的功能、性能、架构以及稳定性。

pic

PostgreSQL社区的贡献者众多,来自全球各个行业,历经数年,PostgreSQL 每年发布一个大版本,以持久的生命力和稳定性著称。

2017年10月,PostgreSQL 推出10 版本,携带诸多惊天特性,目标是胜任OLAP和OLTP的HTAP混合场景的需求:

《最受开发者欢迎的HTAP数据库PostgreSQL 10特性》

1、多核并行增强

2、fdw 聚合下推

3、逻辑订阅

4、分区

5、金融级多副本

6、json、jsonb全文检索

7、还有插件化形式存在的特性,如 向量计算、JIT、SQL图计算、SQL流计算、分布式并行计算、时序处理、基因测序、化学分析、图像分析 等。

pic

在各种应用场景中都可以看到PostgreSQL的应用:

pic

PostgreSQL近年来的发展非常迅猛,从知名数据库评测网站dbranking的数据库评分趋势,可以看到PostgreSQL向上发展的趋势:

pic

从每年PostgreSQL中国召开的社区会议,也能看到同样的趋势,参与的公司越来越多,分享的公司越来越多,分享的主题越来越丰富,横跨了 传统企业、互联网、医疗、金融、国企、物流、电商、社交、车联网、共享XX、云、游戏、公共交通、航空、铁路、军工、培训、咨询服务等 行业。

接下来的一系列文章,将给大家介绍PostgreSQL的各种应用场景以及对应的性能指标。

环境

环境部署方法参考:

《PostgreSQL 10 + PostGIS + Sharding(pg_pathman) + MySQL(fdw外部表) on ECS 部署指南(适合新用户)》

阿里云 ECS:56核,224G,1.5TB*2 SSD云盘

操作系统:CentOS 7.4 x64

数据库版本:PostgreSQL 12

PS:ECS的CPU和IO性能相比物理机会打一定的折扣,可以按下降1倍性能来估算。跑物理主机可以按这里测试的性能乘以2来估算。

场景 - 大表JOIN统计查询 (OLAP)

1、背景

多张大表的JOIN,聚合分析。例如有一张用户表,一张业务日志表表示活跃用户的行为数据,按天分区。

用户表1亿条记录,每天1000万活跃用户,产生10亿行为数据。

根据用户行为join用户表,group 用户表的某些字段,生成用户画像。

2、设计

2张表,1张1亿,uid为主键。1张10亿,订单号为主键,uid关联第一张表。

3、准备测试表

create unlogged table t_user (uid int8, info text, c1 int, c2 int, c3 int, crt_time timestamp);  
  
create unlogged table t_user_log_20191212(id int8, uid int8, info text, crt_time timestamp);  

4、准备测试函数(可选)

5、准备测试数据

insert into t_user select generate_series(1,100000000), md5(random()::text), random()*10, random()*100, random()*1000, now();  
  
insert into t_user_log_20191212 select generate_series(1,1000000000), random()*10000000, md5(random()::text), now();  

空间占用分别为8.8GB, 87GB:

postgres=# \dt+ t_user  
                     List of relations  
 Schema |  Name  | Type  |  Owner   |  Size   | Description   
--------+--------+-------+----------+---------+-------------  
 public | t_user | table | postgres | 8880 MB |   
(1 row)  
  
postgres=# \dt+ t_user_log_20191212   
                           List of relations  
 Schema |        Name         | Type  |  Owner   | Size  | Description   
--------+---------------------+-------+----------+-------+-------------  
 public | t_user_log_20191212 | table | postgres | 87 GB |   
(1 row)  

6、准备测试脚本

7、测试

alter table t_user set (parallel_workers =64);  
alter table t_user_log_20191212 set (parallel_workers =64);  
  
set max_parallel_workers=128;  
set max_parallel_workers_per_gather =32;  
set min_parallel_table_scan_size =0;  
set min_parallel_index_scan_size =0;  
set parallel_setup_cost =0;  
set parallel_tuple_cost =0;  
set jit=on;
  
set parallel_leader_participation =off;  
set enable_sort =off;  
set work_mem='64MB';  
  
explain (analyze,verbose,timing,costs,buffers) select c1,count(*) from t_user join t_user_log_20191212 using (uid) group by c1;  
  
select t1.c1,count(*) from t_user t1 join t_user_log_20191212 t2 using (uid) group by c1;  

8、测试结果

postgres=#       explain  select c1,count(*) from t_user join t_user_log_20191212 using (uid) group by c1;
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Finalize HashAggregate  (cost=13518803.57..13518803.68 rows=11 width=12)
   Group Key: t_user.c1
   ->  Gather  (cost=13518801.70..13518801.81 rows=352 width=12)
         Workers Planned: 32
         ->  Partial HashAggregate  (cost=13518801.70..13518801.81 rows=11 width=12)
               Group Key: t_user.c1
               ->  Parallel Hash Join  (cost=1221935.52..13362551.69 rows=31250002 width=4)
                     Hash Cond: (t_user_log_20191212.uid = t_user.uid)
                     ->  Parallel Seq Scan on t_user_log_20191212  (cost=0.00..11676137.02 rows=31250002 width=8)
                     ->  Parallel Hash  (cost=1167614.01..1167614.01 rows=3125001 width=12)
                           ->  Parallel Seq Scan on t_user  (cost=0.00..1167614.01 rows=3125001 width=12)
 JIT:
   Functions: 20
   Options: Inlining true, Optimization true, Expressions true, Deforming true
(14 rows)

postgres=# select c1,count(*) from t_user join t_user_log_20191212 using (uid) group by c1;
 c1 |   count   
----+-----------
  8 | 100163144
  7 |  99799644
 10 |  50012738
  9 | 100095291
  1 |  99945550
  5 |  99818748
  4 |  99862794
  2 | 100080723
  0 |  50167364
  6 |  99907094
  3 | 100146857
(11 rows)

Time: 46214.349 ms (00:46.214)

TPS: xx

响应时间: 46 秒

不开并行和jit的话,耗时735秒,相差16倍。

参考

《PostgreSQL、Greenplum 应用案例宝典《如来神掌》 - 目录》

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

《PostgreSQL 使用 pgbench 测试 sysbench 相关case》

《数据库界的华山论剑 tpc.org》

https://www.postgresql.org/docs/10/static/pgbench.html

 

免费领取阿里云RDS PostgreSQL实例、ECS虚拟机

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
6月前
|
数据采集 算法 测试技术
【硬件测试】基于FPGA的1024QAM基带通信系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文介绍了基于FPGA的1024QAM基带通信系统的硬件测试版本,包含testbench、高斯信道模块和误码率统计模块。系统新增ila在线数据采集和vio在线SNR设置模块,支持不同SNR条件下的性能测试。1024QAM调制将10比特映射到复平面上的1024个星座点之一,实现高效数据传输。硬件测试结果表明,在SNR=32dB和40dB时,系统表现出良好的性能。Verilog核心程序展示了各模块的连接与功能实现。
145 7
|
2月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的4ASK+帧同步系统开发与硬件片内测试,包含高斯信道,误码统计,可设置SNR
本文为基于FPGA的4-ASK调制与帧同步系统硬件测试版,采用Verilog实现,包含ILA在线采集与VIO SNR设置模块,支持高斯信道误码统计,适用于通信系统教学与实践。
45 2
|
3月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的2FSK+帧同步系统开发与硬件片内测试,包含高斯信道,误码统计,可设置SNR
本文基于FPGA实现2FSK+帧同步系统,采用Verilog开发,包含Testbench、高斯信道、误码统计及可设置SNR功能。硬件版本新增ILA在线数据采集与VIO在线SNR设置模块,验证调制解调过程。理论部分介绍FSK调制解调原理、功率谱特性及帧同步机制,代码实现FSK信号生成与处理,适合数字通信学习与实践。
124 1
|
4月前
|
存储 算法 Java
实现不同数据库的表间的 JOIN 运算的极简方法
跨库计算是数据分析中的常见难题,尤其涉及多数据库系统时,表间 JOIN 操作复杂度显著提升。esProc 提供了一种高效解决方案,能够简化跨库 JOIN 的实现。例如,在车辆管理、交管和公民信息系统中,通过 esProc 可轻松完成如下任务:按城市统计有车公民事件数量、找出近一年获表彰的车主信息,以及按年份和品牌统计车辆违章次数。esProc 支持不同关联场景(如维表关联与主子表关联)的优化算法,如内存索引、游标处理和有序归并,从而大幅提升编码和运算效率。无论是同构还是异构数据源,esProc 均能灵活应对,为复杂数据分析提供强大支持。
|
5月前
|
监控 数据库
【YashanDB 知识库】ycm 托管数据库时报错 OM host ip:127.0.0.1 is not support join to YCM
在托管数据库时,若 OM 的 IP 被设置为 127.0.0.1,将导致无法托管至 YCM,并使数据库失去监控。此问题源于安装时修改了 OM 的监听 IP。解决方法包括:将 OM 的 IP 修改为本机实际 IP 或 0.0.0.0,同时更新 env 文件及 yasom 后台数据库中的相关配置。经验总结指出,应避免非必要的后台 IP 修改,且数据库安装需遵循规范,不使用仅限本机访问的 IP(如 127.0.0.1)。
|
5月前
|
数据采集 移动开发 算法
【硬件测试】基于FPGA的QPSK调制+软解调系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文基于FPGA实现QPSK调制与软解调系统,包含Testbench、高斯信道、误码率统计模块,并支持不同SNR设置。硬件版本新增ILA在线数据采集和VIO在线SNR设置功能,提供无水印完整代码及测试结果。通过VIO分别设置SNR为6dB和12dB,验证系统性能。配套操作视频便于用户快速上手。 理论部分详细解析QPSK调制原理及其软解调实现过程,涵盖信号采样、相位估计、判决与解调等关键步骤。软解调通过概率估计(如最大似然法)提高抗噪能力,核心公式为*d = d_hat / P(d_hat|r[n])*,需考虑噪声对信号点分布的影响。 附Verilog核心程序代码及注释,助力理解与开发。
156 5
|
5月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的2ASK+帧同步系统开发与硬件片内测试,包含高斯信道,误码统计,可设置SNR
本文分享了基于FPGA的2ASK+帧同步系统硬件测试版本,包含ILA数据采集、VIO SNR设置及数据源模块。通过调整SNR(如45dB和10dB),实现对调制解调性能的验证。2ASK调制将数字信号转为二进制码,通过载波振幅变化传输;帧同步用于确定帧起始位置,确保数据正确解调。附带操作视频与核心Verilog代码,便于理解和复现。
155 9
|
6月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的MSK调制解调系统系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文基于FPGA实现MSK调制解调系统,采用Verilog开发,包含同步模块、高斯信道模拟、误码率统计等功能。相比仿真版本,新增ILA数据采集与VIO在线SNR设置模块。通过硬件测试验证,展示不同SNR(如10dB和16dB)下的性能表现。研究聚焦软件无线电领域,优化算法复杂度以适应硬件限制,利用MSK恒定包络、相位连续等特性提升频谱效率。核心代码实现信号生成、调制解调、滤波及误码统计,提供完整的硬件设计与分析方案。
204 19
|
6月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的4ASK调制解调通信系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文介绍了基于FPGA的4ASK调制解调系统的硬件测试版本,该系统包括testbench、高斯信道模块和误码率统计模块,并新增了ILA在线数据采集和VIO在线SNR设置功能。通过VIO设置不同SNR(如15dB和25dB),实现了对系统性能的实时监测与调整。4ASK是一种通过改变载波幅度表示数据的数字调制方式,适用于多种通信场景。FPGA平台的高效性和灵活性使其成为构建高性能通信系统的理想选择。
155 17
|
6月前
|
监控 数据库
【YashanDB知识库】ycm托管数据库时报错OM host ip:127.0.0.1 is not support join to YCM
在托管数据库时,若OM的IP被设置为127.0.0.1,则不支持托管到YCM,导致数据库无法正常监控。此问题源于安装时修改了OM监听IP为127.0.0.1。解决方法为将OM的IP修改为本机实际IP或0.0.0.0,并更新yasom后台数据库中的相关配置。建议遵循规范安装,避免使用仅限本机访问的IP(如127.0.0.1),以减少潜在风险。

热门文章

最新文章

推荐镜像

更多