作者:orczhou@ninedata
来源:云数据库技术
在不同的云厂商购买相同规格的MySQL实例(如4vCPU-16GB),获得的性能相同吗,他们的差异如何?本文继续尝试回答这个问题。
详细数据:
测试结果概述
在本次测试中:阿里云RDS MySQL性能表现最好,极限的QPS达到了4万;其次是腾讯云,达到了3.2万;第二梯队是华为云、百度云和AWS,极限的QPS约2.2万;之后是Azure、Google云,极限QPS约1.2万;最后是Oracle云,极限QPS约8500。详细的数据和趋势图,可以参考以上的图、表,这里不再详述。
本次测试新增了“单位CPU计算能力”、“单位CPU上的Sysbench QPS”等数值,可以更好得帮助开发者理解这些性能表现后的原因。
“单位CPU计算能力”提供的Sysbench QPS
“单位CPU上的Sysbench QPS”(Sysbench QPS per CPU Capacity Unit),很大程度上展现了各个厂商在该测试模型下,对MySQL内核性能优化的效果如何。
本次测试中,新增了“CPU计算能力指标”,参考上图的“cpu_capacity”数据。“CPU计算能力指标”,表示该实例的CPU,在较高并发(等于或超过CPU核数/超线程)情况下,每秒能够完成多少万次简单的散列计算。例如阿里云的“CPU计算能力指标”是80.4,则表示该CPU平均每秒能够完成80.4万次简单字符串散列计算。
有了这个指标,我们可以对上述的性能指标再进行一次深入的观察:
首先,可以直观的看到,每个云厂商,提供的该标准规格下CPU资源具体为多少。这也就是上图中蓝色的柱状图。例如,这里的阿里云RDS MySQL的“CPU计算能力”为80.4,腾讯云为93.3,华为云为163.6。可以看到,各个云厂商对于“相同”(4c16g)的实例,提供了不同的CPU计算能力。而这些计算能力也在各个RDS MySQL的Sysbench QPS中有所表现。
更加深入的,还可以观察到每个云厂商在“单位CPU计算能力”所能够提供的Sysbench QPS。这里,对“单位CPU计算能力”定义是:在MySQL中“一万次简单散列”的计算资源。上图中的红色柱状图,即表示“单位CPU计算能力”所能够提供的Sysbench QPS。
因为该指标不再关注绝对CPU表现下的Sysbench QPS,所以,该指标可以反映各个厂商在该测试模型下,对MySQL内核性能优化的效果如何。
当然,对于开发者选择RDS MySQL来说,有时候只关注绝对Sysbench QPS就可以了。
还需要注意的是,因为各个云厂商的架构、性能参数等各不相同,所以,在做对比的时候,需要考虑这些因素。例如,百度的RDS MySQL的sync_binlog参数是1000,其他厂商都是1;再比如,AWS RDS MySQL使用的存储同步复制,所以默认情况下,Binlog甚至是关闭的(准确的说,应该是与automated backups是否开启有关)。
关于该测试
在上一次测试:《全球八大云厂商,谁的RDS MySQL性能最强?》中详细的描述了如下问题:
如何重现该测试:测试工具与参数该测试中如何选择各个云厂商的4vCPU 16GB的实例:实例规格的选择关于该测试的限制本次测试这些内容并没有改变,这里不再赘述。
阿里云 RDS MySQL
本次测试了杭州、北京两个地区RDS MySQL,两个地区的实例性能相差比较明显:4万 vs 3.2万。并且,本次测试性能相比于之前的测试,性能增长明显。从这里的观察来看:
CPU计算能力提升明显默认情况下关闭了performance_schema开启或优化了thread_pool ,注意到,thread_pool_size参数发生了变化腾讯云 TencentDB for MySQL
本次仅测试了腾讯云北京、独享实例,整体的性能表现依旧非常好。纵向的,与5月份的测试对比,性能较为稳定,没有太大的波动。值得注意的是,相比于之前(202405上海区域),本次测试腾讯云的实例使用了更少的“CPU计算能力”,但依旧获得了与之前测试较为接近的性能表现。
华为云 RDS MySQL
本次测试华为云表现稳定,与之前的测试表现非常接近:性能数据接近,版本几乎相同(build号从“8.0.28-231002”升为了“8.0.28-231003”),所提供的CPU计算能力也几乎相同。注意到,华为云RDS MySQL一直是所有云厂商,所提供的计算能力最高的厂商。似乎,是这样,别的云厂商的的4c16g通常是,4个超线程,而华为云似乎真的是提供了4个核(cores)。
百度云 RDS MySQL
百度云RDS提供非常稳定的性能。如下图数据所示,四次测试,整体的性能表现非常稳定,地域差异也比较小。
亚马逊Amazon RDS MySQL
AWS是所有云厂商中,性能管理做的最好的,对于不同代际的CPU在实例代码层面能够直接看到。可以看到,其性能整体上较为稳定,但本次进行两次测试,相比之前要更低一些,从配置和CPU计算能力指标来看,并没有明显差别。
微软Azure Database for MySQL
Azure的实例有着很多厂商类似的CPU代差导致的性能波动问题,在202409的测试中CPU计算能力指标为56.3,相比202405表现的63.9,也下降了12%,Azure Database for MySQL的Sysbench QPS性能也随之下降。
谷歌云上的Cloud SQL Enterprise
Google云的MySQL托管服务在最近两年里做了非常多的增强,一方面推出了AlloyDB,托管MySQL也推出了Enterprise Plus版本。性能上,202409的测试中,与202405的测试性能并没有太大的差异;此外,它的Enterprise Plus版本的性能提升也非常明显,有着更多的CPU计算性能,也有着更多的内存资源。
Oracle Cloud上的HeatWave MySQL
MySQL是属于Oracle的,Oracle也一直在持续投入发展MySQL数据库与社区的建设。Oracle Cloud是最早推出MySQL 8.4、MySQL 9.0的云厂商,这次也一并测试这两个最新版本在Oracle Cloud上的表现。
可以看到,整个上各个版本在该测试模型下表现较为一致。仅8.4.0(也就是8.4的第一个版本)在超高并发下,性能有明显退化,而该问题也在最新的8.4.2修复了。
最后
该测试很好的展示了不同云厂商之间RDS MySQL性能差异,甚至在同一个云厂商的不同区域,甚至在同一个云厂商的同一区域不同时间建立的实例,其性能都可能会有一定的差异。理解了这些,当我们需要在多云之间进行迁移或变更区域时,可以更好地进行数据库的容量规划。
关于作者:orczhou@ninedata,NineData的联合创始人 & 技术副总裁、Oracle ACE,<高性能MySQL>第三/四版译者。作者的个人公众号:orczhou