云数据库性能深度测评与对比

总览：云数据库性能对比

在进行大量测试之后，对主要的云厂商分别选择了一个“企业级规格”（适合生产环境配置的）进行了对比。性能对比如下图：

可以看到：

• 华为云数据库（红色），在中高并发度时（>=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.”）。

虽然，有这些限制，但是笔者依旧认为，非常明显的，这些测试的数据依旧可以给与开发者/企业在做数据库选型时以非常重要的参考。如果有更多建议，可以在本文后，留下你的建议，以供后续参考与改进。