Greenplum 性能评估公式 - 阿里云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 浅析》
但是这些都是在构建了数据库之后才可以进行的测试，在构建数据库系统之前，如何评估性能呢？
哪些硬件指标决定了数据库性能
这些硬件指标是数据库性能的主要影响因素
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》
但是这依旧是在有数据库、有数据（或者有数据的统计信息）导入到数据库之后进行的评估。
在没有数据库，只有硬件指标和数据指标时，如何评估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》