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

less than 1 minute read

背景

点查，基于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的对比和选择》](../201709/20170918_02.md)

GPDB的写入性能与选择

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