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服务端出现过不止一次崩溃，稳定性存在问题；且崩溃无错误日志，很难定位问题。
