这个地球上，大部分人都是模仿别人唱歌，也有人唱歌让原唱冒汗，比如张学友。
这个地球上，有一些云厂商做服务有明显的效仿痕迹，而有一些云厂商能让“原唱”尬死，比如谷歌“原唱”的Kubernetes，大部分都运行在AWS上，而不是谷歌的GCP云上。
CNCF 2017年的调研数据
上个月，AWS官方博客提到了Principled Technologies的又一个测试报告，说的是在AWS上运行的SQL Server比在Azure上运行得还好，延迟低，性能高，成本还低一大大大截。
于是就标题党出了本文的题目。
AWS方案是EBS gp3块存储加上EC2 r5b.16xlarge实例，对比的是Azure的两种存储加上E64ds_v4 VM实例，无论是延迟，还是吞吐性能，AWS的方案都是全面胜出。
对比跑分的配置概况
为了让对比更有说服力，两家方案的配置要尽可能的相似。我们能先看到，操作系统和SQL Server版本完全一致，都是微软家的。
处理器部分，EC2用的是英特尔第二代至强可扩展处理器白金8259CL，主频2.5G，VM用的是英特尔第二代至强可扩展处理器白金8272CL，主频是2.60G，两个实例都有64个vCPU，而且，两个实例每小时的成本也相近。另外，内存都是500G出头，两部分基本大约一致。
存储部分，AWS用是Amazon EBS gp3，对10块500GB硬盘做了条带化，Azure的存储有两个配置，一个是Azure Premium SSD，对11块2000G硬盘做了条带化，一个是Azure ultra disk，是单个4TB的硬盘。
图自Azure官网：E64ds_v4 VM的IOPS和带宽上限
之所以有这样的存储配置，是为了尽可能发挥实例的最大性能。因为，E64ds_v4实例支持最高80000 IOPS（1200MB带宽），AWS的r5b.16xlarge两倍于E64ds_v4，最高173333 IOPS（5000MB带宽）。
AWS每个EBS gp3最大IOPS是16000，10块gp3做条带化就是160000 IOPS，没有达到r5b.16xlarge的限制。
Azure的单个Azure ultra disk就能提供80000 IOPS，刚好达到E64ds_v4的上限。Premium SSD一共配置了12块盘，支持开启和关闭缓存两种工作模式，开启了读缓存来增强事务性场景的性能，最后也达到了82500的IOPS。
测试用的是HammerDB v4.2的TPROC-C OLTP测试负载，之所以选择这种测试负载，主要是因为这是一种公开的测试方案，谁都可以复现测试结果。另外提一句，三种测试方案使用的测试数据库文件都是3.2TB的。
以下三张图总结了对比测试结果：
Principled Technologies的报告喜欢用NOPM这个单位，说的是new orders per minute，每分钟的订单数，在测试中，AWS r5b.16xlarge的NOPM是E64ds_v4加Premium SSD（上图中的P40+P60）的1.7倍，是E64ds_v4加Ultra Disk的2.7倍。
这张图对比的是平均响应时间，看图吧，不多说。
最狠的是性价比优势，对比的是每处理1000个NOPM的所需要花费的成本，AWS r5b.16xlarge加gp3的成本比E64ds_v4加Premium SSD低49%，比E64ds_v4加Ultra Disk低了49%。
最后这张图是测试性价比的一个详情，成本计算中包含了720小时的云资源费用和Licence费用，总之，花差不多的钱，AWS r5b.16xlarge加gp3的方案干的活儿最多。
摆完事实讲道理
企业用户需要能处理更多数据库事务的公有云服务，在满足性能需求，满足一致性要求的前提下，企业用户应该考虑尽可能的降低成本，这种测试对比就很好地给出了提示，帮助企业用云的时候更好地控制成本。
EBS gp3是AWS最新一代的基于SSD的通用型EBS卷，与gp2相比，性价比提升了20%。gp3相比gp2有一个更新，就是能在不增加容量的情况下提升IOPS和吞吐性能，不用为了提升性能而添加用不着的容量。
gp3适用于各种需要高性能和低成本的应用，包括 MySQL、Cassandra、VDI和Hadoop集群，如果需要更高的持久性，更低的延迟，更高的IOPS的话，用io2卷更合适。
END
