Greenplum 性能评估公式 - 阿里云HybridDB for PostgreSQL最佳实践

3 minute read

背景

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

例如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》

Flag Counter

digoal’s 大量PostgreSQL文章入口