开发者社区> 德哥> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

MPP分布式数据库性能评估方法 - 阿里云HybridDB for PostgreSQL最佳实践

简介:
+关注继续查看

背景

通常评估一个数据库的性能,可以选择工业标准测试,或者根据业务模型,建模进行测试。

例如PostgreSQL pgbench支持的tpc-b测试,以及自定义模型测试。

benchmarksql支持的tpc-c测试。

gp_tpch支持的tpc-h测试等等。

参考文档如下

《TPC-H测试 - PostgreSQL 10 vs Deepgreen(Greenplum)》

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

《PostgreSQL pgbench SQL RT 与 事务RT 浅析》

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

但是这些都是在构建了数据库之后才可以进行的测试,在构建数据库系统之前,如何评估性能呢?

哪些硬件指标决定了数据库性能

这些硬件指标是数据库性能的主要影响因素

CPU主频  
  
CPU指令集  
  
CPU核数  
  
内存主频、总线带宽  
  
硬盘的离散IOPS能力  
  
硬盘的连续IOPS能力  
  
硬盘的带宽  
  
网络的带宽  

针对Greenplum数据库,它的主要影响如下:

1、CPU主频

决定了数据库的计算速度,哪些涉及计算呢?例如:

where条件过滤,select子句中的操作符计算,聚合计算,排序 等。

2、CPU指令集

指令集决定了数据库的某些特殊优化的性能,例如:

向量计算。

《PostgreSQL 向量化执行插件(瓦片式实现) 10x提速OLAP》

3、CPU核数

CPU主频决定了单个核的计算能力,而核数,决定了数据库的并行计算的能力。

4、内存主频、总线带宽

当在内存中进行读写时,内存主频和总线带宽大小决定了整体的读写吞吐能力,非常重要。

例如 DDR 2 667,带宽即为64bit×667MHz÷8≈5.3GB/s,如果是双通道内存,还得×2,即双通道DDR 2 667内存数据带宽为10.6GB/s。

https://www.cyberciti.biz/faq/check-ram-speed-linux/

https://en.wikipedia.org/wiki/Memory_bandwidth

例如这个内存,理论读写带宽 64*2*2400/8/1024= 37.5 GB/s

dmidecode --type 17  
  
        Array Handle: 0x0034  
        Error Information Handle: Not Provided  
        Total Width: 72 bits  ## 带ECC, 64+8  
        Data Width: 72 bits  
        Size: 32 GB  
        Form Factor: DIMM  
        Set: None  
        Locator: CPU0_A0  
        Bank Locator: NODE 1  
        Type: DDR4  
        Type Detail:   
        Speed: 2400 MHz  
        Manufacturer:   
        Serial Number:   
        Asset Tag:   
        Part Number:   
        Rank: 2  
        Configured Clock Speed: 2133 MHz  

注意,这是内存的理论极限,单个CPU核心处理时,通常不能达到这个极限速度。

单个CPU的处理速度如何?可以通过一个简单的测试得到

内存速度  
  
#dd if=/dev/zero of=/dev/null bs=4k count=1024000000  
^C68517474+0 records in  
68517473+0 records out  
280647569408 bytes (281 GB) copied, 34.1855 s, 8.2 GB/s  
  
块设备速度  
#dd if=/dev/块设备名 of=/dev/null bs=4k count=102300000  
^C2687957+0 records in  
2687956+0 records out  
11009867776 bytes (11 GB) copied, 4.6525 s, 2.4 GB/s  

实际上,在数据库应用中,算上CPU参与计算的部分,实际上单核应该达不到8.2GB/s的速度。

6、硬盘的离散IOPS能力

索引访问、多个个会话或进程(并发)访问同一个硬盘的数据时,会涉及硬盘的离散访问能力。

(通过预读,可以提升并发顺序访问的能力,趋于连续IOPS的能力。)

7、硬盘的顺序IOPS能力

不考虑并发时,只要不是索引扫描,通常AP系统大部分是顺序的读写文件。

8、硬盘的带宽、硬盘的接口速率

硬盘的带宽、接口速率决定了数据在硬盘中扫描的上限速度。

例如厂商会给出读写带宽这样的数据

http://www.shannon-sys.com/product_detail?id=4929256206666909936

注意,这是硬盘的理论极限,单个CPU核心处理时,通常不能达到这个极限速度。

9、网络的带宽

网络带宽决定了数据导入速度,同时在数据JOIN时,决定了重分布的时候的速度。

单个主机可以有多个网卡,可以有多个数据节点,不管怎样,按总的出口带宽来估算,例如GP集群有10台主机,每台主机2张10GB网卡,则总网络带宽为200 GB。

10、数据存储倾斜性

分布式系统的短板效应,最慢的节点决定了总的处理时间。数据出现倾斜时,这个问题尤为突出。

以上是影响性能的主要因素,那么如何根据这些主要因素,评估SQL的响应速度呢?

PostgreSQL的代价模型中,有一些成本因子,通过成本计算公式和统计信息,可以算出最终的SQL运行成本,如果将成本和时间对齐,就能得知SQL的执行时间。

《优化器成本因子校对 - PostgreSQL explain cost constants alignment to timestamp》

《优化器成本因子校对(disk,ssd,memory IO开销精算) - PostgreSQL real seq_page_cost & random_page_cost in disks,ssd,memory》

但是这依旧是在有数据库、有数据(或者有数据的统计信息)导入到数据库之后进行的评估。

在没有数据库,只有硬件指标和数据指标时,如何评估SQL响应时间呢?

我们可以将公式抽样出来,根据数据库集群的指标以及数据的指标,SQL的需求进行评估。

Greenplum性能评估例子

简化评估模型,因为CPU这方面(例如LLVM、向量优化、或者其他优化)带来的效果是非常明显的,对结果的影响很大。CPU引入的误差我暂时不计较他。同时我们也不考虑数据倾斜。

1 环境介绍

以如下环境为例,讲一下如何评估性能。

1、硬盘

2块,每块盘读写带宽分别为2GB/s,通过LVM做成一块盘。带宽算4GB/s。

2、内存

512GB,读写带宽 37.5 GB/s

3、CPU

2.5GHz, 32Core

4、网卡

2块10GB网卡

5、机器台数

8台

6、每台机器上的数据节点数

每台16个数据节点。

2 性能指标数据

某个环境下测试得出的性能指标

以整型数据类型为例:

GP列存

postgres=# create table mmtest(id int) with (appendonly=true, blocksize=2097152, ORIENTATION=COLUMN);  
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.  
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.  
CREATE TABLE  
  
postgres=# insert into mmtest select generate_series(1,100000);  
INSERT 0 100000  
insert into mmtest select * from mmtest ;  
...  
postgres=# insert into mmtest select * from mmtest ;  
INSERT 0 409600000  
  
postgres=# select pg_size_pretty(pg_total_relation_size('mmtest'));  
 pg_size_pretty   
----------------  
 3133 MB  
(1 row)  
  
postgres=# select count(*) from mmtest ;  
   count     
-----------  
 819200000  
(1 row)  
  
Time: 779.444 ms  
  
postgres=# select * from mmtest where id=0;  
 id   
----  
(0 rows)  
  
Time: 422.538 ms  

GP 行存

postgres=# create table mmtest1(id int)  
postgres-# ;  
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.  
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.  
CREATE TABLE  
Time: 273.659 ms  
postgres=# insert into mmtest1 select * from mmtest;  
  
postgres=# select pg_size_pretty(pg_total_relation_size('mmtest1'));  
 pg_size_pretty   
----------------  
 28 GB  
(1 row)  
  
postgres=# select count(*) from mmtest1 ;  
   count     
-----------  
 819200000  
(1 row)  
  
Time: 1171.229 ms  
  
postgres=# select * from mmtest1 where id=0;  
 id   
----  
(0 rows)  
Time: 452.582 ms  

PG 行存

create unlogged table mmtest(id int);  
postgres=# insert into mmtest select generate_series(1,100000);  
INSERT 0 100000  
insert into mmtest select * from mmtest ;  
...  
postgres=# insert into mmtest select * from mmtest ;  
INSERT 0 409600000  
  
postgres=# select pg_size_pretty(pg_total_relation_size('mmtest'));  
 pg_size_pretty   
----------------  
 28 GB  
(1 row)  
  
postgres=# select * from mmtest where id=0;  
 id   
----  
(0 rows)  
  
Time: 56410.222 ms (00:56.410)  
  
32 并行  
3.02秒  

1、GP 列存储

单核 4000万行/s 整型filter速度

整机性能 18.8亿行/s 整型filter速度

(含扫描时间)

2、GP 行存储

单核 3700万行/s 整型filter速度

整机性能 17.7亿行/s 整型filter速度

(含扫描时间)

3、PG 行存储

单核 1500万行/s 整型filter速度

整机性能 2.649亿行/s 整型filter速度

(含扫描时间)

3 查询性能评估

1、数据扫描时间

1.1 非内存命中:

每个进程的扫描速度取决于(1. 行的大小,2. 单核的行处理速度:4000万行/s,3. 单进程的读速度 2.4GB/s),取最长时间。

每台主机的扫描速度上限是:4GB/s

least(记录数/(总数据节点数*4000万), 记录数/(总CPU核心数*4000万), 表大小/(数据节点主机数*4G), 表大小/(总数据节点数*2.4G))

1.2 内存命中:

每个进程的扫描速度取决于(1. 行的大小,2. 单核的行处理速度:4000万行/s,3. 单进程的读速度 8.2GB/s),取最长时间。

每台主机的扫描速度上限是:37.5GB/s

根据每台主机的节点数可以推算出单机的扫描能力,以及整个集群的扫描能力。

least(记录数/(总数据节点数*4000万), 记录数/(总CPU核心数*4000万), 表大小/(数据节点主机数*37.5G), 表大小/(总数据节点数*8.2G))

1.3 OSS扫描能力

阿里云还提供了一个OSS外部表的功能。

在数据节点上的单个进程目前的访问速度约30MB/s。如果用户开多个会话同时访问,速度线性提升。所以这块的上限速度是网卡带宽决定的。

least(主机数*网卡带宽, 数据节点数*30MB/s)

2、数据运算时间

以整型为例,单核的行处理速度:4000万行/s

根据数据节点数以及CPU单个核的处理能力评估整个HybridDB for PostgreSQL的处理能力。

least(总记录数/(总数据节点数*4000万), 总记录数/(总数据节点主机CPU数*4000万))

3、数据聚合时间

以整型COUNT聚合为例,单核的行处理速度:3300万行/s。

根据数据节点数以及CPU单个核的处理能力评估整个HybridDB for PostgreSQL的处理能力。

least(总记录数/(总数据节点数*3300万), 总记录数/(总数据节点主机CPU数*3300万))

4、数据排序时间

根据数据节点数以及CPU单个核的处理能力评估。

还和work_mem,临时文件写入速度,排序方法有关。

5、数据JOIN时间

根据数据节点数以及CPU单个核的处理能力评估。

和JOIN方法有关,HASH,MERGE,NESTLOOP速度评估方法不一。

hash每个表算一次,同时算一次HASH的时间。

merge每个表算一次SORT的时间。

NESTLOOP,内表需要算N次循环的时间。

JOIN还可能涉及数据重分布,需要估算重分布时间。

6、数据返回时间

按MASTER节点的网络带宽,单个CPU的返回速度评估。

4 数据导入性能评估

1、insert 单步提交

并发写,1万条/s以内

2、insert 单句批量提交

并发写,10万条/s以内

3、insert 事务批量提交

并发写,10万条/s以内

4、COPY

并发写,15万条/s以内

5、OSS

阿里云还提供了一个OSS外部表的功能。

在数据节点上的单个进程目前的访问速度约30MB/s。如果用户开多个会话同时访问,速度线性提升。所以这块的上限速度是网卡带宽决定的。

least(主机数*网卡带宽, 数据节点数*30MB/s)

6、gpfdist

与OSS类似。

6 数据重分布性能评估

数据重分布时间评估

根据总的网络带宽评估,比如每台服务器带宽20G, 总共8台服务器, 总共160G带宽。

16GB的表,重分布需要16/(160/8) = 16/20 = 0.8秒

7 数据vacuum full(redistribute)性能评估

1、vacuum full

涉及数据重分布,需要考虑数据重分布时间。

2、alter table redistribute.

如果重分布键不变,不涉及数据重分布,在节点内完成。

特别适合膨胀数据的收缩。

参考

《优化器成本因子校对 - PostgreSQL explain cost constants alignment to timestamp》

《优化器成本因子校对(disk,ssd,memory IO开销精算) - PostgreSQL real seq_page_cost & random_page_cost in disks,ssd,memory》

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【内含干货PPT下载】DTCC 2020 | 阿里云王涛:阿里巴巴电商数据库上云实践
第十一届中国数据库技术大会(DTCC2020),在北京隆重召开。大会以“架构革新 高效可控”为主题,重点围绕数据架构、AI与大数据、传统企业数据库实践和国产开源数据库等内容展开分享和探讨。在数据库智能运维专场上,邀请了阿里云数据库高级技术专家王涛为大家介绍阿里巴巴电商数据库上云的选择、思考与实践。阿里巴巴电商数据库原先是在自己独立的IDC维护的,伴随着阿里巴巴上云项目,数据库轻松实现上云。阿里云云原生管控以及云原生数据库技术可以帮助业务实现平滑上云目标,进而实现资源最大化成本最优化的目标。阿里巴巴希望利用阿里云的技术体系,帮助客户大规模上云,打造自己的运维管控平台。
2286 0
[大数据新手上路]“零基础”系列课程--如何将ECS上的Hadoop数据迁移到阿里云数加·MaxCompute
 想用阿里云数加·大数据计算服务(MaxCompute),但是现在数据还在hadoop上,怎么办?   别烦恼,跟着我们走,来一次MaxCompute零基础数据迁移之旅~Let’s Go!
15151 0
【云栖神侠传】—阿里云数据库专家德歌告诉你PostgreSQL的那些事
云栖神侠传—阿里云数据库专家德歌告诉你PostgreSQL的那些事 何为云栖神侠传? 互联网江湖门派风起云涌。 “A"门派在纷争不断的业界,声名显赫! 在“A"门派中,有一个世外桃源名叫“云栖社区”。 在云栖社区中,云集了众多“A"门派高手,他们功力深厚且行侠仗义,助人为乐
5042 0
如何搭建阿里云RDS PostgreSQL数据库的物理备库
如何搭建阿里云RDS PostgreSQL数据库的物理备库 用户在阿里云购买了RDS PostgreSQL,如何在自己的机房或者ECS上建立备库?关于如何构建逻辑备库,在我以前的文章有详细的讲解,所谓逻辑备库,是可以跨版本,甚至仅仅同步一部分相同步的表的备库。https://yq.aliyun
8408 0
+关注
德哥
公益是一辈子的事, I'm digoal, just do it.
2153
文章
245
问答
来源圈子
更多
让用户数据永远在线,让数据无缝的自由流动
+ 订阅
相关文档: 云数据库 OceanBase 版 可信账本数据库 云原生关系型数据库 PolarDB PostgreSQL引擎
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载