简单生活
-
2024年的期待
·
今天是元宵节，姑且还算是春节期间吧，做个总结和展望吧，虽然有点晚。
- 海拉鲁大陆已经被探索的差不多了，考虑新开一个游戏系列，有什么推荐的吗？《艾尔登法环》、《博德之门 3》？
- 考虑和家人们一起更多的探索中国、或者国外的一些地方
- 随着大模型的流行，以及文字内容日渐不受关注，老实说，写博客的动力越来越不足了，是不是考虑把博客转换成视频呢？
- 把云数据库性能测试持续做下去，2024年计划再测三次
- 希望把体重能够控制在130以内，这个目标非常不容易
- 拍更多的照片，家人们的，以及看到的风景的
- 祝愿TH000早日康复，挺喜欢看他的直播
- 还有几部电视剧/电影，也计划看掉：
- 三体（Netflix）、
- 庆余年2（这是一个“爽”剧）、
- 真探第四季（HBO）
- 猩球崛起4：新世界 Kingdom of the Planet of the Apes (2024)，虽然前面三部，一部比一部差…
- 变形金刚：初代 Transformers One
- 和同事们一起把产品做得更好，同时也探索出可持续的、高效的商业模式
-
过去的2023年
·
我们一家人一起去吃了很多次海底捞，还在那里过了一次生日，哥哥如他说所，尴尬得躲到了桌子底下。不过，吃得依旧非常的欢乐。
人生第一次去了西安，这个中国古都。是在咸阳机场落地，然后在雁塔区做了一场关于云数据库架构与选型的分享。之后，去秦岭脚下的西北工大，见到了十几年未见的研究生同学，他的生活还是和在学校时差不多，他们学校的烤鱼味道真的不错。
虽然是江西人，但是这是我们第一次去滕王阁。还有八一纪念馆没有去过、江西省博物馆也没有去过，打算春节期间再去这些地方看看
一家人一起去了黄山，虽然爬山有点累，但是都很开心。看到了传说中的迎客松、猴子观海、天都峰，黄山的松、石确实奇美，古人诚不欺我：参考
今年后院的柚子树，依旧结了很多柚子。不过，柚子树有一根非常重要支干被虫子蛀得非常厉害，老爸虽然已经把这部分清理掉了，不知道明年柚子树是否还能够保持健康。今年结的柚子，水份很足，味道很好。
这一年，经常会在梦中见到妈，妈变得话很少，总是会在远远的地方看着我。每次醒来，都很想回忆起梦中的更多细节，不过，似乎越想去记得清晰，梦中的场景却会变得越模糊。
爸妈年轻时候的样子 
今年，休假了一次大长假，全家一起去了一趟大西北。看到了似湖似海的青海湖，翻过了葱郁的祁连山，领略了发着金光的岗什卡雪山，经过了杳无人烟的火星公路，见证了石壁上环绕千年敦煌飞天。
终于玩上了《塞尔达传说：王国之泪》：做好了一刀入魂的斩马刀；帮助渔民赶走了海盗，重建了渔村；解决了哈特诺村传统与时尚的矛盾；运送了无数的呀哈哈；帮助搭建了无数的松达家的广告牌；从人马竞技场进货无数…… 唯独，还没有去救公主
一起去了人很多很多很多的黄鹤楼，人真的很多。不过，除了黄鹤楼，武汉还有湖北省博物馆、辛亥革命纪念馆、热干面，都不错
今年，还斥巨资购入了新的相机，佳能R8+RF24-70/F2.8。给拍了很多照片，有家人们、有去过的景点、也有日常生活的记录。右边这张照片，曾被西湖文旅的公众号选中，作为图书馆的宣传照片。哦，今年还去了十次图书馆，希望明年能够去得更多。
元旦，我们还去了上海。去看了四姨家的小宝宝，去了上海天文馆、航海博物馆。
公司的业务，有顺利的一面，也有很有挑战的一面。整体的环境比较困难，内力与招式需要双修，才能适应复杂的外部环境。
今年做了第一次云数据库性能测试，算是给自己挖了一个大坑，希望后续能够持续关注云数据库发展，持续的进行性能测试。
多年的老同事从澳洲回杭州，借机会也把附近的原淘宝DBA的同事聚了起来，多年不见，再次相聚，非常开心
-
本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。
一直都在非常深度调研、关注和使用云数据库，其中性能是关注的重点之一。一方面性能是最终成本的重要影响因素，更好的性能，通常意味着使用更少的资源支撑更高的业务量，从而降低整体成本。另外，性能还意味着在极端场景下，数据库的上限支撑能力。
所以，近期对各个云数据库厂商做了一个较为系统的性能对比，供开发者和企业在云数据库选型时的参考。
总览：云数据库性能对比
在进行大量测试之后，对主要的云厂商分别选择了一个“企业级规格”（适合生产环境配置的）进行了对比。先看性能对比如下图：
可以看到：
- 华为云数据库（红色），在中高并发度时（>=16），性能最强，且高于第二名约18%；
- 腾讯云数据库（紫色），在低并发时（<=8），性能最强，高于第二名约15%；
- 百度云数据库（淡蓝色），在中高并发时（>16），性能跃居第二，仅次于华为云；
- 阿里云数据库（黄色）和谷歌云数据库（绿色）在低并发时也都有不错的表现，高并发之后性能则持续稳定在850 tps。这两家云数据库的响应延迟，表现得也非常接近。
- 亚马逊云数据库（Amazon RDS，蓝色）和微软Azure云在中低并发时，表现出了较为相近的性能趋势，且性能较低。但是在高并发时，两者都表现出了非常强的扩展性，AWS RDS在96和128并发时，性能超过阿里云、腾讯云、谷歌云等，跃居第三；同样的，微软Azure云的数据库在高并发时也超过了阿里云、谷歌云，也有不错的性能表现。
-
本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。
这是一个云数据库性能的系列文章，包含了：
- 阿里云RDS标准版(x86) vs 经济版(ARM)性能对比
- 华为云RDS通用型(x86) vs 鲲鹏(ARM)架构的性能对比
- AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比
- AWS基于x86 vs Graviton(ARM)的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.0AWS 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的成本。
参考
-
本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。
概述
在2018年，AWS首次推出Graviton EC2实例，2020年7月AWS RDS正式支持Graviton 2的实例，就在前两天，在最新的AWS re:Invent大会上，AWS已经推出了第四代Graviton 4实例。现在，AWS的Graviton已经较为成熟，也在大量的企业和应用被广泛使用。AWS官方也宣称使用Graviton 2的RDS实例能够有52%的性价比提升（参考）。这里，来通过标准的Sysbench测试来实测一下，看看实际Graviton 2实例的效果。
与上次阿里云测试相同，这次依旧是使用了同样的测试工具和场景，对较为常用的4c16gb，即db.m6g.xlarge和db.m5.xlarge实例，进行并发数分别为
2 4 8 16 24 32 48 64 96 128的测试。测试结论
在性能上，平均来看，x86要比Graviton实例性能高约12.7%；x86规格延迟要比Graviton规格低15%。也注意到，在超高并发的情况下（并发超过96时），Graviton实例与x86实例无论是在性能，还是延迟上，是比较接近的，不过，这时候系统压力太大、延迟太高，对实际使用并没有太大的参考价值。
为了更加直观的做性价比的比较，这里选取16并发时的数据进行对比。在16并发下，Graviton实例的TPS是275，db.m6g.xlarge价格是$0.836/小时；x86实例的TPS是341，价格是$0.94/小时。那么每100TPS，Graviton价格是0.304，x86是0.275。所以，在16并发时，相比之下，x86规格的性价比更高，高出Graviton实例10%。这个结果与测试之前预期还是非常不一样的，也与AWS宣称的完全不同。
只有在超高的并发情况下（96/128并发），Graviton实例的吞吐量才与x86接近，这时，Graviton实例才表现出接近10%的性价比优势。但这种高并发在实际场景中并不是常态，所以并没有很强的参考价值。
这个测试结果与预期的差别比较大，所以后来又再做过一次测试，结果与这次基本相同。所以，性能到底怎样，还是最终要自己实际测试，因为宣传的数据，通常都是非常极端的适配该产品的场景，并不是真实的场景。
一下两幅图分别是TPS和平均延迟的对比图：
横坐标是sysbench的并发线程数，纵坐标分别为tps和平均的延迟。
测试模型说明
这里使用了sysbench的读写混合模型（oltp_read_write）进行测试，单表大小为100万，共十个表，单次测试时长为300秒，分别测试了如下的并发度的性能表现：
2、4、8、10、12、14、16、24、32。实例配置与价格
这里选择了较为常用4c16gb的实例进行测试，各个选项尽量选择默认选项，以更加接近的模拟用户实际场景，具体的，版本是AWS默认的8.0.33、多可用区版、存储默认加密、gp3存储、100GB空间、3000 IOPS、Performance Insight也默认开启。完整的选项参考如下：
AWS的价格分为计算节点价格（CPU与内存）、存储价格、IOPS价格，这里仅关注计算节点价格。存储和IOPS对于ARM和x86实例来说，是相同的。这里的选择的是东京地区、多可用区实例的价格，如下：
后续，也还将测试基于 io1（Provisioned IOPS SSD） 存储的RDS。
详细测试数据参考
AWS RDS Graviton（db.m6g.xlarge/gp3/100gb/3000iops/8.0.33)
threads|transactions| queries| time |avg/Latency|95%/Latency 2| 11951| 239020|300.03| 50.21| 55.82 4| 23322| 466440|300.04| 51.45| 57.87 8| 43654| 873080|300.05| 54.98| 65.65 16| 82519| 1650380|300.05| 58.17| 70.55 24| 120541| 2410820|300.06| 59.74| 73.13 32| 156680| 3133600|300.07| 61.28| 74.46 48| 218709| 4374180|300.06| 65.85| 81.48 64| 269430| 5388600|300.08| 71.27| 90.78 96| 329366| 6587320|300.07| 87.45| 121.08 128| 351579| 7031580|300.11| 109.24| 164.45AWS x86实例（db.m5.xlarge/gp3/100gb/3000iops/8.0.33）
threads|transactions| queries| time |avg/Latency|95%/Latency 2| 13357| 267140|300.03| 44.92| 112.67 4| 27539| 550780|300.03| 43.57| 50.11 8| 55330| 1106600|300.04| 43.38| 51.94 16| 102408| 2048160|300.05| 46.87| 56.84 24| 145718| 2914360|300.05| 49.41| 61.08 32| 186619| 3732380|300.05| 51.44| 63.32 48| 260415| 5208300|300.04| 55.30| 69.29 64| 306939| 6138780|300.08| 62.56| 82.96 96| 330131| 6602620|300.09| 87.25| 123.28 128| 348095| 6961900|300.12| 110.34| 155.80小结
AWS RDS在发布Graviton 2实例时，曾宣传Graviton 2实例有52%的性价比提升。但是在这里的Sysbench混合读写的测试场景下，反而是x86性价比优势更加明显，16并发是，x86性价比要高出Graviton实例10%。而仅是在超高并发时，Graviton实例性价比才比x86高10%。但是，一般我们不会让4c16的实例，运行在如此高的压力下，所以后面这种情况的参考意义并不强。
虽然AWS曾大量宣传Graviton实例，但是实测下来并没有什么性价比的优势。所以，在数据库应用场景下，使用AWS Graviton实例的必要性，似乎并不高。另外，也注意到，RDS Graviton 3的实例一直都没有推出，也许这是其中的原因之一。
参考