PG数据库插件性能对比测试

简介

PG-Strom是在PostgreSQL上的GPU插件,可以使用GPU进行运算。

cstore_fdw是PostgreSQL上的列式插件,使用该插件可以对表进行列式存储。

对比原生PG与使用上述插件的导入及查询性能。

系统配置

CPUIntel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz*4
内存8G
磁盘260G ssd
GPUNVIDIA Tesla P40(24G显存)*1

性能测试

原始数据美国2008年飞行数据(MapD官方提供)行长约400B,共2.1亿行,84G

3.1 入库性能

数据库导入性能表大小数据压缩比
pg-strom9.3w/s66G1.27
pg-strom多进程导入23.9w/s66G1.27
cstore_fdw7w/s3.8G22.1

3.2 查询性能

测试语句:

Sql1: select count(*) from flights;
Sql2: select count(*) from flights where origin_country=’USA’;
Sql3: select count(*) as cnt,avg(distance) as dis from flights where flight_month=10;
Sql4: select origin_city,dest_city,count(*) as cnt,avg(airtime) as atime from flights group by origin_city,dest_city order by cnt desc,atime;
Sql5: select origin_state,dest_state,count(*) as cnt,avg(airtime) as atime from flights where distance<175 group by origin_state,dest_state ;

性能对比:

无缓存:

Sql 查询耗时(ms)pgpg with pg-stromcstore_fdwpg-strom & cstore_fdw
sql170833861962447835965
sql2143490907824931647441
sql3754908869967667902
sql412866669421914162485152
sql5212259919564123039182

有缓存:

Sql 查询耗时(ms)pgpg-stromcstore_fdwpg-strom & cstore_fdw
sql171456869462250335686
sql2142894910043974338782
sql3742878887445954686
sql412706289276811936264952
sql5211838881074195138719

测试结论

  1. 入库性能:PG一个导入进程只能用满1核,故需要多进程导入才能达到性能上限。但是cstore_fdw不支持多进程并发导入,只支持单进程。
  2. cstore_fdw插件数据压缩比很高,甚至高于vertica的13.12。
  3. 两个插件较原生PG均能大幅提高性能,且可以共同生效。
  4. 有无缓存对PG性能基本没有影响,只有cstore_fdw插件在有缓存场景下性能有所提升。
  5. 分析型业务可以使用cstore_fdw插件提速,但是该插件使用外部表,功能上限制较大,不支持删除与修改。

MapD性能测试

简介

MapD是使用GPU以毫秒为单位计算大量数据的先驱,号称比传统基于CPU的数据库快几个数量级。

MapD分为社区版与企业版,共同具备的特性有:

  1. 先进的内存管理:可以对内存和显存的数据进行交换。
  2. 混合计算:SQL引擎可以同时使用CPU和GPU进行并行运算。
  3. 支持SQL语言查询
  4. 快速编译
  5. 自带MapD Immerse组件可以进行图表展示
  6. 无索引化,采用列存储

社区版不具备分布式水平扩展、高可用、LDAP、ODBC和本地图形渲染的功能。

系统配置

CPU2*Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
内存256G
磁盘2T sata
GPU4*GeForce GTX 1080 TI(每块10G显存)

对比vertica:

Cpu2*Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
内存64G

性能测试1

原始数据每个bcp 100w行,行长330B,bcp大小约300m,共200个文件,2亿行数据,64G

3.1 入库性能

数据库导入性能
mapd5.45w/s
vertica26.18w/s

3.2 查询性能

测试语句:

Sql1: select count(*) from datadetail_qqnum;
Sql2: select count(distinct datasetid) from datadetail_qqnum;
Sql3: select datasetid ,count(*) from datadetail_qqnum group by datasetid;

性能对比:

无缓存:

Sql 查询耗时mapd gpu+cpumapd cpu onlyvertica
sql112941 ms14623 ms2132 ms
sql218342 ms18278 ms3656 ms
sql333745 ms32504 ms3116 ms

有缓存:

Sql 查询耗时mapd gpu+cpumapd cpu onlyvertica
sql138 ms92 ms2132 ms
sql253 ms184 ms3656 ms
sql3139 ms186 ms3116 ms

性能测试2

原始数据美国2008年飞行数据(mapd官方提供)行长约400B,共2.1亿行,84G

4.1 入库性能

数据库导入性能
mapd21.1w/s
vertica10.6w/s

4.2 查询性能

测试语句:

Sql1: select count(*) from flights;
Sql2: select count(*) from flights where origin_country=’USA’;
Sql3: select count(*) as cnt,avg(distance) as dis from flights where flight_month=10;
Sql4: select origin_city,dest_city,count(*) as cnt,avg(airtime) as atime from flights group by origin_city,dest_city order by cnt desc,atime;
Sql5: select origin_state,dest_state,count(*) as cnt,avg(airtime) as atime from flights where distance<175 group by origin_state,dest_state ;

性能对比:

无缓存:

Sql 查询耗时mapd gpu+cpumapd cpu onlyvertica
sql149712 ms49662 ms35 ms
sql266231 ms64906 ms3354 ms
sql359972 ms58637 ms3215 ms
sql434947 ms35105 ms3306 ms
sql528173 ms28627 ms1179 ms

有缓存:

Sql 查询耗时mapd gpu+cpumapd cpu onlyvertica
sql184 ms58 ms47 ms
sql250 ms67 ms3494 ms
sql386 ms97 ms157 ms
sql4144 ms394 ms3639 ms
sql5191 ms210 ms933 ms

4.3 并发测试

使用3.2中SQL3、SQL5进行并发测试,其中flight_month与distance随机生成:

SQL3:

GPU+CPU:

并发数QPS显存GPUCPU
1203G*45%4%
1020.83G*45%4%
2020.43G*45%4%
5020.33G*46%4%
10020.23G*46%4%
20020.33G*46%4%

CPU ONLY:

并发数QPS内存GPUCPU
132.51G020%
10451G021%
2046.51G021%
5045.41G021%
10045.91G021%
200无法测试,服务每次都崩溃

SQL5:

GPU+CPU:

并发数QPS显存GPUCPU
118.23G*435%4%
1018.53G*435%4%
2018.33G*435%4%
5018.63G*435%4%
10018.63G*435%4%
20018.63G*435%4%

CPU ONLY:

并发数QPS内存GPUCPU
114.32G030%
1016.92G035%
20172G035%
5017.12G035%
10016.92G035%
200无法测试,服务每次都崩溃

通过测试可以看出mapd引擎内部并无并发处理机制,实际多个会话执行的查询都是串行执行,系统资源也并未随并发数升高而增加。

截取日志同样可以佐证:

I0209 19:12:22.732260 51362 MapDHandler.cpp:607] sql_execute-COMPLETED Total: 10674 (ms), Execution: 53 (ms)

总sql时间为10674 (ms),实际真正执行耗时53 (ms),其余时间都在等待。

性能测试2(SSD环境)

5.1 系统配置

CPUIntel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz*4
内存8G
磁盘260G ssd
GPUNVIDIA Tesla P40(24G显存)*1

5.2 入库性能

数据库导入性能表大小数据压缩比
mapd27.5w/s37G2.27
vertica14.2w/s6.4G13.12

导入时CPU使用率接近100%,均为瓶颈。

5.3 查询性能

测试语句同性能测试2

性能对比:

无缓存

 gpu+cpucpu onlyvertica
sql13641 ms3095 ms154 ms
sql24571 ms4319 ms5838 ms
sql34428 ms3942 ms511 ms
sql45914 ms5699 ms8698 ms
sql56666 ms5903 ms3289 ms

有缓存

 gpu+cpucpu onlyvertica
sql152 ms72 ms169 ms
sql258 ms106 ms5787 ms
sql357 ms149 ms153 ms
sql4252 ms496 ms8567 ms
sql5162 ms212 ms2637 ms

5.4 并发测试

测试语句同性能测试2

并发QPS显存GPU
17.94.8G90%
108.54.8G90%
208.54.8G90%
508.44.8G90%

第三方测试数据

配置:

MapD: 1 machine (16 cores, 512 GB RAM, 2 x 1TB SSD, 8 Nvidia Pascal Titan X GPUs)

Redshift: 6 machines (36 cores, 244 GB RAM, 16TB HDD, AWS ds2.8xlarge)

Presto: 50 machines (4 cores, 15 GB RAM, 100GB SSD, GCP n1-standard-4)

Spark: 11 machines (4 cores, 15 GB RAM, 2 X 40GB storage, AWS m3.xlarge)

原始数据: 11亿出租车数据

测试语句:

Query 1SELECT cab_type, count() FROM trips GROUP BY cab_type;
Query 2SELECT passenger_count, avg(total_amount) FROM trips GROUP BY passenger_count;
Query 3SELECT passenger_count, extract(year from pickup_datetime) AS pickup_year, count() FROM trips GROUP BY passenger_count, pickup_year;
Query 4SELECT passenger_count, extract(year from pickup_datetime) AS pickup_year, cast(trip_distance as int) AS distance, count(*) AS the_count FROM trips GROUP BY passenger_count, pickup_year, distance ORDER BY pickup_year, the_count  desc;

测试结果:

测试结论

  1. 与vertica性能对比:
    • 入库性能:取决于不同业务数据,2种测试数据结果不一致
    • 数据有缓存场景下,mapd的大部分统计查询得益于GPU的高吞吐量性能远高于vertica
    • 每次重启数据库并清除系统cache后查询的场景下,mapd的性能受制于磁盘IO,所以不能发挥GPU的运算优势。此时vertica反而性能高于mapd。mapd在首次加载数据时性能较差。但是在SSD环境下首次加载数据时间大大减小,部分场景也优于vertica。
    • 数据压缩比远低于vertica
  2. mapd引擎内部并无并发处理机制,所有查询都是串行执行。已向官方证实。
  3. mapd适用于瓶颈在于CPU而不是磁盘的IO的业务,如即席查询、多维分析等。
  4. 在计算压力小的业务里,GPU模式性能不一定会高于CPU模式。
  5. SQL方面只支持INSERT、SELECT,不支持UPDATE、DELETE、事务、索引等。
  6. 在测试过程中mapd服务端出现过不止一次崩溃,稳定性存在问题;且崩溃无错误日志,很难定位问题。

docker常用命令

记录下自己常用的一些docker命令:
搜索 docker search imagename
下载 docker pull path/imagename 官方镜像则没有path,默认下载最新版本
查看已下载的镜像 docker images
查看正在运行的镜像 docker ps
查看所有容器docker ps -a
删除容器 docker rm containername
删除镜像 docker rmi imagename
查看构建历史docker history imagename
创建镜像(保存修改过的容器)docker commit containername imagename
运行容器,并开启交互式会话 docker run -ti imagename
后台运行容器docker run -d imagename
跟踪带时间戳的日志docker logs -ft containername
附着已运行的容器docker attach containername
以上一次的命令启动容器docker start containername
查看容器内top进程docker top containername
导出容器 docker export containername >> file.tar
导入为镜像 cat file.tar | docker import – imagename