本文共 6596 字，大约阅读时间需要 21 分钟。
通常评估一个数据库的性能，可以选择工业标准测试，或者根据业务模型，建模进行测试。
例如PostgreSQL pgbench支持的tpc-b测试，以及自定义模型测试。
benchmarksql支持的tpc-c测试。
gp_tpch支持的tpc-h测试等等。
参考文档如下
但是这些都是在构建了数据库之后才可以进行的测试，在构建数据库系统之前，如何评估性能呢？
这些硬件指标是数据库性能的主要影响因素
CPU主频 CPU指令集 CPU核数 内存主频、总线带宽 硬盘的离散IOPS能力 硬盘的连续IOPS能力 硬盘的带宽 网络的带宽
针对Greenplum数据库，它的主要影响如下：
1、CPU主频
决定了数据库的计算速度，哪些涉及计算呢？例如：
where条件过滤，select子句中的操作符计算，聚合计算，排序 等。
2、CPU指令集
指令集决定了数据库的某些特殊优化的性能，例如：
向量计算。
3、CPU核数
CPU主频决定了单个核的计算能力，而核数，决定了数据库的并行计算的能力。
4、内存主频、总线带宽
当在内存中进行读写时，内存主频和总线带宽大小决定了整体的读写吞吐能力，非常重要。
例如 DDR 2 667，带宽即为64bit×667MHz÷8≈5.3GB/s，如果是双通道内存，还得×2，即双通道DDR 2 667内存数据带宽为10.6GB/s。
例如这个内存，理论读写带宽 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、硬盘的带宽、硬盘的接口速率
硬盘的带宽、接口速率决定了数据在硬盘中扫描的上限速度。
例如厂商会给出读写带宽这样的数据
注意，这是硬盘的理论极限，单个CPU核心处理时，通常不能达到这个极限速度。
9、网络的带宽
网络带宽决定了数据导入速度，同时在数据JOIN时，决定了重分布的时候的速度。
单个主机可以有多个网卡，可以有多个数据节点，不管怎样，按总的出口带宽来估算，例如GP集群有10台主机，每台主机2张10GB网卡，则总网络带宽为200 GB。
10、数据存储倾斜性
分布式系统的短板效应，最慢的节点决定了总的处理时间。数据出现倾斜时，这个问题尤为突出。
以上是影响性能的主要因素，那么如何根据这些主要因素，评估SQL的响应速度呢？
PostgreSQL的代价模型中，有一些成本因子，通过成本计算公式和统计信息，可以算出最终的SQL运行成本，如果将成本和时间对齐，就能得知SQL的执行时间。
但是这依旧是在有数据库、有数据（或者有数据的统计信息）导入到数据库之后进行的评估。
在没有数据库，只有硬件指标和数据指标时，如何评估SQL响应时间呢？
我们可以将公式抽样出来，根据数据库集群的指标以及数据的指标，SQL的需求进行评估。
简化评估模型，因为CPU这方面（例如LLVM、向量优化、或者其他优化）带来的效果是非常明显的，对结果的影响很大。CPU引入的误差我暂时不计较他。同时我们也不考虑数据倾斜。
以如下环境为例，讲一下如何评估性能。
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个数据节点。
某个环境下测试得出的性能指标
以整型数据类型为例：
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速度
(含扫描时间)
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的返回速度评估。
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类似。
数据重分布时间评估
根据总的网络带宽评估，比如每台服务器带宽20G， 总共8台服务器， 总共160G带宽。
16GB的表，重分布需要16/(160/8) = 16/20 = 0.8秒
1、vacuum full
涉及数据重分布，需要考虑数据重分布时间。
2、alter table redistribute.
如果重分布键不变，不涉及数据重分布，在节点内完成。
特别适合膨胀数据的收缩。
转载地址：http://iaovx.baihongyu.com/