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

标签

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外部表并行导入》

时间: 2024-09-22 07:03:53

Greenplum 点查(按PK查询)性能与提升空间的相关文章

Greenplum 2000亿 近似度查询 性能 以及注意事项

greenplum和PostgreSQL一样,都是通过pg_trgm来支持近似度查询的. 原理是将字符串前加2空格,末尾加1空格,然后按照3个连续的字符串为一组,打散成多个字符串.然后计算字符串的重复度来计算两个字符串的相似度. 计算重复度时,需要进行去重复的操作. 例如: postgres=# select similarity('abcde','abcabc'); similarity ------------ 0.333333 (1 row) Time: 0.413 ms 以上两个字符串被

SQL Server查询性能优化之创建合理的索引(下)

续上一篇SQLServer查询性能优化之创建合理的索引(上) 数据库索引分为聚集索引和非聚集索引,聚集索引就是物理索引,也就是数据的物理的存储顺序,聚集索引的叶子节点就是数据行本身:非聚集索引是逻辑索引,也可以简单的认为是对聚集索引建立的索引,一般来说聚集索引的键就是非聚集索引的叶子节点(在不使用include时). 关于索引的选择 对于索引类型来说没什么好选的,一般来说聚集索引是必须的(有特殊需要的另说),非聚集索引看实际需要灵活建立.因此对于索引来说主要是决定在那些列上建立索引,尤其是对于聚

Sql Server查询性能优化之不可小觑的书签查找介绍_MsSql

小小程序猿SQL Server认知的成长 1.没毕业或工作没多久,只知道有数据库.SQL这么个东东,浑然分不清SQL和Sql Server Oracle.MySql的关系,通常认为SQL就是SQL Server 2.工作好几年了,也写过不少SQL,却浑然不知道索引为何物,只知道数据库有索引这么个东西,分不清聚集索引和非聚集索引,只知道查询慢了建个索引查询就快了,到头来索引也建了不少,查询也确实快了,偶然问之:汝建之索引为何类型?答曰:... 3.终于受到刺激开始奋发图强,买书,gg查资料终于知道

Solr全文搜索与MySQL查询性能比较

测试数据量:10407608Num Docs: 10407608 在项目中一个最常用的查询,查询某段时间内的数据,SQL查询获取数据,30s左右 SELECT * FROM `tf_hotspotdata_copy_test` WHERE collectTime BETWEEN '2014-12-06 00:00:00' AND '2014-12-10 21:31:55'; 对collectTime建立索引后,同样的查询,2s,快了很多. Solr索引 Solr查询,同样的条件,72ms "st

MongoDB查询性能优化验证及验证_MongoDB

结论: 1. 200w数据,合理使用索引的情况下,单个stationId下4w数据.mongodb查询和排序的性能理想,无正则时client可以在600ms+完成查询,qps300+.有正则时client可以在1300ms+完成查询,qps140+. 2. Mongodb的count性能比较差,非并发情况下client可以在330ms完成查询,在并发情况下则需要1-3s.可以考虑估算总数的方法,http://blog.sina.com.cn/s/blog_56545fd30101442b.htm

SQL Server-聚焦移除Bookmark Lookup、RID Lookup、Key Lookup提高SQL查询性能(六)

前言 前面几节都是讲的基础内容,本节我们讲讲索引性能优化,当对大数据进行处理时首先想到的就是索引,一旦遇到这样的问题则手忙脚乱,各种查资料,为何平常不扎实基本功呢,我们由浅入深,简短的内容,深入的理解,而非一上来就把问题给框死,立马给出解决方案,抛出问题,再到解决问题,你GET了没有.Always to review the basics. Bookmark Lookup.RID Lookup.Key Lookup定义 一说到这三者,如果对索引研究不深的童鞋估计是懵逼的,什么玩意,我们姑且将上面

Elasticsearch增删改查 之 —— Get查询

GET API是Elasticsearch中常用的操作,一般用于验证文档是否存在:或者执行CURD中的文档查询.与检索不同的是,GET查询是实时查询,可以实时查询到索引结果.而检索则是需要经过处理,一般默认是1秒钟吧...才能搜索到.合理利用这些方法,可以更灵活的使用Elasticsearch. 更多内容参考ELK教程 阅读这篇文档,发现自己对很多地方不是很理解.比如存储机制.版本维护等等.暂时先做为阶段性的学习吧...后续更新在回来补补.... 查询样例 Get API允许基于ID字段从Ela

Sql Server查询性能优化之不可小觑的书签查找介绍

小小程序猿SQL Server认知的成长 1.没毕业或工作没多久,只知道有数据库.SQL这么个东东,浑然分不清SQL和Sql Server Oracle.MySql的关系,通常认为SQL就是SQL Server 2.工作好几年了,也写过不少SQL,却浑然不知道索引为何物,只知道数据库有索引这么个东西,分不清聚集索引和非聚集索引,只知道查询慢了建个索引查询就快了,到头来索引也建了不少,查询也确实快了,偶然问之:汝建之索引为何类型?答曰:... 3.终于受到刺激开始奋发图强,买书,gg查资料终于知道

使用查询改写提高查询性能

性能 无需改变SQL查询就可以大幅提高查询性能. 你是否为等待你的查询返回结果而感到疲惫?你是否已经为增强索引和调优SQL而感到疲惫,但仍然不能提高查询性能?那么,你是否已经考虑创建物化视图?有了物化视图,那些过去需要数小时运行的报告可以在几分钟内完成.物化视图可以包括联接(join)和集合(aggregate),它提供了一种储存预计算结果的方法. 在执行一个查询时,优化器会判定访问物化视图或数据驻留的基础表是否更快一些.如果优化器判定查询物化视图是更好的解决方案,那么优化器会在一个被称为"查询