orczhou.com – Page 3

过去的2023年

2024-02-09

我们一家人一起去吃了很多次海底捞，还在那里过了一次生日，哥哥如他说所，尴尬得躲到了桌子底下。不过，吃得依旧非常的欢乐。

人生第一次去了西安，这个中国古都。是在咸阳机场落地，然后在雁塔区做了一场关于云数据库架构与选型的分享。之后，去秦岭脚下的西北工大，见到了十几年未见的研究生同学，他的生活还是和在学校时差不多，他们学校的烤鱼味道真的不错。

虽然是江西人，但是这是我们第一次去滕王阁。还有八一纪念馆没有去过、江西省博物馆也没有去过，打算春节期间再去这些地方看看

一家人一起去了黄山，虽然爬山有点累，但是都很开心。看到了传说中的迎客松、猴子观海、天都峰，黄山的松、石确实奇美，古人诚不欺我：参考

今年后院的柚子树，依旧结了很多柚子。不过，柚子树有一根非常重要支干被虫子蛀得非常厉害，老爸虽然已经把这部分清理掉了，不知道明年柚子树是否还能够保持健康。今年结的柚子，水份很足，味道很好。

这一年，经常会在梦中见到妈，妈变得话很少，总是会在远远的地方看着我。每次醒来，都很想回忆起梦中的更多细节，不过，似乎越想去记得清晰，梦中的场景却会变得越模糊。

今年，休假了一次大长假，全家一起去了一趟大西北。看到了似湖似海的青海湖，翻过了葱郁的祁连山，领略了发着金光的岗什卡雪山，经过了杳无人烟的火星公路，见证了石壁上环绕千年敦煌飞天。

终于玩上了《塞尔达传说：王国之泪》：做好了一刀入魂的斩马刀；帮助渔民赶走了海盗，重建了渔村；解决了哈特诺村传统与时尚的矛盾；运送了无数的呀哈哈；帮助搭建了无数的松达家的广告牌；从人马竞技场进货无数…… 唯独，还没有去救公主

一起去了人很多很多很多的黄鹤楼，人真的很多。不过，除了黄鹤楼，武汉还有湖北省博物馆、辛亥革命纪念馆、热干面，都不错

今年，还斥巨资购入了新的相机，佳能R8+RF24-70/F2.8。给拍了很多照片，有家人们、有去过的景点、也有日常生活的记录。右边这张照片，曾被西湖文旅的公众号选中，作为图书馆的宣传照片。哦，今年还去了十次图书馆，希望明年能够去得更多。

元旦，我们还去了上海。去看了四姨家的小宝宝，去了上海天文馆、航海博物馆。

公司的业务，有顺利的一面，也有很有挑战的一面。整体的环境比较困难，内力与招式需要双修，才能适应复杂的外部环境。

今年做了第一次云数据库性能测试，算是给自己挖了一个大坑，希望后续能够持续关注云数据库发展，持续的进行性能测试。

多年的老同事从澳洲回杭州，借机会也把附近的原淘宝DBA的同事聚了起来，多年不见，再次相聚，非常开心

Oracle Cloud上的MySQL性能测试

2024-01-26

本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的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

data on 10.0.0.13

instance configuration
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

data on 10.0.0.74

instance configuration
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

data on 10.0.0.224

instance configuration
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

参考

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

2024-01-22

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

(more…)

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

2024-01-19

随着云数据库的普及，数据库的传输加密也会随之被广泛使用。本文，将使用通用测试来看看，开启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…)

Protected: 男孩节，写给成长中的周陌

2023-12-28

Gartner 2023数据库魔力象限发布，阿里云数据库连续成为领导者

2023-12-22

这是一个跨越数年的系列，历史文章参考：

概述

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云数据库魔力象限”。完整的文档中，包含了更多关于各个厂商优势和缺点的描述，可以作为数据库厂商选型的重要参考。