1 简介
MapD是使用GPU以毫秒为单位计算大量数据的先驱,号称比传统基于CPU的数据库快几个数量级。
MapD分为社区版与企业版,共同具备的特性有:
- 先进的内存管理:可以对内存和显存的数据进行交换。
- 混合计算:SQL引擎可以同时使用CPU和GPU进行并行运算。
- 支持SQL语言查询
- 快速编译
- 自带MapD Immerse组件可以进行图表展示
- 无索引化,采用列存储
社区版不具备分布式水平扩展、高可用、LDAP、ODBC和本地图形渲染的功能。
2 系统配置
CPU | 2*Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz |
内存 | 256G |
磁盘 | 2T sata |
GPU | 4*GeForce GTX 1080 TI(每块10G显存) |
对比vertica:
Cpu | 2*Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz |
内存 | 64G |
3 性能测试1
原始数据:每个bcp 100w行,行长330B,bcp大小约300m,共200个文件,2亿行数据,64G
3.1 入库性能
数据库 | 导入性能 |
mapd | 5.45w/s |
vertica | 26.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+cpu | mapd cpu only | vertica |
sql1 | 12941 ms | 14623 ms | 2132 ms |
sql2 | 18342 ms | 18278 ms | 3656 ms |
sql3 | 33745 ms | 32504 ms | 3116 ms |
有缓存:
Sql 查询耗时 | mapd gpu+cpu | mapd cpu only | vertica |
sql1 | 38 ms | 92 ms | 2132 ms |
sql2 | 53 ms | 184 ms | 3656 ms |
sql3 | 139 ms | 186 ms | 3116 ms |
4 性能测试2
原始数据:美国2008年飞行数据(mapd官方提供)行长约400B,共2.1亿行,84G
4.1 入库性能
数据库 | 导入性能 |
mapd | 21.1w/s |
vertica | 10.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+cpu | mapd cpu only | vertica |
sql1 | 49712 ms | 49662 ms | 35 ms |
sql2 | 66231 ms | 64906 ms | 3354 ms |
sql3 | 59972 ms | 58637 ms | 3215 ms |
sql4 | 34947 ms | 35105 ms | 3306 ms |
sql5 | 28173 ms | 28627 ms | 1179 ms |
有缓存:
Sql 查询耗时 | mapd gpu+cpu | mapd cpu only | vertica |
sql1 | 84 ms | 58 ms | 47 ms |
sql2 | 50 ms | 67 ms | 3494 ms |
sql3 | 86 ms | 97 ms | 157 ms |
sql4 | 144 ms | 394 ms | 3639 ms |
sql5 | 191 ms | 210 ms | 933 ms |
4.3 并发测试
使用3.2中SQL3、SQL5进行并发测试,其中flight_month与distance随机生成:
SQL3:
GPU+CPU:
并发数 | QPS | 显存 | GPU | CPU |
1 | 20 | 3G*4 | 5% | 4% |
10 | 20.8 | 3G*4 | 5% | 4% |
20 | 20.4 | 3G*4 | 5% | 4% |
50 | 20.3 | 3G*4 | 6% | 4% |
100 | 20.2 | 3G*4 | 6% | 4% |
200 | 20.3 | 3G*4 | 6% | 4% |
CPU ONLY:
并发数 | QPS | 内存 | GPU | CPU |
1 | 32.5 | 1G | 0 | 20% |
10 | 45 | 1G | 0 | 21% |
20 | 46.5 | 1G | 0 | 21% |
50 | 45.4 | 1G | 0 | 21% |
100 | 45.9 | 1G | 0 | 21% |
200 | 无法测试,服务每次都崩溃 |
SQL5:
GPU+CPU:
并发数 | QPS | 显存 | GPU | CPU |
1 | 18.2 | 3G*4 | 35% | 4% |
10 | 18.5 | 3G*4 | 35% | 4% |
20 | 18.3 | 3G*4 | 35% | 4% |
50 | 18.6 | 3G*4 | 35% | 4% |
100 | 18.6 | 3G*4 | 35% | 4% |
200 | 18.6 | 3G*4 | 35% | 4% |
CPU ONLY:
并发数 | QPS | 内存 | GPU | CPU |
1 | 14.3 | 2G | 0 | 30% |
10 | 16.9 | 2G | 0 | 35% |
20 | 17 | 2G | 0 | 35% |
50 | 17.1 | 2G | 0 | 35% |
100 | 16.9 | 2G | 0 | 35% |
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),其余时间都在等待。
5 性能测试2(SSD环境)
5.1 系统配置
CPU | Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz*4 |
内存 | 8G |
磁盘 | 260G ssd |
GPU | NVIDIA Tesla P40(24G显存)*1 |
5.2 入库性能
数据库 | 导入性能 | 表大小 | 数据压缩比 |
mapd | 27.5w/s | 37G | 2.27 |
vertica | 14.2w/s | 6.4G | 13.12 |
导入时CPU使用率接近100%,均为瓶颈。
5.3 查询性能
测试语句同性能测试2
性能对比:
无缓存
gpu+cpu | cpu only | vertica | |
sql1 | 3641 ms | 3095 ms | 154 ms |
sql2 | 4571 ms | 4319 ms | 5838 ms |
sql3 | 4428 ms | 3942 ms | 511 ms |
sql4 | 5914 ms | 5699 ms | 8698 ms |
sql5 | 6666 ms | 5903 ms | 3289 ms |
有缓存
gpu+cpu | cpu only | vertica | |
sql1 | 52 ms | 72 ms | 169 ms |
sql2 | 58 ms | 106 ms | 5787 ms |
sql3 | 57 ms | 149 ms | 153 ms |
sql4 | 252 ms | 496 ms | 8567 ms |
sql5 | 162 ms | 212 ms | 2637 ms |
5.4 并发测试
测试语句同性能测试2
并发 | QPS | 显存 | GPU |
1 | 7.9 | 4.8G | 90% |
10 | 8.5 | 4.8G | 90% |
20 | 8.5 | 4.8G | 90% |
50 | 8.4 | 4.8G | 90% |
6 第三方测试数据
配置:
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 1 | SELECT cab_type, count() FROM trips GROUP BY cab_type; |
Query 2 | SELECT passenger_count, avg(total_amount) FROM trips GROUP BY passenger_count; |
Query 3 | SELECT passenger_count, extract(year from pickup_datetime) AS pickup_year, count() FROM trips GROUP BY passenger_count, pickup_year; |
Query 4 | SELECT 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; |
测试结果:
7 测试结论
- 与vertica性能对比:
- 入库性能:取决于不同业务数据,2种测试数据结果不一致
- 数据有缓存场景下,mapd的大部分统计查询得益于GPU的高吞吐量性能远高于vertica
- 每次重启数据库并清除系统cache后查询的场景下,mapd的性能受制于磁盘IO,所以不能发挥GPU的运算优势。此时vertica反而性能高于mapd。mapd在首次加载数据时性能较差。但是在SSD环境下首次加载数据时间大大减小,部分场景也优于vertica。
- 数据压缩比远低于vertica
- mapd引擎内部并无并发处理机制,所有查询都是串行执行。已向官方证实。
- mapd适用于瓶颈在于CPU而不是磁盘的IO的业务,如即席查询、多维分析等。
- 在计算压力小的业务里,GPU模式性能不一定会高于CPU模式。
- SQL方面只支持INSERT、SELECT,不支持UPDATE、DELETE、事务、索引等。
- 在测试过程中mapd服务端出现过不止一次崩溃,稳定性存在问题;且崩溃无错误日志,很难定位问题。