orczhou.com

Cloud MySQL Performance Benchmark

Posts of Cloud MySQL Performance Benchmark

  • Oracle Cloud上的MySQL性能测试

    ·

    admin

    本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。

    在MySQL社区的帮助下，终于成功开通了Oracle Cloud，于是，第一时间测试了一下在Oracle Cloud上托管MySQL，看看Oracle MySQL原厂的性能表现如何。

    关注我朋友圈的应该知道，在国内自助的注册Oracle Cloud真的非常不容易。所以，特别感谢Oracle MySQL原厂工程师徐轶韬的帮助，他也是《MySQL高可用解决方案-从主从复制到InnoDB Cluster架构》的作者，他的公众号是“MySQL解决方案工程师”，感兴趣可以关注他的公众号。

    回到正文，Oracle Cloud的全称是”Oracle Cloud Infrastructure”，也经常被简称为”OCI”。在OCI上提供的MySQL服务，相较于AWS、阿里云来说，产品形态也比较简单。首先，托管MySQL在分类“Databases->MySQL HeatWave->DB Systems”这个类目下，在实例创建过程中，涉及的选项不算多，但是因为名词/定义与其他云厂商有一些不同，所以这里做一些解释。Oracle Cloud上的托管MySQL主要选项为：

    • 高可用类型（单节点/standalone、三节点/HA）
    • 规格大小
    • 主可用区选择
    • 空间大小（IOPS/吞吐量与此相关）

    在本次测试中，一共进行了三组测试。规格大小统一为：2 OCPU（Oracle CPU）32GB，100GB存储（对应的7500 IOPS），规格代码为MySQL.VM.Standard.E4.2.32GB。三组测试对比项分别为：单节点 vs 三节点和同可用区 vs 跨可用区。三组测试具体为：跨可用区的三节点测试、同可用区的三节点测试、同可用区的单节点测试。详细参数表如下：

    整体性能趋势图

    整体上，OCI上的MySQL高可用版本（MGR三节点）性能要比单节点低约20%。在三节点的两次测试下，跨可用区与同可用区有着几乎相同的性能表现，从延迟上来看，也非常接近，可用区之间的延迟约为百微秒级别。

    相比于其他云厂商，OCI上的MySQL性能表现，并不算高的。从架构层面，Oracle MySQL是唯一一个选择了MGR来实现高可用、跨可用区数据一致性的。

    OCI上的区域与可用区

    在MySQL的实例创建过程中，会有一些诸如：AD、FD（Fault Domins）等选项。这是OCI特有的关于区域、可用区等选项。关于区域和可用区的概念，Oracle Cloud与其他云厂商虽然都是相同的概念，但是用了完全不同的名称，也是非常容易让人困惑的。

    在Oracle中，分了几层概念：Region->Availability Domains->Fault Domains。

    • Region与其他云厂商区域概念相同；
    • Fault Domains则与其他云厂商的“可用区”对应；
    • 在OCI中，通常三个为一组的Fault Domains会组成一个“Availability Domains”。大部分的Oracle Region中只有一个Availability Domains，也有部分region有3个Availability Domains（参考），所以在MySQL的配置选项中会有AD、FD等缩写词语。

    Oracle Cloud上MySQL实例的数据可靠性架构

    OCI上的MySQL使用的MGR来实现高可用、高可靠（参考：High Availability@Oracle Cloud Infrastructure Documentation、Group Replication@MySQL Documentation）。三个不同的MySQL节点分布在三个不同的FD，每个节点使用的存储是OCI上的Block Volume（参考），以iSCSI方式使用，类型是“Higher Performance”（此外，还有Balanced、Ultra High Performance、Lower Cost三种Block Volume）。

    根据参数配置来看，Oracle Cloud提供的MySQL三节点是通过MGR实现的，使用的是group_replication_single_primary_mode模式。

    mysql> show variables like '%group_replication_single_primary_mode%';
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| group_replication_single_primary_mode | ON    |
+---------------------------------------+-------+
1 row in set (0.00 sec)

    其他说明

    • Oracle Cloud的MySQL没有提供两节点选项
    • 产品规格，Oracle Cloud使用的是OCPUs（Oracle CPU，可以理解为core），详细参考：vCPU and OCPU pricing information。相比于其他云厂商的vCPU（大部分时候为超线程）是明显不同的。

    性能测试的原始数据

    2024-01-14@MySQL at Oracle Cloud Benchmark
    host : 10.0.0.13 
sub_dir : 10.0.0.13 
ins_code : MySQL.VM.Standard.E4.2.32GB 
ha_type : ha 
same_az : 1 
region : tokyo 
storage_size : 100 

    sysbench for host :10.0.0.13
threads|transactions| queries| time |avg/Latency|95%/Latency
      2|       95033| 1900660|300.01|       6.31|       7.56 
      4|      148751| 2975020|300.01|       8.07|      10.27 
      8|      214974| 4299480|300.01|      11.16|      13.70 
     16|      262105| 5242100|300.01|      18.31|      30.81 
     24|      253583| 5071660|300.03|      28.39|      47.47 
     32|      272755| 5455100|300.03|      35.20|      54.83 
     48|      269370| 5387400|300.04|      53.46|      77.19 
     64|      286891| 5737820|300.06|      66.93|     102.97 
     96|      276749| 5534980|300.12|     104.08|     161.51 
    128|      287452| 5749040|300.13|     133.61|     183.21 
    192|           0|       0|  0.00|       0.00|       0.00 

    host : 10.0.0.74 
sub_dir : 10.0.0.74 
ins_code : MySQL.VM.Standard.E4.2.32GB 
ha_type : ha 
same_az :  
region : tokyo 
storage_size : 100 

    sysbench for host :10.0.0.74
threads|transactions| queries| time |avg/Latency|95%/Latency
      2|       90638| 1812760|300.01|       6.62|       7.84 
      4|      147270| 2945400|300.01|       8.15|      10.09 
      8|      215078| 4301560|300.01|      11.16|      13.70 
     16|      242713| 4854260|300.02|      19.78|      33.72 
     24|      260072| 5201440|300.02|      27.68|      45.79 
     32|      273703| 5474060|300.03|      35.07|      56.84 
     48|      283811| 5676220|300.06|      50.74|      73.13 
     64|      287176| 5743520|300.06|      66.86|     102.97 
     96|      283113| 5662260|300.09|     101.74|     158.63 
    128|      285210| 5704200|300.12|     134.66|     189.93 
    192|           0|       0|  0.00|       0.00|       0.00 

    host : 10.0.0.224 
sub_dir : 10.0.0.224 
ins_code : MySQL.VM.Standard.E4.2.32GB 
ha_type : standalone 
same_az : 1 
region : tokyo 
storage_size : 100 

    sysbench for host :10.0.0.224
threads|transactions| queries| time |avg/Latency|95%/Latency
      2|      102033| 2040660|300.00|       5.88|       7.56 
      4|      186602| 3732040|300.01|       6.43|       8.90 
      8|      281464| 5629280|300.01|       8.53|      12.30 
     16|      333418| 6668360|300.02|      14.40|      31.94 
     24|      345463| 6909260|300.02|      20.84|      47.47 
     32|      359902| 7198040|300.03|      26.67|      56.84 
     48|      353246| 7064920|300.06|      40.77|      78.60 
     64|      370118| 7402360|300.07|      51.88|      99.33 
     96|      380647| 7612940|300.09|      75.67|     134.90 
    128|      372683| 7453660|300.12|     103.05|     164.45 
    192|           0|       0|  0.00|       0.00|       0.00

    参考

    1. High Availability@Oracle Cloud Infrastructure Documentation
    2. Group Replication@MySQL Documentation
    3. vCPU and OCPU pricing information

  • ACMUG分享《云数据库(RDS MySQL)性能深度测评与对比》

    ·

    admin

    最近，在ACMUG（中国MySQL用户组）的年度活动中，较为详细对之前的云数据库 RDS MySQL性能测试做了分享。如下为分享的PDF，供参考：

    (more…)

  • 启用TLS传输加密对数据库性能的影响

    ·

    admin

    随着云数据库的普及，数据库的传输加密也会随之被广泛使用。本文，将使用通用测试来看看，开启TLS传输对数据库的性能有什么样的影响。

    1. 原理概述

    开启TLS传输加密之后，分别会在建立连接、数据传输两个阶段对性能造成影响。因为建立连接的过程通常是一次性的，连接会被复用，所以这部分的性能开销通常是可以接受的。在传输阶段，是传输加密对性能影响的重要阶段，这时候通常会使用对称加密算法（例如AES256）对数据进行加密，那么实际的对称加密的性能就是对TLS传输加密性能影响最大的部分。需要注意的是，如果应用使用的是短链接（应该尽量避免使用这种方式），TLS加密的密钥交换阶段也会对每个连接建立的过程都有一定的性能影响。

    2. 云数据库实际测试

    这里选择对RDS MySQL进行测试，云厂商则各自选择国外、国内Top 1的云厂商AWS和阿里云。

    2.1 测试方法说明

    使用sysbench 1.1.0版本，测试类型为oltp_read_write，相关参数如下：

    • –mysql-ssl=REQUIRED 是否使用TLS加密传输
    • –percentile=95 关注95%Query的延迟
    • –histogram=on 可以查看延迟分布情况
    • –time=600 sysbench运行的总时间（秒）
    • –warmup-time=60 开始计算性能前预热时间（秒）
    • –table_size=1000000 单表100万条记录
    • –tables=5 共测试5个表
    (more…)

  • 磁盘类型选择对阿里云RDS MySQL的性能影响

    ·

    admin

    本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。

    测试说明

    这是一个云数据库性能测试系列，旨在通过简单标准的性能测试，帮助开发者、企业了解云数据库的性能，以选择适合的规格与类型。这个系列还包括：

    * 云数据库(RDS MySQL)性能深度测评与对比

    * 阿里云RDS标准版(x86) vs 经济版(ARM)性能对比

    * 华为云RDS通用型(x86) vs 鲲鹏(ARM)架构的性能对比

    * AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比（二）

    * AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比

    阿里云RDS存储类型概述

    阿里云RDS提供了较为丰富的存储类型选择，包括ESSD PL0、ESSD PL1、ESSD PL2、ESSD PL3、通用云盘、本地SSD。其中ESSD PL0仅在非常小的经济型规格中提供，并不在测试范围内。根据阿里云的官方文档可以看到，从PL0到PL3，性能越来越强，并且IO能力也越来越稳定（详细参考：ESSD云盘@阿里云文档中心），当然价格也越来越贵。这里摘抄了文档中的描述，以及关键的部分，对比如下：

    此外，“通用云盘”的说明可以参考阿里云文档描述：“通用云盘兼容ESSD云盘的所有特性，性能与ESSD PL1云盘相同，在ESSD云盘的基础上提供了IO突发能力。” 所以，可以这样理解，通用云盘是一种具备ESSD PL1能力，同时具备更加灵活的IOPS突发增长能力的云盘。突发IOPS部分，将额外计费（有少部分的免费额度），突发IOPS部分的额外费用为：0.02元/万IO。

    不同存储类型的性能趋势对比

    那么，我们看看在RDS MySQL中这些不同的存储的性能表现。这里依旧选择了“企业级规格”进行比较（企业级规格的定义可以参考：云数据库(RDS MySQL)性能深度测评与对比），详细的性能如下：

    可以看到：

    • 对于几种云盘的存储，RDS表现出了较为一致的性能，即，使用更好的存储的RDS总是能够获得了更好的性能：ESSD PL3 > ESSD PL2 > 通用存储 >> ESSD PL1
    • 本地SSD，性能则是最差的存储，相较于ESSD PL1要低9%；相较于性能最好的ESSD PL3则要低18.7%
    • 不过，相较于ESSD PL1/2/3之间成倍的价格增长，从这里的测试性能并没有展示出那么大的差距
    (more…)

  • 云数据库(RDS MySQL)性能深度测评与对比@2023年12月

    ·

    admin

    本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。

    一直都在非常深度调研、关注和使用云数据库，其中性能是关注的重点之一。一方面性能是最终成本的重要影响因素，更好的性能，通常意味着使用更少的资源支撑更高的业务量，从而降低整体成本。另外，性能还意味着在极端场景下，数据库的上限支撑能力。

    所以，近期对各个云数据库厂商做了一个较为系统的性能对比，供开发者和企业在云数据库选型时的参考。

    总览：云数据库性能对比

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

    可以看到：

    • 华为云数据库（红色），在中高并发度时（>=16），性能最强，且高于第二名约18%；
    • 腾讯云数据库（紫色），在低并发时（<=8），性能最强，高于第二名约15%；
    • 百度云数据库（淡蓝色），在中高并发时（>16），性能跃居第二，仅次于华为云；
    • 阿里云数据库（黄色）和谷歌云数据库（绿色）在低并发时也都有不错的表现，高并发之后性能则持续稳定在850 tps。这两家云数据库的响应延迟，表现得也非常接近。
    • 亚马逊云数据库（Amazon RDS，蓝色）和微软Azure云在中低并发时，表现出了较为相近的性能趋势，且性能较低。但是在高并发时，两者都表现出了非常强的扩展性，AWS RDS在96和128并发时，性能超过阿里云、腾讯云、谷歌云等，跃居第三；同样的，微软Azure云的数据库在高并发时也超过了阿里云、谷歌云，也有不错的性能表现。
    (more…)

  • AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比（二）

    ·

    admin

    本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。

    这是一个云数据库性能的系列文章，包含了：

    在前篇中（参考），较为详细的对比x86和Graviton 2（AWS推出第二代ARM芯片）的性能。Graviton 3实例在今年的4月份支持了RDS数据库（参考）。这里，我们再系统的看看m7g实例（Graviton 3）、m6g实例（Graviton 2）、m5实例（Intel Xeon）、m6i实例（第三代Intel Xeon/Ice Lake）的RDS性能（包括性价比）表现如何。

    测试结论

    参考下图。整体上，在中低并发时，m6i实例（第三代Intel Xeon/Ice Lake）、m5实例（Intel Xeon）性能要比m7g实例（Graviton 3）、m6i实例（第三代Intel Xeon/Ice Lake）实例要略微高一些。即，低并发时，x86实例性能要高出约10%。

    在超高并发的时候性能表现：m7g实例 > m6i实例 > m6g实例 ~ m5实例。在超高并发下，m7g、m6i实例表现出了非常强的扩展性和吞吐量，m7g实例吞吐量最高，甚至高出m6i实例10%；相比m6g、m5实例，m7g实例性能则要高出30%。

    为了更加直观对比性价比，这里选取了16并发的性能进行对比。m7g实例在16并发下，tps为314，价格为$0.936/小时；m6i实例的tps为336，价格为$0.94/小时。所以，m6i实例（x86）性价比要比m7g实例（Graviton 3）更高，高出约：6%。在超高并发时（128并发），m7g实例（Graviton 3）实例性价比才比m6i实例（x86）要更高，高出约：10%。不过，无论怎样，这与AWS宣称的Graviton实例性价比更高的结论是不一致的。

    测试模型说明

    这里使用了sysbench的读写混合模型（oltp_read_write）进行测试，单表大小为100万，共十个表，单次测试时长为300秒，分别测试了如下的并发度的性能表现：2 4 8 16 24 32 48 64 96 128。

    实例配置与价格

    这里关注db.m7g.xlarge、db.m6i.xlarge实例价格，m6g、m5实例的价格可以参考前篇。以东京地区、多可用区实例价格为参考：

    实例配置与之前的测试保持一致。选择了较为常用4c16gb的实例进行测试，各个选项尽量选择默认选项，以更加接近的模拟用户实际场景，具体的，版本是AWS多可用区版、存储默认加密、gp3存储、100GB空间、3000 IOPS、Performance Insight也默认开启。

    详细的测试数据参考

    AWS RDS Graviton 3（db.m7g.xlarge/gp3/100gb/3000iops)

    threads|transactions| queries| time |avg/Latency|95%/Latency
2|       10847|  216940|300.04|      55.32|     127.81
4|       25897|  517940|300.00|      46.34|      51.94
8|       49010|  980200|300.05|      48.97|      55.82
16|       94335| 1886700|300.05|      50.89|      58.92
24|      141987| 2839740|300.05|      50.71|      59.99
32|      185996| 3719920|300.05|      51.62|      62.19
48|      268264| 5365280|300.05|      53.68|      68.05
64|      341468| 6829360|300.06|      56.23|      74.46
96|      446113| 8922260|300.06|      64.56|      92.42
128|      491663| 9833260|300.09|      78.11|     121.0

    AWS RDS x86（第三代Intel Xeon/Ice Lake）（db.m6i.xlarge/gp3/100gb/3000iops)

    threads|transactions| queries| time |avg/Latency|95%/Latency
2|       13281|  265620|300.02|      45.18|     112.67
4|       29635|  592700|300.04|      40.49|      47.47
8|       53875| 1077500|300.04|      44.55|      53.85
16|      100785| 2015700|300.07|      47.63|      57.87
24|      150515| 3010300|300.04|      47.84|      59.99
32|      193195| 3863900|300.05|      49.69|      63.32
48|      273454| 5469080|300.08|      52.67|      69.29
64|      343939| 6878780|300.05|      55.83|      75.82
96|      408551| 8171020|300.09|      70.50|      99.33
128|      438708| 8774160|300.06|      87.54|     123.28

    小结

    经过较为详细的测试，可以看到，在RDS数据库的场景下，无论是第二代自研芯片Graviton2，还是第三代Graviton3，相比于x86芯片在性价比上并没有特别明显的优势。而在更加常见的低并发的场景下，x86实例的性价比依旧是更高的。在超高并发时，Graviton3实例虽然表现出了一些性价比优势，但是，如此高的并发，其实在实际应用中，并不常见。

    另外，第三代Graviton3相比第二代Graviton2的性能提升也是非常明显，大概有10~40%的性能提升。

    当然，这应该也是符合预期的结论，毕竟在大原则上，处理复杂的负载x86芯片应该更有优势；对简单的场景、更低功耗的场景，Graviton（ARM）芯片是更有优势的。对于数据库来说，涉及到事务处理、磁盘IO、大量的比较判断等，还是比较复杂的。不过，依旧期待未来，Graviton做更多的适配与正对性的优化，以获得更高的性价比，从而降低最终降低使用RDS的成本。

    参考