• 在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 DocumentationGroup 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(大部分时候为超线程)是明显不同的。

    性能测试的原始数据

    oracle@2024-01-14 Cloud MySQL Performance Testing
    data on 10.0.0.13
    instance configuration
    host : 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 
    
    data on 10.0.0.74
    instance configuration
    host : 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 
    
    data on 10.0.0.224
    instance configuration
    host : 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(中国MySQL用户组)的年度活动中,较为详细对之前的云数据库 RDS MySQL性能测试做了分享。如下为分享的PDF,供参考:

    (more…)
  • 随着云数据库的普及,数据库的传输加密也会随之被广泛使用。本文,将使用通用测试来看看,开启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…)
  • This content is password protected. To view it please enter your password below:

  • 这是一个跨越数年的系列,历史文章参考:

    概述

    Gartner云数据库魔力象限(参考,后面简称MQ)一直是全球数据库领域的年度”锦标赛”,其目标是帮助企业技术决策者选择更加适合的数据库厂商。也因为Gartner的专业与专注,其榜单在各个领域都被众多的企业技术决策者所认可。所以,数据库领域的MQ也就成为了各大厂商年度一场重要的”考试”。放榜了:

    中国数据库厂商:阿里云孤军奋战,虽艰难,但依旧在向前

    Gartner的云数据库魔力象限是一个全球的比较,关注的也是各个厂商在全球是市场的表现。所以,即便中国厂商在中国这个单一市场上做得很好,也无法受到认可。

    在今年的魔力象限中,中国厂商,只剩下阿里云数据库在孤军奋战了。在诸如SAP、IBM、Teradata等一众厂商均跌出领导者象限的背景下,阿里云数据库不仅稳稳的被评为全球领导者,而且其位置相比于去年,无论是横纵坐标均有增强,这是非常了不起的。

    另一方面,也可以注意到,跌出领导者象限的厂商,其对应的云战略通常也是相对失败的,这则是“云计算”是如何重塑数据库领域的具体表现。

    比较遗憾的是,在继去年华为退出魔力象限后,注意到今年腾讯云也退出了该魔力象限。

    在“象限”报告最后的“Honorable Mentions”部分,还提到的中国厂商包括OceanBase、PingCAP/TiDB(总部在Sunnyvale CA,姑且也算是中国厂商吧)、华为云、腾讯云。其中,OceanBase在中国分布式数据库市场有着非常强的表现,包括产品能力、性能以及市场占有率。

    新增分布式关系型数据库厂商

    今年,象限中新增了一个独立的分布式关系型数据库厂商:Yugabyte。在这块市场上,国内厂商包括TiDB、OceanBase,海外有CockroachDB(依旧在象限中),加之今年Aurora Limitless,可以预见这块并不宽敞的赛道上,未来的竞争会更加激烈。换个角度来看,也说明,随着数字化的更加深入,这个赛道似乎有一些转暖的迹象。

    也非常期待,未来TiDB、OceanBase、PolarDB-X、TDSQL、openGauss等能够在全球市场一展拳脚。

    领跑组:Amazon、微软、Oracle、Google

    分析了Garnter十年的魔力象限,从2013年2016年,Oracle和Microsoft一直是“绝对第一梯队”,并保持着统治性的领先。自2017年,Amazon开始进入“绝对第一梯队”,2021年开始Google进入该“梯队”,Oracle虽然依旧保持在梯队中,但位置已经开始有一些相对落后。

    在过去十年中,一直保持在“绝对第一梯队”就是“微软”,实属不易。微软是一家“巨无霸”公司,但是过去十年从企业软件,到云计算,再到AI争夺战,微软都是其中的“弄潮儿”。在数据库领域,微软有老牌数据库SQL Server,云上是SQL Database;还是自研的多模数据库Cosmos DB,以及托管数据库系列Azure Database。

    Oracle依旧拥有这最强的数据库产品Oracle数据库,以及最流行的开源数据库MySQL。但受限于其在云计算市场现状,很多企业在选择数据库时,会同时考虑云平台的集成度,这也让Oracle感受到了巨大的危机。

    Google是云计算的“后来居上者”。Google通过开放的策略,在云计算领域在逐步赶超对手。他的“开放”包括:面相生态的开放;以及面向其他所有云的开放。例如,Google云提供的一方托管数据库产品种类应该是最少的,Google鼓励用户使用第三方厂商基于Google云构建的服务(例如MongoDB等),而不是全部都由Google一方提供;再比如Google通过BigLake服务很好的兼容不同的云平台与环境,无论企业的数据在哪里,Google都提供了非常好兼容性,最终帮助用户使用Google云平台的分析服务构建自己的Lakehouse。

    其他

    • TigerGraph 去年昙花一现后,今年也退出了魔力象限。
    • 在今年,IBM/SAP/Teradata/Cloudera“组团”跌入远见者象限,如果从更长时间的尺度去看,每个时代都有每个时代都有时代的特点,在“云计算”时代,没能够踩对节奏,就会在市场上遇到挑战。如果未来十年是AI的时代,谁会成为新的弄潮儿,也让人期待。
    • MongoDB、Snowflake、DataBricks位置较为稳定,Snowflake在纵坐标的相对位置有所下降,这可能是其市场占有率被更多厂商在挑战的表现。
    • EDB再次回到“象限”中,EDB提供基于PostgreSQL的Oracle兼容版,同时提供增强的PostgreSQL版本。随着,最近几年PostgreSQL的回暖

    过去十年对比参考

    Gartner数据库魔力象限十年对比

    关于Gartner云数据库魔力象限

    Gartner 云数据库魔力象限,其英文全称为:Magic Quadrant™ for Cloud Database Management Systems。该报告的核心是其魔力象限图。该图有横纵两个坐标,横坐标是”COMPLETENESS OF VISION”,代表了厂商的”远见/软实力”,或者说是“对领域未来理解判断”,具体的包括市场理解、产品策略、创新能力、商业模式等的理解和策略等。纵坐标是“ABILITY TO EXECUTE”,代表了厂商的“硬实力”,包括产品和服务能力、销售定价、市场响应、客户服务等能力。

    • 如果横纵坐标”双高”(软硬皆强)那么就是在第一象限,也就是“领导者
    • “如果”软实例”很强,则会落在第四象限,被称为”VISIONARIES”,译为”远见者”
    • 如果”硬实力”很强,则会落在第二象限,被称为”CHALLENGERS”,译为”挑战者”
    • 如果”软硬”都相对不算强(注意,这里是”相对”,因为进入了该象限都已经是全球范围内都有竞争力的选手了),那么则落在第三象限,被称为”NICHE PLAYERS”,译作”特定领域者”,这个翻译不是很好理解,其意思有两方面一个是,在某个特定的领域非常强,另外,就是,软实力和硬实力都还相对不算强。不用太纠结翻译

    更多说明可以参考:数据库魔力象限2022:阿里领先、腾讯再次进入、华为退出文章中的说明。

    最后

    普通用户可以通过,各个数据库厂商对外公开的页面下载最新的“Gartner云数据库魔力象限”。完整的文档中,包含了更多关于各个厂商优势和缺点的描述,可以作为数据库厂商选型的重要参考。

  • 测试说明

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

    云数据库(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…)