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

digoal 2017-07-25

465

TAG 11

作者

digoal

日期

2017-07-25

背景

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

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

文章转载自digoal，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

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

TAG 11

作者

日期

标签

背景

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

dd if=/dev/zero of=/dev/null bs=4k count=1024000000

dd if=/dev/块设备名 of=/dev/null bs=4k count=102300000

Greenplum性能评估例子

1 环境介绍

2 性能指标数据

3 查询性能评估

4 数据导入性能评估

6 数据重分布性能评估

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

参考

PostgreSQL 许愿链接

9.9元购买3个月阿里云RDS PostgreSQL实例

PostgreSQL 解决方案集合

德哥 / digoal's github - 公益是一辈子的事.

评论

相关阅读