Greenplum 点查(按PK查询)性能与提升空间
2017-12-15 15:06
162 查看
原文链接:点击打开链接
摘要: 标签 PostgreSQL , Greenplum , 点查 , 按PK查询 背景 点查,基于PK的查询或者OLTP类查询,实际上并不是GPDB 擅长的,GPDB擅长的是海量的OLAP。 不过在企业、政府等窗口服务类业务,并发实际上并不高,如果GPDB的点查性能达到一定的性能时,实际上也能满足这类场景的需求。
PostgreSQL , Greenplum , 点查 , 按PK查询
点查,基于PK的查询或者OLTP类查询,实际上并不是GPDB 擅长的,GPDB擅长的是海量的OLAP。
不过在企业、政府等窗口服务类业务,并发实际上并不高,如果GPDB的点查性能达到一定的性能时,实际上也能满足这类场景的需求。
下面是一组测试,造10亿条测试数据,按PK查询。
使用pgbench压测,GPDB点查性能如下,达到了接近1万TPS,实际上已经满足大多数的企业、政府等窗口服务类业务的查询需求。
同一台物理机,PostgreSQL的点查性能如下,超过了100万tps。
当然,这里并不是要PK的意思,只是说GPDB还有很大的提升空间。
GPDB 5.x的版本,据说点查性能已经提升到5万+的tps了。
满足窗口类查询场景完全没有问题,GPDB可以作为一个OLTP+OLAP(偏OLAP)的数据库来使用,满足企业、政府等窗口服务类业务,海量数据的分析与实时查询的需求。
PG和GPDB如何选择?
《PostgreSQL 规格评估 - 微观、宏观、精准 多视角估算数据库性能(选型、做预算不求人)》
《数据库选型之 - 大象十八摸 - 致 架构师、开发者》
《数据库选型思考》
《空间|时间|对象 圈人 + 透视 - 暨PostgreSQL 10与Greenplum的对比和选择》
GPDB的写入性能与选择
《Greenplum insert的性能(单步\批量\copy) - 暨推荐使用gpfdist、阿里云oss外部表并行导入》
摘要: 标签 PostgreSQL , Greenplum , 点查 , 按PK查询 背景 点查,基于PK的查询或者OLTP类查询,实际上并不是GPDB 擅长的,GPDB擅长的是海量的OLAP。 不过在企业、政府等窗口服务类业务,并发实际上并不高,如果GPDB的点查性能达到一定的性能时,实际上也能满足这类场景的需求。
标签
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外部表并行导入》
相关文章推荐
- 深度优化sql 查询, 提升性能一百倍是什么概念?
- 提升数据库查询的性能
- 提升数据库查询的性能
- 使用ViewFields提升SPQuery查询性能
- 在合适的场合使用 with (nolock) 提升查询性能
- 强制SQL Server执行计划使用并行提升在复杂查询语句下的性能
- MS SQL 技巧系列(二)SQL查询的性能大PK之:or vs. union
- 如何提升sqlite中blob数据的查询性能
- 如何使用 Hadoop 提升 Hive 查询性能
- Oracle 索引 bitmap 类型对 LIKE查询性能提升
- Hibernate如何提升数据库查询的性能+SpringAOP分析
- 预分配mysql binlog文件存储空间有可能较大幅度提升性能
- 实体框架 5.0:空间数据类型、性能增强、数据库提升
- 强制SQL Server执行计划使用并行提升在复杂查询语句下的性能
- 强制SQL Server执行计划使用并行提升在复杂查询语句下的性能
- 用户空间网络提升 NFV 的性能
- Mysql分页查询获取totalCount大幅提升性能的办法总结
- Hibernate如何提升数据库查询的性能
- 0101-ArcPy:使用内存作为工作空间,提升地理处理工具性能
- Hibernate怎么提升数据库查询的性能 (1)