简单生活

  • 更新@2023年1月

    应部分读者要求,制作了一个《高性能MySQL 第四版》主题页:链接。主题页中包含了该书籍的适合读者、如何阅读该书籍、该书籍中涉及的链接、以及部分来自读者的勘误等,供参考:高性能MySQL


    十年经典再更新

    十年前,当时Ningoo找到我们翻译第三版时(参考),还是一个刚刚进入数据库领域的小兵。十年后,当初的译者们,都已经在各个公司的数据库方向成为中坚力量。

    时隔十年,《高性能MySQL》再次出版,这是该系列的第四个版本。过去十年,《高性能MySQL 第三版》已经成为除了文档之外,MySQL相关开发者、DBA等从业者的必读书目,在豆瓣上也收到了9.3分的好评。

    另一方面,在这十年间,MySQL技术、数据库技术以及数据库的生态都发生了很大的变化,最新版的图书也相应做了大量的更新、精简与修订。这次依旧由我和宁海元、张新铭等一起完成翻译。如果,英文阅读没有大的障碍的朋友,仍然推荐阅读英文原版,目前在京东、亚马逊等平台都可以买到。如果,想读中文版的朋友,这次出版的《高性能MySQL 第四版》则是非常不错的选择。本文,概述了第四版的一些更新与改变,以及MySQL在中国这十年的发展。另外,文末有一个“回复SQL,抽奖领取赠书”的活动,感兴趣的直接跳到最后部分。新书在京东上已经上线,欢迎购买。

    MySQL在中国的这十年

    过去十年也是中国MySQL快速发展的十年。在2022年,CSDN的中国开发者调查报告中的数据,在中国,有73%的开发者都在使用MySQL,稳居第一名,且遥遥领先其他数据库。一方面是中国互联网在过去十年的快速发展背后,需要海量的、低成本的数据库存储方案,另一方面,更重要的,随着中国开发者、DBA能力增强,从原来的用好开源,逐步成长为开源背后的重要的贡献力量。无论是,阿里、腾讯、华为、百度、去哪儿等公司,都在通过各种方式,一方面输出自己的最佳实践,另一方面也在向MySQL代码库贡献自己的力量。

    随着,中国厂商在MySQL技术使用和商业上的深入,以阿里云、腾讯云、华为云为代表的中国技术厂商已经成为MySQL社区重要力量:

    • 在2018年,阿里云数据库RDS团队,因为多源复制、FlashBack等功能获得了MySQL Community Awards,彭立勋作为代表在Percona Live接受颁奖:参考
    • 2018年,在5.7.17版本,由翟卫祥贡献的关于Group Commit和GTID的优化:参考;2021年,在8.0.24版本中,由翟卫祥修复的关于InnoDB Recovery阶段性能问题:参考。除此之外,翟卫祥其实是比较频繁的出现在MySQL Release Note的人。也因为这些贡献,翟卫祥也在2019年也获得了MySQL Community Contributor of the Year的奖项:参考。
    • 2019年,腾讯游戏CROS DBA团队的陈福荣(Vin Chen)、梁飞龙(Felix Liang)也获得MySQL Community Contributor Award:参考。
    • 2022年,彭祥在今年成为MariaDB Foundation的Board Members,他也是阿里云RDS业务的负责人。
    • 2022年7月,在最新的8.0.30版本中,来自腾讯CDB团队的Yuxiang Jiang和Zhou Xinjing修复了部分关于InnoDB、PS相关的Bug:参考。
    • 另外,在MySQL Bug系统上,也经常能够看到国内厂商的身影,主要是阿里云和腾讯。

    在国内社区,诸如丁奇、彭立勋、周彦伟、杨建荣、韩锋、杨奇龙、叶金荣、沃趣科技、盖国强、何登成等都非常活跃,通过ACMUG、DBAplus、墨天轮等平台推广数据库的最佳实践。另外,国内各个大厂也都还有隐藏着非常多的“扫地僧”级别的高手,抛头露面比较少,诸如ba0tiao、江神、Jimmy(这里无法一一列举)也是中国MySQL社区非常重要力量。

    MySQL凭借着其强大的影响力,也影响着一系列的产品的发展。在云时代,MySQL依旧是主角。在2014年AWS推出的Aurora、2017年阿里云推出的PolarDB、2018年腾讯云发布CynosDB(TDSQL-C前身)都首先选择了兼容MySQL。而众多新的数据库,诸如OceanBase、TiDB、PolarDB-X、ClickHouse、AnalyticDB等都或者选择兼容MySQL或者使用MySQL类似的SQL方言。而各个云厂商,凭借着MySQL开放、开源,基于其构建的RDS、或者云原生数据库都赚的盆满钵满,通常,都能够占到其数据库收入的50%以上。这也从经济基础上,保障了各个云厂商依旧会坚定不易的在MySQL方向投入大量人力,推进MySQL的发展。到目前为止,MySQL数据库也成为了“开源技术”和“云厂商”之间,在技术利益非常庞大的时候,依旧能够较为“和谐”相处的案例之一。

    兼容MySQL的分布式数据库

    全球的MySQL数量约为800万个,大量的运行场景已经催生更加垂直和高要求的产品。兼容MySQL的分布式数据库就是其最重要的一个方向。从需求上来说,随着数据的快速增长,在越来越多的场景下,MySQL单机架构已经无法满足需求,分布式数据库在过去10年也在快速发展。2010年,阳振坤在淘宝内部开始研发OceanBase,自2015年后,开始逐步在外部探索商业化,同时兼容MySQL和Oracle;TiDB于2015年正式发布,兼容MySQL协议;2020年,在云栖大会上,阿里云数据库负责人李飞飞也宣布,DRDS正式升级为PolarDB-X,并于2021年正式开源,也是兼容MySQL协议。2018年,ShardingSphere发布(前身为Sharding-JDBC),也是兼容MySQL的。

    在中国当下,分布式数据库的竞争是异常激烈。在今年(2022年)的4月份,TiDB发布了6.0版本,将TiFlash也正式开源,之后也很快上线TiDB Cloud,上线了阿里云心选商城。OceanBase也于今年的8月发布了4.0版本,单机部署最小支持4核8G;分析能力实现了由全场景向量化能力覆盖;OceanBase Cloud也会很快上线。另外,PolarDB-X也在持续的增强,发布包括了与MySQL兼容性比较好的AUTO_INCREMENT、数据热点诊断、冷热数据存储分离、Flashback Query等功能。另外,ShardingSphere、TDSQL等也在快速发展。

    另外,在今年9月,TiDB和OceanBase都不约而同的在美国硅谷开始做产品推广,这个竞争已经逐步从国内延伸到了海外。这也是该行业快速发展与繁荣的体现。

    自此,中国的数据库已经逐步从最早的用好开源、贡献开源,慢慢走向自主研发、独立品牌的模式,也从国内竞争开始走向更大的国际市场,这是中国数据库在商业模式、技术能力、生态建设都更加强大的体现。

    新的版本,新的技术

    MySQL 5.1是十年前的主流版本,期间经历了5.5、5.6、5.7,到现在8.0逐步成为当前的主流版本。在最新的“第四版”发布时,MySQL最新的版本为8.0.20,所以,书中很多案例与测试也都在该版本中经过了测试与验证。

    这次出版的《高性能MySQL 第四版》则新增了过去十年MySQL各个新版本特性。新的版本背后代表的是新的技术。例如,从5.6开始引入、5.7和8.0版本中逐步成熟的GTID技术,大大提高了MySQL复制时的数据一致性、以及可运维性,也使得MySQL在整个数据流生态中,变得更加易用;随着,NoSQL的流行以及部分应用或者模块中Schema Free设计的出现,MySQL在最近的版本中,一直在不断增强对JSON的支持,包括操作JSON函数支持、性能优化、表达式函数支持等,使得在MySQL中也可以非常自由、高效的管理JSON数据。

    性能管理一直是该书目的重点部分,最新版本的MySQL也在不断的完善Performance Schema(简称“PS”),帮助用户更加系统的进行性能管理与优化。在第四版中新增的第三章则系统的介绍了PS,可以帮助读者系统的了解如何通过PS查看数据库/InnoDB内部的运行指标,从而观测性能并针对性的进行优化。

    云数据库已经成为数据库领域最重要的方向。本书也增加了关于云数据库的篇幅,并以AWS Aurora、谷歌云数据库、云主机自建数据库为代表,介绍了当前云数据库的使用、能力以及限制等。随着云计算、IoT、互联网等技术发展,数据量也一直在快速增长,本书也增加了关于如果扩展MySQL的章节与篇幅,包括通过只读节点进行的读扩展,以及如何通过拆分的方式进行写扩展等。

    另外,本书另一个重要特点是做了大量删减,全书也从原来的第三版约800页精简到约350页:

    删除了所有的MyISAM引擎相关的内容。MyISAM引擎是最早版本MySQL的原生引擎,但由于其架构缺陷、不支持事务、性能等原因,自8.0版本开始彻底被InnoDB替换。 

    删除了大量关于如何配置MySQL的内容。随着时间的推移,现在的MySQL文档已经非常详尽的描述了这部分操作。本书则侧重于原理、使用、最佳实践等。  

    删除或大大简化了诸如分区表、调度事件、全文索引、Query Cache等特性的介绍。虽然,在十年前这些都还算是MySQL的“高级特性”,但现在已经为大家所熟悉,而且文档已经了非常详细的描述,本书则不再介绍这些内容。

    当然,依旧保留了最重要的部分,包括MySQL架构与基础原理、可靠性管理、SQL优化、索引设计与优化、硬件与软件适配优化、表结构设计规范与原理、复制技术、备份与恢复、垂直与水平扩展、云数据库等。

    整体上,依旧非常推荐大家购买与阅读。本书,在翻译出版过程中也得到了很多数据库领域朋友的支持,包括沃趣科技陈栋、云和恩墨盖国强、OceanBase的阳振坤、周彦伟等,尤其是,阿里云数据库负责人、ACM/IEEE Fellow李飞飞 特意拨冗指导并撰写推荐序言,这里引用如下:

    随着互联网行业以及云计算产业的高速发展, MySQL成为世界范围内以及中国数据库领域最流行的开源数据库。在几乎所有大型互联网业务场景中, MySQL都是业务架构的核心组件之一。广泛的应用也推动了MySQL在过去十年的高速发展,MySQL社区相继推出了5.6、5.7、8.0版本,从性能、可扩展性、安全性、稳定性、可维护性、易用性等维度都有了非常大的发展。《高性能MySQL 第三版》是2012年发布的,最新版本的《高性能MySQL 第四版》在上一版的内容上延续了之前的经典内容,包括架构设计、优化、高可用等内容,同时新增了云数据库、扩展性等过去10年发展的相关内容,另外,也增加MySQL过去10年里的最新版本包括5.7、8.0版本的最新的特性和内容。

    MySQL作为当下最流行的开源数据库,本书从实践的角度涵盖了数据库系统的架构设计、锁、性能管理、高可用等内容,除了作为MySQL的参考书之外,也可以作为数据库系统原理和设计的一个实现参考。随着云数据库的流行,这本书的最新版也做了相应的调整,例如,将数据库的安装、配置、监控搭建等基础操作内容(云数据库封装并提供了大部分这些能力)做了大幅度的缩减。因此,本书也非常适合面向云数据库系统开发者的一本MySQL参考书籍。如本书的名字所述,本书在内核设计、性能优化方面,依旧是着墨最多的部分,深入介绍了锁管理、并发控制、Performance Schema使用、索引优化等内核机制,可以帮助企业的DBA、或者想深入了解MySQL优化的开发者,以及云数据库开发者更高效的使用和拓展MySQL。

    本书的译者是云数据库领域和MySQL数据库的资深专家,有着很强的技术能力和行业实践以及业务洞察,同时也具备非常出色的业务架构设计和商业化经验。在深入理解原著的基础上,结合自己的洞察和经验提供了出色的专业化中文版本,是MySQL领域不可多得的一本必读书目。

  • Shadowserver Foundation在5月31日发布了一份全网的MySQL扫描报告,共发现了暴露在公网的360万个MySQL实例。因为这份报告基数够大,而且信息也非常完整,从数据库专业的角度来看,里面是有很多非常有意思,且可以量化的数据和结论的。之前网上的一些分析都是基于安全角度来分析,这里我们一起再看看这份报告里面隐含的一些数据库信息吧。

    另外,这里的“暴露在公网”,是指其端口在公网可以被访问且响应握手信息,并不是可以被登录,并没有什么安全隐患。原报告的文章链接可以在文章结尾处查看。

    数据说明

    该数据由Shadowserver的SCANNING PROJECT收集,总计扫描到537.8万个打开的3306端口,其中IPv4协议的395.7万个,IPv6协议142.1万个。这些端口中反馈了握手信息的共360万个,其中IPv4协议的228万个,IPv6协议134.4万。

    返回握手信息的360万实例,因为握手信息包含了版本等信息,加上Shadowserver的地域等信息,就构成了一份较为完整的MySQL实例版本和实例分布数据。

    Shadowserver并没有公布完整的数据详细信息,但依旧公布了多个维度的数据供分析。

    8.0 GA已经四年,但5.7依旧是主流

    以IPv4 Top 10的版本来看,当前5.7版本占比最大,其次为5.6和8.0版本。另外,MariaDB占比14%,更具体的:

    • MySQL 8.0 GA日期为2018年04月,占比为8%
    • MySQL 5.7 GA日期为2015年10月,占比为46.7%
    • MySQL 5.6 GA日期为2013年02月,占比为30%
    • MariaDB版本占比为14%,包括了MariaDB 5.5占比8.1%,其10.1版本占比6%

    可以看到,MySQL 5.7依旧为当前最主流的版本,根据MySQL官方的规划,该版本可能在明年的10月就会停止对其的扩展支持,可能就不再更新版本。与此同时,MySQL官方还可能会在今年推出新的大版本(可能是9.0或者8.1之类的),加上5.7的维护周期接近尾声,会较为大量的用户升级到新版本。

    全球共有800万MySQL实例在运行

    根据一些公开数据和部分经验数据,这里对全球MySQL运行实例个数做一个预测。在这份报告中,共探测到约538万开放的3306端口,其中约360万返回了握手信息。那么,全球一共有多少MySQL在运行呢? 这里基于以下信息做一个猜测:

    • 根据帕累托法则,即2/8原则,约仅有20%的因素影响80%的结果
    • 诸如Google、Amazon、微软、阿里巴巴、腾讯、字节跳动等大型企业保有大量实例,且不可以被扫描
    • 还会有大量实例运行在AWS、Azure、阿里云、GCP等云环境的VPC之中,如果没有开启公网IP,通常也无法被扫描到,这部分根据一些经验数据,预计为200万个
    • 根据IDC数据,全球服务器2021年出货量为1350万台

    那么,扫描到538万再加上200万,则有约738万个”闲散”实例。根据2/8原则,诸如Google、Amazon、阿里巴巴等这些大型企业(非云部分)中依旧可能保有着20%的实例(738万为80%部分),也就是约为184.5万个实例。那么预计:全球整体MySQL实例数量可能在922万这样的数量级。

    另外,我们再从全球服务器出货量角度做一个验证。根据IDC数据,2021年全球服务器出货量约为1350万台,这里假设(该假设基于一些历史的经验)10台服务器对应一个数据库实例,那么2021年服务器出货量就对应了135万个实例,按照服务器平均5年折旧计算,总保有则约为675万个实例,这里与922万有一定的偏差。折中取这两个数据的平均值,所以这里预测:全球MySQL实例数在800万左右。当然,这只是一个超大颗粒度的、不可验证的预测,如果有更好的预测模型或者数据支持,欢迎回复公众号讨论。

    MariaDB在某些细分市场份额很大

    从这份数据来看,MariaDB是拿下了非常大的市场的。从IPv4 top 10版本统计信息来看,MariaDB占比为14.3%;如果,单从IPv6的统计数据来看,MariaDB占比为86.2%,实例数量超110万。

    这里在IPv6环境中,部署量最大的版本为:5.5.5-10.5.12-mariadb-cll-lve,这是一个cPanel在Lightweight Virtual Environment的发行版本,而对应的MariaDB 10.5.12版本为2021年8月发布。从这个点看到,MariaDB是获得了更多的开源社区的信任,作为其发行版的默认数据库版本。甚至在一些细分的场景中,MariaDB甚至可以说可能成为了主流。

    但,另一方面,根据在中国的实际感受来看,MariaDB的市场现状并没有以上数据展示的那么乐观,原因如下:

    • 一是MySQL品牌依旧非常强大,虽然安装的MariaDB,但是实际使用的客户端依旧可能是mysql命令行,所以,用户依旧当做MySQL来使用。
    • 另外,目前,大型企业全面使用MariaDB支撑核心业务的公司还比较少,大部分依旧是使用MySQL,并基于MySQL去进行优化,而不是MariaDB。

    当然,从这个数据角度来看,MariaDB的这个部署量依旧会给其带来很多优势:

    • 提升用户认知基础,虽然命令行依旧使用mysql,但是登录后依旧会看到MariaDB版本号信息和功能
    • 产品会在各种环境中被使用,对其整体的稳定性会有较大的保障
    • 相比MySQL,MariaDB已经获得更多Linux发行版的信任,这可能是进一步获得扩大市场的最重要的机会点之一

    49%的实例启用了TLS/SSL加密

    从所有IPv4环境的实例数据来看,有49%启用了TLS/SSL加密。因为MySQL 5.7之后的版本,都已经默认开启了传输加密,这与前面的MySQL 5.7占比数据是基本吻合的,大部分用户在使用5.7或8.0的时候,都会使用其默认自带的加密能力。所以,你的实例开启了传输加密吗?延伸阅读:

    中国的MySQL实例在全球占比15.8%

    在这份报告中,从IPv4的数据中看到,中国MySQL实例数占比为15.8%(大陆地区约为13%,香港地区约为2.8%),仅次于美国的32.5%。其次是波兰、德国、法国、新加坡等地。另外,根据IDC的报告中国服务器出货量占全球比率约为25.3%(2021年,从销售额角度),所以,中国数据库的实际部署量可能更大。

    IPv6在全球普及率都不高,中国更低

    从整体数据来看,有握手反馈的扫描中,IPv4的3306共扫描到2,279,908个,IPv6共1,343,993个,在全球角度上,运行在IPv6上的MySQL已经达到了37%。但是,这个数据在中国,仅有0.1%。虽然,数据库部署并不适合作为IPv6和IPv4的对比,但作为一个参考,可以看到在全球范围IPv6已经比较高了,但是在中国普及率还非常低。

    从这份数据来看,IPv6较高的国家有:美国、荷兰、新加坡、德国、英国等。

    这份数据的一些限制

    • 因为报告是通过端口扫描获得的信息,所以各个大公司自己内部的服务器都是不在其中的。所以,实际MySQL装机量应该远大于这个量。另外,大公司企业数据库情况可能与报告有一定的偏差。例如,通常大公司环境中数据库版本会比较统一,而不会简单的使用最新版本。
    • 报告中的数据可以看到MariaDB的部署量比想象的要大。猜测的原因可能是,很多Linux发行版本中自带的仓库使用的是MariaDB数据库,这让MariaDB的装机量比想象的更大。
    • 另外,报告没有公布所有的数据,例如版本数据,只有Top 10的版本,占整体IPv4的比率约为26%,还不是一个完整的数据,可能与整体数据会有一些偏差

    其他补充说明

    • MariaDB的握手阶段提供的版本信息与实例中的信息有一些不同,所以会呈现出比较多的是”5.5.5-10.5.12-mariadb-cll-lve”这样的版本号,其中10.5.12才是MariaDB正确的版本号;”cll”应该是代表有cPanel编译提供的发行版(参考);”lve”则可能是”Lightweight Virtual Environment”的缩写。
    • Shadowserver Foundation是什么?“Shadowserver是全球领先的恶意活动调查、互联网安全报告的公益组织,Shadowserver维护着世界上最大的安全信息存储库之一,它存储了数以万亿计的历史恶意网络连接,同时Shadowserver每天扫描整个互联网超过50种协议暴露情况,用于查找可能用于攻击利用的配置错误或存在恶意行为的系统,Shadowserver拥有超过20个监测节点。”
    • Shadowserver还扫描了MongoDB、Redis、SQL Server的情况。MongoDB约为10万个(101338,参考)、Redis约为2.5万(参考)、SQL Server约为8.5万(参考)。如果说,MySQL在很多Linux环境中可能默认安装,但是这几个数据库一般是不会被默认安装的。
    • 报告中IPv6协议下的MySQL实例数据与实际感受差距非常大,例如在IPv6版本下,MariaDB占比约为85%(超100万实例)。在IPv6实例最多的国家是美国、荷兰、新加坡等来看,这与服务器出货量相关数据匹配度非常低。所以,有几种可能:一个是MariaDB在某个细分的场景下有非常大的优势,在早期对IPv6支持更好,所以在某些对IPv6有强制要求的地区和国家有更好的市场。
    • 再次声明这里的“暴露”在公网,并不是说这些实例不安全,因为这里的探测不能,也没有连接上数据库,而是在连接之前的握手数据交换阶段。

    原始报告链接

    • https://www.shadowserver.org/news/over-3-6m-exposed-mysql-servers-on-ipv4-and-ipv6/
  • 在上周,SQL Server 2022版本(16.x)正式进入公测状态,大家都可以下载并安装了。当前只支持Windows,被称为CTP 2.0版本(community technology preview ),包含了企业版的所有功能,可以试用180天。于是第一时间下载并进行了体验,一起来看看,新版本有哪些新的功能吧。

    01 全面支持与Azure云建立链接

    SQL Server 2022版本在复制与容灾、分析增强、S3存储兼容支持、Azure Arc、Azure Defender等方面,全面的与Azure云在建立链接。

    通过Azure Synapse Link for SQL(公测支持将SQL Server 2022版本与云端Azure Synapse Analytics无缝集成,从而实现分析、BI和ML等数据处理能力。还可以通过Azure SQL Managed Instance的Link功能,实现将云端实例作为本地SQL Server的副本,提供只读或者容灾使用。

    SQL Server安装时,可以直接安装Azure Arc agent;支持使用Azure AD进行数据库的认证;支持使用Azure Defender for SQL来保护SQL Server。

    支持了S3-协议的对象存储:从2012版本开始,已经支持了备份到Azure Blob Storage,2022版本开始支持到S3兼容的存储进行备份;同时,通过,PolyBase功能可以支持S3兼容存储的访问,支持使用T-SQL直接访问parquet文件的数据。

    02新增了账本数据库(ledger database)功能

    2022版本中,新增支持了ledger database功能,提供数据不可篡改的证明。其模式类似于AWS QLDB。具体的,在数据库所有记录的变更都通过递归哈希的Merkle tree记录(被称为Database digests),用户可以通过其他独立的存储保存该Database digests,独立存储可以使用Azure Blob Storage或其他写入后不可修改的存储中。在重要的审计、第三方商务流程记录等场景下,可以使用账本数据库对数据进行不可篡改的存储。

    03 持续提升数据库性能

    • 备节点上支持与主节点上一样的Query Store功能,帮助用户管理与诊断Query的执行计划相关的问题
    • 开始支持Query Store hints功能(注:之前仅Azure云端版本支持)
    • 增强了Memory Grant Feedback (MGF) 功能
    • 提升了大内存场景下的内存管理能力,避免OOM发生;提供了大内存场景下,内存池并行扫描的能力
    • 提供了参数-自感知缓存执行计划能力,帮助SQL Server自动化的处理由于参数分布带来的无法使用最优执行计划的问题
    • 创建表语句新增了XML_COMPRESSION选项,提供XML压缩能力
    • 提供新的硬件感知和使用能力,例如使用高级向量扩展指令集(Advanced Vector Extensions)
    • DOP功能提供新的参数DOP_FEEDBACK,帮助更加自动化管理DOP参数的配置
    • 提供了Cardinality estimation feedback,帮助定位由于基数预估不准确导致的性能问题
    • 提供了基于Query Store功能的强制执行计划选择能力

    04 持续增强可用性与可管理性

    • 提供了”contained availability group”,在AG层面提供了自己的元数据管理、并且包含了需要的一些系统数据库等内容
    • 支持了AG参数REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT的修改
    • 在SQL Server初始安装时,可以直接安装Azure Arc agent
    • 进一步优化了ADR功能(Accelerated Database Recovery),开启后数据库在异常恢复时能够更快,提升整体可用性
    • 提升快照备份能力,新增了使用T-SQL冻结IO操作
    • 新增参数降低数据库收缩(空间回收)是对数据库并发读写的影响
    • 新增了数据库级别变量实现异步的统计信息更新,以降低对数据库并发读写的影响
    • 支持数据备份到S3兼容的存储中,也可以直接从这类存储中恢复数据

    05 增强了数据库安全

    • 支持使用Azure Defender for SQL保护SQL Server
    • 基于最小权限原则,对于某些管理任务新增了新的内置权限与角色
    • 提供了更细粒度(包括database、schema、table或column级别)的UNMASK权限管理
    • 更好的支持了对秘钥(数字证书和秘钥)向Azure Blob Storage的备份
    • 支持新的TDS 8.0协议,兼容TLS 1.3
    • 增强了Always encrypted数据的加密查询能力,包括 JOIN, GROUP BY, and ORDER BY等

    06 其他功能与细节方面的增强

    • 新增更多的JSON相关的函数:ISJSON、JSON_ARRAY、JSON_OBJECT、JSON_PATH_EXISTS等
    • 新增了部分处理时序数据的函数,例如DATE_BUCKET、GENERATE_SERIES等
    • 新增SELECT…WINDOW语法
    • ALTER TABLE ADD CONSTRAINT支持中断后续执行
    • 新增部分聚合和字符处理函数:GREATEST、LEAST、STRING_SPLIT
    • Azure Data Studio、VS Code最新版本都开始支持SQL Server 2022;SSMS发布最新的19.0版本;

    总结在2022版本中,继续增加了性能、安全性、可管理性,最重要就是增强了与Azure云的联系,帮助用户用好本地数据库的同时,具备较为便捷的向Azure云端迁移的能力。相关参考阅读:

    > What’s new in SQL Server 2022 (16.x) Preview :

    https://docs.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-2022?view=sql-server-ver16

    > Get SQL Server 2022 Preview Evaluation Edition

    https://go.microsoft.com/fwlink/?linkid=2162126

  • 在上周的Google I/O大会上,GCP(Google云平台)正式对外发布了数据库AlloyDB(Preview版本)。这里对AlloyDB的架构也做一个较为深入的分析,看看与当前的云原生数据库PolarDB、Aurora有哪些异同。

    01 AlloyDB 整体架构图

    AlloyDB是GCP上的一个全托管的云数据库服务,当前完全兼容PostgreSQL 14,提供企业级的性能、扩展性与可用性。声称是标准PostgreSQL性能的4倍,AWS同类服务的两倍(应该是指RDS PostgreSQL和Aurora PostgreSQL),如果是分析查询,则可能有100倍的性能加速。另外,在介绍时,还特别提到,价格非常透明,这应该是针对当前AWS数据库大多数都对IOPS独立并按量计费而说的。

    根据当前资料,其整体架构如下:

    高清大图下载地址:

    https://cloud-database-tech.github.io/images/alloydb-arch-with-qr-code.png

    02 AlloyDB与Aurora、PolarDB有什么异同

    • 简单来说,其架构与现有的云原生数据库Aurora、PolarDB都非常相似。使用了存储计算分离,分布式存储提供了多节点挂载能力。分布式存储,会带来海量存储能力,以及非常强的IO吞吐能力;多点挂载,大大增强了数据库的读扩展能力,同时因为底层使用同一个存储,所以也不再有数据拷贝和延迟等问题。
    • 在实现上,体现了”the log is the database”,尽可能只传输日志,避免数据块的传输与复制。例如,计算节点与存储节点的不再传输数据块(当然,就多了一个日志应用的过程)。这一点与Aurora类似,但是PolarDB在日志下推上,做得比较少,而是选择将存储以”较为标准”的文件系统提供给计算节点,数据库本身的各个模块还是比较完整的,这带来的好处是,对数据库的侵入要稍微小一些,对于新版本的支持和不同的数据库的支持会更加简单和一致。Aurora和AlloyDB的这种做法,则是将数据库的解构更加彻底,将数据库的日志模块一定程度下沉到存储层。在AlloyDB在实现时,还将这个部分彻底的做了分布式,通过多个不同的日志处理进程(LPS)进行分布式并发处理。
    • 这种日志处理的下推,也让数据库在进行崩溃恢复的时候,相比传统的一体化架构要快非常多,也就让数据库所提供的SLA可以更高。因为没有checkpoint,也应该就没有什么fuzzy或者sharp一说了,后端的LPS进程会持续的将redo apply到本地存储,分布式存储上的数据块的版本总是非常新的。而不用像传统数据库,数据库crash后,所有的没有刷写到磁盘的脏数据块(内存中该数据库已经更新,但是还没有刷写到磁盘)都需要通过redo应用到最新状态,所以,传统数据库在崩溃恢复时总是需要一定的时间,而且内存越大,这个时间可能会越长。
    • 另外,AlloyDB的日志存储使用了较为独立的存储,也就是文中提到了”log storage”或者”log store”。考虑日志与数据块的读写特性都不相同,使用独立的存储在性能优化上,会更加有效。一般来说,日志写入通常是append-only的,而且是”同步”操作,需要非常低的延迟,另外,在AlloyDB的设计中,日志写入后,需要立刻读取并应用到数据块中。只需要将内存中已经更新过的数据块覆盖写入本地存储就可以了。而数据块的处理,通常来说是一个异步的过程(不阻塞数据库的写入),并且会有大量的随机读,这与日志数据的访问有很大的不同。这里的一个猜测是,日志存储和数据块存储可能使用同一套存储架构,但是可能使用面向不同场景的优化和参数,如果有Google的人,希望求证一下。
    • 计算节点使用了”ultra-fast cache”,猜测一下,可能是使用了与PolarDB类似的optane存储作为加速,虽然使用optane卡的场景不同。这也是另一个希望求证的点。
    • AlloyDB的数据块请求是带有LSN号的,而每个可用区(Zone)内都有完整的数据块,所以,在各个可用区的节点(可能是read replica)总是可以在本地可用区获得最新的数据块。也就是无需像Aurora使用的多数派协议,数据块的读取需要3份(写入四份,4+3>6),当然Aurora也对这里做了很多的优化(例如,通过一个bookkeeping记录写入数据和node的对应关系,尽可能将多数派读取变成一次单节点的读取[参考])。
    • AlloyDB下沉到存储的日志处理服务(LPS),也做了彻底的分布式。日志存储在一个底层的相对独立的日志存储中,日志处理服务则是一个分布式的、相对”无状态”的进程,因为也做了存算分离,所以有非常好的扩展性。另外,在日志处理的分片上,AlloyDB通过将底层的数据块分成一个个独立的分片(Shard,应该类似于PolarDB或其他系统中的chunk),每个分片由一个独立的LPS处理,一个LPS可以根据系统压力情况处理一个或多个分片。这样就通过分布式的方式解决了日志应用的问题。并且,这个日志应用是在各个不同的可用区独立运行。
    • 关于数据副本数量的问题:Aurora是3*2的副本设计,每个可用区两个副本,每次写入应该是3个副本,读取可能需要4个副本,这种性能应该比较差,达到的效果是宣传”AZ+1”的容灾能力,也就是一个可用区失败,再加一个副本失败,依旧可以恢复数据。在实现上,Aurora对于底层副本感知是要更强的,并与上层实现结合起来了。但是AlloyDB使用Google底层统一的存储,这里看到的数据分布在三个zone,有三个副本,但实际上,每个zone的数据是存储在一个分布式存储的,这个分布式存储数据的副本数情况,并没有对数据库暴露。这里可以猜测,可能是两个副本或者更多,对于数据库这里IO敏感型的应用,应该比较难使用EC算法去做去重。所以,实际上,一份数据,可能会有超过6份的副本数。
    • 另外,这里看到,Block storage部分是可以通过一些智能化的方式,对数据块进行分级,降低整体的存储成本的,这应该是底层存储的数据分层能力。

    03 AlloyDB的写操作

    这里通过一个写操作来看看,AlloyDB的整个处理流程。客户端通过TCP连接,连接到主实例,然后将变更SQL发送到主实例。主节点进行SQL解析、并在内容中更新数据和索引页,同时,准备好WAL日志。在事务提交时,则同步地将日志写入低延迟的日志存储,这些日志则会被日志处理进程(LPS)异步的消费并处理。

    存储层被分成了三个部分:日志存储、日志处理服务、数据块存储。日志存储本身是顺序写,并对写入延迟要求很高,会直接影响事务处理的性能。AlloyDB专门针对该模式/场景进行了优化,以提供一个高性能的、低延迟的日志存储服务。

    多个日志处理服务(LPS)则会根据”Shard”(一组数据库的数据块)机制,对不同的日志进行处理。先从存储层读取需要处理的数据块(随机读),然后将redo日志应用到这些数据块,并回写(持久化)数据块到存储中,并最终删除日志存储中的日志记录。

    04 AlloyDB的读操作

    读操作有两种情况,一个是从主节点提供服务,一个是从读节点(read replica)提供服务。如果查询所需要的数据都在内存中,那么就和单机的PostgreSQL实例一样,进行SQL解析、执行计划生成、查询执行,并响应用户。为了加速查询处理,AlloyDB在数据库中额外集成了一个”ultra-fast block cache”。

    如果,需要的数据块在上面的两级缓存中都不存在,则需要到存储中获取。在把请求发送给存储层的时候,需要附带把LSN(log-sequence number)号也作为请求的一部分,而底层存储则返回满足该LSN对应事务能够看到数据块。

    从整体存储层来看,LPS进程也会参与数据块的请求的处理。LPS进程也有自己的缓存,如果请求的数据块在这个缓存中,则会立刻返回给上层节点。如果,这里再次缓存缺失,则再向数据块存储读取数据块并响应请求。

    这里,LPS进程需要存储一个”列表”,用于记录日志已经提交,但是,还没有应用到底层的块记录。对于此类数据块的请求,则需要先完成日志应用再返回。虽然,此类情况不应该经常出现,因为如果是一个最近日志没有应用的块,缓存应该不太会把这样的页面清除。

    05 其他

    • 虽然是Preview,但已经是目前看到的最具诚意的Preview了:任何用户立刻就可以开通使用,并且给予了非常大的免费额度,具体的,计算节点每月免费不超过1.5万美元、存储节点不超过650美元的资源。
    • 另外,注意到,GCP会说这是一个”fully-managed, PostgreSQL-compatible database”,而不会过多的强调这是一个云原生的数据库系统。对于用户来说,这就是一个具备高性能、高可用以及高可靠的PostgreSQL。至于,是不是Cloud-Native的,Google似乎对于这个概念并不那么”感冒”。
    • 通过实现”non-disruptive instance resizing”、Vacuum优化管理、Crash Recovery的速度提升,这个服务推出就是99.99%的SLA。
    • 更底层使用的是Google内部统一的分布式存储层,经过Gmail、Youtube等大型系统的验证,性能/稳定性等经过了验证。这一点上,AlloyDB与PolarDB、Aurora是不一样的。PolarDB和Aurora都选择了实现自己面向数据库的分布式存储系统,而AlloyDB选择了更加通用的存储层,再面向数据库进行优化。这两个路线,客户价值都是直接的,但哪个方案的生命力会更加持久,可能需要几十年的时间去观察。
    • 与AlloyDB一起,GCP还推出一个Oracle到PostgreSQL的迁移服务,只是这个服务看起来推出的也比较仓促,比较困难的结构迁移部分,使用了一个第三方的开源产品来实现。一方面可以看到这个,迁移是非常重要的模块,另一方面也看到,这一块做起来其实比较难。从这里看到,AlloyDB考虑优先推出PostgreSQL版本的一个重要原因,是认为:Oracle数据库的迁移至关重要,且PostgreSQL是Oracle迁移的重要目标数据库。
    • 目前,发布的内容来看,关于数据库内部的并发访问/多版本管理的内容比较少,这部分应该是另一个复杂的点。期待后续的文章。

    06 一些已知的不确定的点

    • ultra-fast cache是什么介质?如何被使用?
    • 对于其他zone(非primary节点所在的zone),他的WAL日志(在log storage上)从哪里获取?WAL一定是具备跨zone的容灾能力的,这里WAL的容灾是在数据层去做的(日志写时写两份或者三份),还是log storage去做的?
    • 与上面的问题相关的另一个重要的问题,LPS进程是全局的还是属于某个Zone的?
    • log storage是针对日志场景专门进行优化的,其模式是,append-only、延迟敏感并直接影响效率,这里的疑问是,做了哪些优化?

    如果有Google的同学,可以一起讨论一下。

    参考

    • AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage
    • AlloyDB for PostgreSQL
    • Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases
  • 实测阿里云RDS Serverless

    ·

    在4月底,阿里云RDS Serverless正式公测发布。第一时间申请了公测资格,并进行了测试验证。测试完成后,还是非常期待这个功能的商业化的,当前的公测版本也值得开发者们去了解和小范围(例如开发测试环境)尝试。

    00 什么是RDS Serverless

    RDS Serverless是一种独立于按量付费、包年包月的资源使用与计费模式。提供了一种自动化的弹性扩缩容的规格,用户无需提前选定固定规格,后端会根据系统压力进行自动升降配,并根据实际使用计费,当然,用户需要设置该规格最大和最小规格,限制最大、最小使用资源与费用。

    对于峰谷明显的业务系统,该模式一方面可以在需要时提供很高的资源规格应对压力,另一方面可以在低峰时降低资源使用,降低成本。

    01测试结论概述

    • 整体上,该Serverless版本的升/降配速度非常快,约10秒完成压力检测与变配,升配时性能表现非常平稳,降配时性能比较平稳。
    • 具体的,在系统压力突增时,约10秒内就可以完成检测与变配,完成升配后系统压力立刻得到一定程度的缓解;与之前的Aurora Serverless v2测试中,升配的时间是差不多的,都是10秒以内
    • 在系统压力下降时,降配的速度也非常快,约10秒完成检测与降配操作。另外,需要注意的是,当前的版本,因为降配非常快,也导致降配后,性能出现了一些波动,持续约10秒,波动幅度从约8毫秒的响应时间增长到30~50毫秒,在两次降配之后,都出现这样小波动。相比,Aurora降配更加“保守”,观测了50秒,之后才开始降配。在降配之后,Aurora的性能依旧非常平稳,没有任何波动。也就是说,降配过程中清除出内存池的数据页都是确确实实不再使用的,这里可能需要深入的观测InnoDB的Buffer Pool收缩时的表现,避免将可能使用数据页清理出内存。
    • 目前只支持基础版(单节点实例),应用场景还比较有限,不过对于开发测试环境,种类可用性要求没那么高,且性能峰谷明显的场景,是可以轻松节省超过50%成本的,而且在实际使用时,性能还会非常不错(最高扩展到8*RCU)。
    • 当然,现在阿里云RDS Serverless还是刚刚公测,申请公测资格通过后,可免费创建2个体验实例,最大规格为8*RCU,即约8c16g内存的实例,免费周期3个月,算是不错的羊毛了,具体的,可以通过RDS MySQL购买页找到公测申请链接。

    02 测试方法说明

    整体的测试方法与之前做Aurora Serverless v2类似。首先,启动一个单线程sysbench,作为测试“主进程”,程序运行900秒,在“主进程”运行300秒后,再启动一个“压力进程”(24并发的sysbench进程)向系统施压,该进程运行300秒后退出,在这个过程中,我们观测”主进程”的rt变化,以及整个过程中,实例规格的变化(依旧以buffer pool为指标)。更详细的描述可以参考:实测Aurora Serverless v2

    03 测试结果与分析

    3.1 整体过程

    • 下图黄点代表主进程每秒RT的变化;”蓝点”(连成线)代表秒级别buffer pool的变化。左侧纵坐标为响应时间,单位为毫秒;右边纵坐标为buffer pool大小,单位为GB
    • 在第300秒,“压力进程”给出额外压力之后,系统开始升配,经过三次升配之后,到最大规格
    • 在第600秒,“压力进程”退出,经过了4次降配,降级到最低规格

    3.2 升配过程

    从如下放大的图可以看到,在“压力线程”启动的第300秒,“主线程”的响应时间立刻增长到了300ms。

    • 该实例在之后的7秒内完成升配,实例响应时间也立刻降了下来,降到约75毫秒
    • 之后,再过10秒(约第317秒),完成了第二次升配,实例响应时间再次下降,约到30毫秒
    • 再过约10秒(约第328秒),再次升配,但是此时响应时间不再有什么变化

    3.3 降配过程

    • 第600秒,压力进程退出,约11秒后,完成降配。但是,在第15秒性能出现明显波动,持续10秒
    • 第650秒,完成第二次降配,4秒后性能出现波动,持续约5秒
    • 第670秒,再次降配,性能再次波动,并出现一个异常点,响应时间非常大(约200ms)
    • 之后,系统平稳运行

    04 其他

    • 当前RDS Serverless处于公测阶段,没有SLA保障,且仅支持基础版、区域支持也有限,虽然降配和升配都比较快,也比较稳定,但是还不适合生产环境。
    • 当前,实例规格区间为0.5~8 RCU,最大规格也还比较小。
    • 在这次对比测试中,也发现,相比AWS,阿里云在同一个可用区的网络延迟是更低的,仅5~10ms,而Aurora同可用区响应时间约为15~20ms。
    • 据了解,阿里云今年还是会在这个方向加大投入,还会有一些大的版本和改进发出来,拭目以待吧。

  • 实测Aurora Serverless v2

    ·

    Aurora自2014年发布以来,一直是AWS的最核心数据库产品,而Serverless则是这个产品最重要的功能之一了。在2018年08月,Serverless功能刚刚GA,当时做过一次测试(参考)。在2020年底的re:Invent上,Andy Jassy宣布Aurora发布Serverless v2,时隔一年半,终于GA,一起来看看实际效果怎样吧。

    在最近看到该功能的介绍文章中,使用了”几分之一秒内扩展”、” scales instantly and nondisruptively “等描述,对此,我是保持怀疑的,这也要实测一下的原因,从一个用户感受的角度,看看一次升级(scaling)需要多长时间。

    测试结果概述

    • 在这次实际测试中,新的Serverless v2,可以将scaling up的时间降低到10秒级别。系统压力上来后,首次升级(scaling up)花了13秒,之后的几次升级分别花了7秒、4秒、10秒等。在这几秒内,Aurora需要完成监控采集、分析与决策,变配动作完成等动作。于用户侧,系统压力突增时,10秒内Aurora就会完成升级,这是非常实用和强大的。
    • 相比4年前GA版本数分钟级别的升级(scaling),新的版本提升非常大。不过,与宣传的亚秒级( in a fraction of a second )还有差距的。当然,一种猜测是,”亚秒内”完成的是变配动作本身,不包括监控、决策与命令下发等过程。
    • Scaling down是逐步阶梯式完成的,每次间隔约1分钟,这是符合预期的。
    • 新的版本与旧版本有非常好的兼容性,可以作为旧版本的replica,然后切换为主节点,也就可以完成平滑的升级。新的版本,支持MySQL 8.0和PostgreSQL 13版本。
    • 该功能的客户价值是非常明显的:在更多的业务场景中,可以帮助用户降低成本,同时也可以帮助应对更多的突发流量。另外,云计算的”使命”之一是通过统一的底层资源调度,提升资源利用率,降低资源使用成本,而该功能,在交易数据库的场景,把这个”使命”的粒度降低到了”秒”级别。用好了该功能,在很多场景中,降低50%的数据库成本应该是容易的。
    (more…)