This content is password protected. To view it please enter your password below:
]]>
根据Wikipeida的信息(参考),杨梅主要分布在中国的东南方地区、日本、菲律宾、朝鲜/韩国等地。在中国,又属浙江特别多,浙江又以仙居杨梅最为有名。
杨梅酸中带甜,非常好吃。但是,杨梅的运输是非常困难的。从树上采摘下来,最佳的食用时间也就是1~3天,再长时间由于水分的流逝,味道就没那么鲜美了。再者,因为杨梅表面非常松软,而如果运输过程稍有颠簸挤压,则非常容易压坏,影响口感,也容易变质。
所以,实际的情况就是,杨梅的上市几乎只有一个月时间,也就是说,每年只有一个月时间,也只在中国的东南方的一些城市能够吃到最好的杨梅。
鲁彦曾经下过一篇散文《故乡的杨梅》,是啊,对于浙江人,身在外地,对于杨梅的怀念,大概就是故乡味道的怀念吧。
前年底,妈妈离开了我们。当时,有几天闲在家里,我就和爸爸说,来年开春,我打算在后院种一颗杨梅树。去年,我们移植了一颗小的杨梅树,大概是因为种植的时候耽搁了几天。杨梅树没能够活下来。今年,我们又移植了一颗,这次的树更大一些,种植的时候我们也更小心,也了解了很多种植的知识,希望这颗杨梅树能够活下来,过几年能够吃上自己种的杨梅树。
对于自己,对于孩子们,也希望让故乡,多一份味道。
--skip_trx=on
,很快在实际的测试中就遇到了Duplicate entry
的报错,详细的报错如下:
[ 105s ] thds: 64 tps: 845.68 qps: 15226.20 (r/w/o: 11833.15/3393.04/0.00) lat (ms,95%): 82.96 err/s: 0.00 reconn/s: 0.00
[ 108s ] thds: 64 tps: 828.65 qps: 14846.32 (r/w/o: 11547.73/3298.59/0.00) lat (ms,95%): 92.42 err/s: 0.00 reconn/s: 0.00
[ 111s ] thds: 64 tps: 811.67 qps: 14705.36 (r/w/o: 11439.69/3265.67/0.00) lat (ms,95%): 92.42 err/s: 0.00 reconn/s: 0.00
FATAL: mysql_drv_query() returned error 1062 (Duplicate entry '172978' for key 'sbtest4.PRIMARY') for query 'INSERT INTO sbtest4 (id, k, c, pad) V
ALUES (172978, 743044, '85734897298-37760631172-31656179599-77290009462-94351507893-97022333300-02606364258-99231394161-86310536236-00514105136',
'50908340877-51595671823-98046322819-52667567569-56801127593')'
FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:488: SQL error, errno = 1062, state = '23000': Duplicate entry '172978' f
or key 'sbtest4.PRIMARY'
也注意到,这个错误的出现有一定的偶发性,但是高并发、长时间压测几乎一定会遇到了(在开启了--skip_trx=on
参数后)。因为Sysbench没有对”Duplicate entry”该错误进行处理,测试会退出,也就无法正常完成测试。
当多个线程并发时,同时没有使用--skip_trx=on
,而是使用MySQL默认的auto commit模式,那么在oltp_read_write
模型下则一定的概率(小概率)会出现如下的场景:
时间线 | 线程A | 线程B |
1 | 生成随机ID X | |
2 | 生成随机ID X | |
3 | 删除 id 为 X 的记录 delete from sbtest where id = X | |
4 | 删除 id 为 X 的记录 delete from sbtest where id = X | |
5 | 写入 id 为 X 的记录 insert into sbtest (id…) values ( X …) | |
6 | 写入 id 为 X 的记录 insert into sbtest (id…) values ( X …) |
在上面的场景下,最后一步,线程B再次写入id 为 X 的记录时,则会出现冲突。
一般来说,即便发生如上情况,也不会出现Duplicate entry
的报错。但,组合一些情况,则会出现。例如,在这里,我们使用了--skip_trx=on
,那么线程A的如上行为不是在一个事务中,每个操作是一个独立的事务,那么就会出现Duplicate entry
报错。
如果没有使用--skip_trx=on
参数,那么在线程2尝试删除记录时,则会遇到锁等待,直到线程1的相关操作全部完成。也就不会出现报错。
在开启了–skip_trx=on之后,如果运行时间足够长,且是多线程并发,则几乎一定会遇到如上错误。可以考虑如下方案避免:
INSERT ... ON DUPLICATE KEY UPDATE
(参考)替换原始的INSERT
语句一般来说,因为当表的记录数非常多时,遇到该类冲突的概率比较小,做如上处理并不会影响测试的“一致性”。
function sysbench.hooks.sql_error_ignorable(err)
if err.sql_errno == 1062 then -- ER_DUP_ENTRY
-- do nothing
-- con:reconnect()
return true
end
end
]]>我们一家人一起去吃了很多次海底捞,还在那里过了一次生日,哥哥如他说所,尴尬得躲到了桌子底下。不过,吃得依旧非常的欢乐。
人生第一次去了西安,这个中国古都。是在咸阳机场落地,然后在雁塔区做了一场关于云数据库架构与选型的分享。之后,去秦岭脚下的西北工大,见到了十几年未见的研究生同学,他的生活还是和在学校时差不多,他们学校的烤鱼味道真的不错。
虽然是江西人,但是这是我们第一次去滕王阁。还有八一纪念馆没有去过、江西省博物馆也没有去过,打算春节期间再去这些地方看看
一家人一起去了黄山,虽然爬山有点累,但是都很开心。看到了传说中的迎客松、猴子观海、天都峰,黄山的松、石确实奇美,古人诚不欺我:参考
今年后院的柚子树,依旧结了很多柚子。不过,柚子树有一根非常重要支干被虫子蛀得非常厉害,老爸虽然已经把这部分清理掉了,不知道明年柚子树是否还能够保持健康。今年结的柚子,水份很足,味道很好。
这一年,经常会在梦中见到妈,妈变得话很少,总是会在远远的地方看着我。每次醒来,都很想回忆起梦中的更多细节,不过,似乎越想去记得清晰,梦中的场景却会变得越模糊。
今年,休假了一次大长假,全家一起去了一趟大西北。看到了似湖似海的青海湖,翻过了葱郁的祁连山,领略了发着金光的岗什卡雪山,经过了杳无人烟的火星公路,见证了石壁上环绕千年敦煌飞天。
终于玩上了《塞尔达传说:王国之泪》:做好了一刀入魂的斩马刀;帮助渔民赶走了海盗,重建了渔村;解决了哈特诺村传统与时尚的矛盾;运送了无数的呀哈哈;帮助搭建了无数的松达家的广告牌;从人马竞技场进货无数…… 唯独,还没有去救公主
一起去了人很多很多很多的黄鹤楼,人真的很多。不过,除了黄鹤楼,武汉还有湖北省博物馆、辛亥革命纪念馆、热干面,都不错
今年,还斥巨资购入了新的相机,佳能R8+RF24-70/F2.8。给拍了很多照片,有家人们、有去过的景点、也有日常生活的记录。右边这张照片,曾被西湖文旅的公众号选中,作为图书馆的宣传照片。哦,今年还去了十次图书馆,希望明年能够去得更多。
元旦,我们还去了上海。去看了四姨家的小宝宝,去了上海天文馆、航海博物馆。
公司的业务,有顺利的一面,也有很有挑战的一面。整体的环境比较困难,内力与招式需要双修,才能适应复杂的外部环境。
今年做了第一次云数据库性能测试,算是给自己挖了一个大坑,希望后续能够持续关注云数据库发展,持续的进行性能测试。
多年的老同事从澳洲回杭州,借机会也把附近的原淘宝DBA的同事聚了起来,多年不见,再次相聚,非常开心
关注我朋友圈的应该知道,在国内自助的注册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主要选项为:
在本次测试中,一共进行了三组测试。规格大小统一为: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来实现高可用、跨可用区数据一致性的。
在MySQL的实例创建过程中,会有一些诸如:AD、FD(Fault Domins)等选项。这是OCI特有的关于区域、可用区等选项。关于区域和可用区的概念,Oracle Cloud与其他云厂商虽然都是相同的概念,但是用了完全不同的名称,也是非常容易让人困惑的。
在Oracle中,分了几层概念:Region->Availability Domains->Fault Domains。
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)
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.00data 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.00data 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
参考
]]>在本次测试与分享中尝试回答如下问题:
开启TLS传输加密之后,分别会在建立连接、数据传输两个阶段对性能造成影响。因为建立连接的过程通常是一次性的,连接会被复用,所以这部分的性能开销通常是可以接受的。在传输阶段,是传输加密对性能影响的重要阶段,这时候通常会使用对称加密算法(例如AES256)对数据进行加密,那么实际的对称加密的性能就是对TLS传输加密性能影响最大的部分。需要注意的是,如果应用使用的是短链接(应该尽量避免使用这种方式),TLS加密的密钥交换阶段也会对每个连接建立的过程都有一定的性能影响。
这里选择对RDS MySQL进行测试,云厂商则各自选择国外、国内Top 1的云厂商AWS和阿里云。
使用sysbench 1.1.0版本,测试类型为oltp_read_write,相关参数如下:
这里选择了mysql.x4.large.2c规格(4c16),MySQL 5.7版本,50GB存储,IOPS 4300,主备均在同一个可用区。
测试中,看到性能影响约为3.5%~6.5%:
测试中,看到性能影响约为4.5%~7.5%:
AWS RDS规格选择了db.m5.xlarge(4c16g),多可用区版本,8.0版本,100GB存储,Provisioned IOPS。
测试中,看到性能影响约为1.5%~3%:
在2014年的IEEE International Conference on Cloud Engineering (IC2E)有一篇论文测试了DynamoDB、Cassandra开启TLS的性能影响:Benchmarking the Performance Impact of Transport Layer Security in Cloud Database Systems,文中的测试,吞吐性能影响分别为5%和9%左右。另外,不同的加密算法选择也会对性能有一定的影响,例如,文中的Cassandra测试中,AES128和AES256约有10%左右的性能差异。
2021年,yugabyteDB的TPC-C测试中,性能约有5%的影响:Measuring the Performance Impact of TLS Encryption Using TPC-C。
整体上,开启传输加密时,对性能的影响约为2%~8%,不同的环境不同的数据库版本会有一些不同。在实际的生产环境中,建议默认打开该功能,应用连接是否需要开启,可以根据实际场景决定。通常,如果Client端和数据库服务器不再同一个网络环境中,则建议Client端启用加密传输。
另外,如果服务端开启TLS加密,但是客户端实际连接中,并没有使用的话,那么对于性能是没有影响的。
]]>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等能够在全球市场一展拳脚。
分析了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。
Gartner数据库魔力象限十年对比
Gartner 云数据库魔力象限,其英文全称为:Magic Quadrant for Cloud Database Management Systems。该报告的核心是其魔力象限图。该图有横纵两个坐标,横坐标是”COMPLETENESS OF VISION”,代表了厂商的”远见/软实力”,或者说是“对领域未来理解判断”,具体的包括市场理解、产品策略、创新能力、商业模式等的理解和策略等。纵坐标是“ABILITY TO EXECUTE”,代表了厂商的“硬实力”,包括产品和服务能力、销售定价、市场响应、客户服务等能力。
更多说明可以参考:数据库魔力象限2022:阿里领先、腾讯再次进入、华为退出文章中的说明。
普通用户可以通过,各个数据库厂商对外公开的页面下载最新的“Gartner云数据库魔力象限”。完整的文档中,包含了更多关于各个厂商优势和缺点的描述,可以作为数据库厂商选型的重要参考。
]]>