云数据库性能深度测评与对比
笔者一直都在非常深度关注、调研和使用云数据库,其中性能是关注的重点之一。一方面性能是最终成本的重要影响因素,更好的性能,通常意味着使用更少的资源支撑更高的业务量,从而降低整体成本。另外,性能还意味着在极端场景下,数据库的上限支撑能力。
所以,近期对各个云数据库厂商做了一个较为系统的性能对比,供开发者和企业在云数据库选型时的参考。
总览:云数据库性能对比
在进行大量测试之后,对主要的云厂商分别选择了一个“企业级规格”(适合生产环境配置的)进行了对比。性能对比如下图:
可以看到:
*?华为云数据库(红色),在中高并发度时(>=16),性能最强,且高于第二名约18%;
*?腾讯云数据库(紫色),在低并发时(<=8),性能最强,高于第二名约15%;
*?百度云数据库(淡蓝色),在中高并发时(>16),性能跃居第二,仅次于华为云;
*?阿里云数据库(黄色)和谷歌云数据库(绿色)在低并发时也都有不错的表现,高并发之后性能则持续稳定在850 tps。这两家云数据库的响应延迟,表现得也非常接近。
*?亚马逊云数据库(Amazon RDS,蓝色)和微软Azure云在中低并发时,表现出了较为相近的性能趋势,且性能较低。但是在高并发时,两者都表现出了非常强的扩展性,AWS RDS在96和128并发时,性能超过阿里云、腾讯云、谷歌云等,跃居第三;同样的,微软Azure云的数据库在高并发时也超过了阿里云、谷歌云,也有不错的性能表现。
下图是对应的平均延迟趋势图:
“企业级规格”的定义
为了方便跨云对比,笔者根据常见的企业核心数据库配置,在每朵云的RDS的中选择了一个适合的规格作为对比代表,并将该规格称之为“企业级规格”。在众多配置选项中,“企业级规格”需满足如下条件:
*?具备敏捷的高可用能力。需要是双节点或更多,在其中一个节
点出现故障时,能够快速的进行切换(Switchover或failover);
*?需要具备非常高的数据可靠性保障。至少需要跨可用区(同城)的容灾,且数据在不同可用区同步持久化。即需要使用同步或“接近同步”(如半同步)的复制;
*?具备较好的性能一致性。核心数据库对于稳定性有着更高的要求,需要使用独享的计算、存储、内存等资源。不允许因为资源争抢导致的,故数据库的性能表现需要较为一致,不能有太大的波动,或者未知的不可预测的资源争抢。
*?关于规格的大小,这里选择中等规格4vCPU16GB内存/100GB存储/3000 IOPS。主要考虑是,一方面是改规格为核心业务使用的起步规格,另外,考虑将测试程序设计的较为简洁,便于后续持续测试与持续对比。
华为云RDS性能详情
华为云的规格选择与配置都很简洁。主要支持通用型、鲲鹏增强型、独享型实例。我们看看这三种规格的性能情况。
在前面,“企业级规格”对比中,选择了企业级用更为常用的“独享型”。该规格也在全部“企业级规格”的对比中,表现出了最强的性能。在高并发的情况下,性能高出了其他云数据库厂商约30%~100%。
华为云通用规格通过更多的资源共享,可以获得更好的性能,但是也因为共享的原因,性能会有时候不稳定。在这里的测试中,如果使用通用型规格,在高并发时,用户又可以获得约15%~20%的性能。
鲲鹏增强型,使用的是华为自研的鲲鹏芯片(基于ARM)。该芯片的自主化率是非常高的,在国产化芯片中,属于佼佼者。但,也因为复杂的环境和技术的差异,相比Intel的x86有着约20%~30%的性能退化。考虑到鲲鹏芯片在国产芯片中的地位,在国产化场景中,采用该规格是非常不错的选择。
百度云数据库(RDS)性能
在前面的整体对比中看到,百度智能云RDS的“企业级规格”在中高并发时,表现出了非常强的性能,位居榜眼。百度云RDS的选项也比较简单,性能相关主要是“异步/半同步复制”、“高性能/默认参数模板”。其中,“异步/半同步复制”与阿里云、腾讯云等类似,这里不再赘述。
“高性能/默认参数模板”的配置各个云厂商略有一些不同,在笔者测试时,百度云RDS对应的部分参数如下:
*?高性能:sync_binlog=1000、innodb_flush_log_at_trx_commit=2
*?默认参数模板:sync_binlog=1000、innodb_flush_log_at_trx_commit=1
在实际测试中,我们也看到,不同参数模板对于性能有一些影响,但是并不明显。具体性能如下:
再来单独对比一下“默认参数模板”和“高性能参数模板”的性能情况。从如下两幅对比图中,则可以更加清晰的看到,无论是半同步还是异步模式下,这两类参数模板都并没有表现出太大的性能差别。
腾讯云RDS性能详情
在购买腾讯云数据库时,与阿里云类似,也提供了比较丰富的选项供用户选择。用户可以在数据库可靠性与性能、性能稳定性与性能峰值之间进行平衡的选择。这些选项分别是“通用/独享”、“异步/半同步复制”、“高性能/高稳定性参数模板”。其中“通用/独享”选项与阿里云相同,这里不再赘述。
“异步/半同步复制”配置的是主备复制时的同步策略,异步则意味着主备可能存在一定的延迟,不过根据经验来看这个延迟一般是毫秒级别的,有时候甚至更低。“半同步”同步复制下,主库需要再备库接受完日志后,才完成日志的提交,数据可靠性有更好的保障。
“高性能/高稳定性参数模板”的区别在于MySQL / InnoDB的一些与日志相关的参数的配置。其中“高稳定”在数据可靠性上,有着更严格的配置,例如sync_binlog=1&innodb_flush_log_at_trx_commit=1。而“高性能”参数模板,以上两个参数分别为1000和2,是在数据的可靠性上做了适当的让步,以换取更好的性能。
以上,三组选择的组合,一共有如下八个类型的实例,测试的性能表现如下:
可以看到:
首先,通用型实例因为能够获得额外的共享的CPU资源,表现出了普遍的更高的性能,在较高的并发压力之下,高出约100~200%。异步与半同步复制的实例的性能相差也非常明显,有更强可靠性的“半同步复制”性能要低20%~35%之间。
在这一次的测试中,腾讯云的独享实例,也表现出了一些异常情况。高稳定和高性能这两个参数模板之间,在独享实例测试组中,这两组模板的性能表现与其名称表现得并不同。在独享实例的测试中,高稳定的参数模板在高并发的时候,都表现出了更高的性能。即“独享-异步-高稳定” > “独享-异步-高性能” 以及 “独享-半同步-高稳定” > “独享-半同步-高性能”。这一点与预期得是非常不同的。
阿里云RDS性能详情
阿里云RDS提供了非常丰富的选项,给了开发者更大的选择空间,让开发者可以在性能的稳定性、数据可靠性、性能高低之间做更多的平衡与选择。另外,新推出的“经济型”(之前的ARM规格)实例又给了开发者更高性价比的RDS方案。但,另一方面,也让容易让开发者非常困惑,难以选择。
这里我们来看看这些规格、选项对性能的影响情况:(注:各种类型的架构与区别可以参考之前的文章:一张图读懂阿里云数据库RDS架构与选型)
阿里云提供了通用/独享、经济/标准、高性能/默认参数模板等选项,一共有八种如上的组合。“通用/独享”代表了资源的共享程度;经济/标准则代表不同的CPU类型(ARM vs x86);高性能/默认参数模板则是代表数据可靠性的严格程度。更多详细说明可以参考:一张图读懂阿里云数据库RDS架构与选型。
整体上,通用规格,凭借其更多的CPU资源共享,整体表现出了更强劲的性能。一般的,通用规格性能比独享规格的性能的要高50%~150%。所以,当使用通用规格遇到了性能波动的问题的时候,如果升级到独享规格,则需要注意,即使是看似同样大小的规格的实例,性能可能会相差很多。这就是需要获得更稳定性能的代价,下图可以更加清晰的诠释这一点:
阿里云的数据库选项中,还可以选择标准型、经济型。关于经济版是如何“经济的”,目前阿里云并没有太多阐述。不过,比较确定的是,经济版并不是简单仅包含ARM实例(参考)。经济版本,尝试通过更低的价格提供更强的计算能力,付出的代价是什么,并没有太多详细的阐述,可能会包括更激烈的资源竞争等。关于标准版和经济版的详细的对比可以参考:阿里云RDS标准版(x86) vs 经济版(ARM)性能对比。
在阿里云实例的购买过程中,还有一个参数模板的选项。共有三组:“默认参数模板”、“异步参数模板”、“高性能参数模板”(参考)。向用户提供了可靠性与性能的平衡选择。数据可靠性上:“默认参数模板” > “异步参数模板” > “高性能参数模板”,性能则是反过来的:
Amazon RDS提供了m6i(第三代Intel Xeon/Ice Lake实例)、m5(Xeon? Platinum 8175M or 8259CL)、Graviton 2(即m6g)、Graviton 3(即m7g)这四种架构选择,在性能上也有着较为直接的对应关系。
整体上,中、低并发时,m6g实例(Graviton2,第二代自研ARM芯片实例)性能略微差一些。其他三个规格性能较为接近。在高并发,尤其是超高并发时,m7g实例(Graviton3,第三代自研ARM芯片实例)表现出了更强大扩展性,性能相比于m6g高出约45%左右。
非常明显的,无论是x86还是ARM(Graviton),新一代的实例总是有着更好的性能表现,并且通常新、旧实例价格是差不多的,有时候新一代价格还会更加便宜。所以,选择新一代实例总是可以获得更好的性价比。即m7g几乎全面优于m6g,x6i全面优于m5。虽然这似乎是一个“平凡”的结论,但这里依旧通过benchmark的方式确定了这一点。
此外,从当前的测试来看,在RDS的场景下,依旧是x86规格(对比Graviton/ARM)更加合适。无论是性能还是折算后的性价比,Intel x86规格都是更好的选择,对应的,也就是db.m6i规格是当前Amazon RDS最具性价比的规格。
另外,也注意到,Amazon RDS在前面的“企业级规格”性能对比中,表现的并不算好。尤其是在低并发时,几乎是性能垫底的,这与其在是云计算老大的地位似乎是不符合的。这背后的原因,后续还将再做更多解析。
Google云Cloud SQL(RDS)的性能
谷歌云提供的RDS(在Google云叫Cloud SQL)选项比较简单,主要的选项中,仅有“Enterprise”版和“Enterprise Plus”版,这两个版本最主要的区别是“Plus”版提供了额外的“Data Cache能力”,该能力通过本地的SSD可以加速数据库更多的“冷”数据访问,关于这两个版本的详细说明可以参考之前的文章:Google Cloud SQL for MySQL的”Enterprise”和”Enterprise Plus”版本。根据这篇文章的对比,也注意到Plus的价格也要高出30%左右。这里,我们来看看他们的性能差别。
需要特别提到的是,Enterprise的测试使用的4vCPU16GB的规格,与其他云的测试规格是一致的。但,因为“Enterprise Plus”没有该规格的,于是使用了最为接近的4vCPU32GB规格替代。因为这里的测试,主要瓶颈在于CPU和IO,内存增加的对于性能的影响是有限的。
详细的性能对比参考下图。
可以看到,在低并发时,普通的Enterprise版本性能反而更好。只有在中、高并发时(并发高于24),Enterprise Plus版本才表现更好的性能,最后,在64并发以上的时候,Enterprise Plus性能相比与Enterprise版本,要高出约75%以上。
Azure Database for MySQL(RDS)的性能
微软的MySQL托管服务完整名称叫:“Azure Database for MySQL flexible server”,至于为什么叫“Flexible Server”,可以以参考:Azure数据库的Flexible Server。
微软的Azure云发展要略微晚一些,不过势头是非常猛的,算是后来居上。在最新的Gartner云魔力象限中,凭借其在AI领域的投资与布局,大有全面赶超AWS的趋势。这次,我们也一起来看看Azure托管MySQL的性能如何。
Azure云上购买托管MySQL的选项(与数据库有关的)应该是比较简单的。主要的选型包括,是否需要可用区容灾、IOPS类型选择、Intel还是AMD平台。在本次测试中,选择了US East地区,选择了跨可用区的容灾(Zone redundant),使用预留的IOPS,预留值为3000,使用的Intel的CPU,实例规格为4vCPU16GB内存。规格代码为D4ds_v4。详细的测试性能趋势图如下:
跨云迁移时的性能考虑
注意到,不同的云厂商性能差异是非常大的。例如,在最前面的性能对比图中可以看到,华为云的“企业级规格”性能相当于阿里云或谷歌云的两倍。那么,当考虑数据库在华为云和阿里云之间迁移的时候,则需要结合数据库的业务支撑能力与成本进行综合评估,再开始做迁移规划。
在考虑迁移到阿里云时,除了考虑“企业级规格”的性能外,阿里云还提供了非常丰富的实例类型选择。开发者和企业可以根据不同的业务类型,可以考虑在数据可靠性上做极其轻微的让步,以获得数倍的性能提升。
测试方法说明
这里使用了sysbench的读写混合模型(oltp_read_write)进行测试,单表大小为100万,共十个表,单次测试时长为300秒,分别测试了如下的并发度的性能表现:2、4、8、16、24、32、48、64、96、128。
sysbench oltp_read_write --threads=$conthread --time=$run_time \
--report-interval=3 --percentile=95 --histogram=on \
--table_size=$table_size --tables=$tables run
限制与补充说明
本节对在测试过程中的一些限制进行补充说明,供参考。
*?本次测试,地域选择较为随机,例如阿里云选择了杭州、百度云选择北京、AWS/谷歌云选择了东京、Azure云选择了美东等。这里的一个假设是,各个区域的性能应该是相同或者接近的。
*?限制时间与资源限制,这里仅对较为常用的4vCPU16GB的规格进行测试,单次并发测试持续时间为300秒。
*?虽然都是用MySQL 8.0版本,但是不同的厂商的数据库小版本也会不同。
*?不同厂商的CPU、磁盘类型、价格等各有不同,所以这不是一个完全对等的测试,也不可能是。
*?不同厂商的RDS实例的默认参数模板也各有不同,甚至同一个厂商在不同阶段的参数也可能会有调整。
*?有的云厂商的磁盘存储有着多种不同的选择,例如阿里云支持ESSD PL1/2/3,AWS也支持gp3/io1类型的存储选择,不同的存储选择也会对应这个不同的性能。
*?关于可用区的选择:在测试中,我尽量会将测试的ECS/EC2/VM等与数据库主节点放在同一个可用区。但依旧有一些情况做不到这一点。例如在这次的测试过程中,GCP在东京地区b可用区,虽然可以创建数据库,但是却没有资源创建VM节点(“A n2-highcpu-8 VM instance is currently unavailable in the asia-northeast1-b zone.”)。
虽然,有这些限制,但是笔者依旧认为,非常明显的,这些测试的数据依旧可以给与开发者/企业在做数据库选型时以非常重要的参考。如果有更多建议,可以在本文后,留下你的建议,以供后续参考与改进。
本文转自:orczhou
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!