北京网站优化厂家,做网站公司项目的流程,asp网站建设,怎么申请网址好的 MySQL 兼容性可以做到什么程度
PolarDB-X 如何做生态兼容
——吴学强#xff08;燧木#xff09;阿里云数据库高级技术专家
了解更多PolarDB-X 内容#xff1a; https://developer.aliyun.com/topic/polardbx_release
众所周知#xff0c;数据库是基础的软件系统燧木阿里云数据库高级技术专家
了解更多PolarDB-X 内容 https://developer.aliyun.com/topic/polardbx_release
众所周知数据库是基础的软件系统而基础的软件都有自己的生态。生态的构建有两种范式第一种范式是从 0 到 1 的构建第二种是基于已有的生态继续演化。
分布式数据库是数据库领域的热门方向目前已有非常多的开源项目。这些开源的项目大多都选择了第二种方式即从已有的 MySQL 或 Oracle 生态进行自己的生态构建。
而采用第二种方式就不得不考虑与已有生态的兼容性。兼容性并不是0 和 1 的二分区别用兼容度来表达会更客观。作为新的数据库更应该关注的是它解决了什么新的问题或是带来了什么新的特性。
一、为什么要兼容 MySQL 2003 年淘宝网成立之后业务飞速发展其后台架构也进行了多次迭代。2009 年之前淘宝网后台的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、 Oracle 的数据库加上 EMC 的高端存储。这套组合成本高昂但依然无法满足淘宝网对于高并发、大容量的扩展性需求。
为了解决这两个问题 2009 年淘宝发起了“去 IOE” 运动其目标是用自研的分库分表中间件 TDDL 加自己维护的 MySQL 分支 AliSQL 来替换 IOE 组合。这套架构在 2011 年双 11 大促的时候成功接管了交易的核心库之一——商品库从而验证了 TDDL AliSQL 方案的可行性。
伴随着此套方案的普及“去 IOE” 活动在 2013 年正式结束TDDL AliSQL 组合成为了阿里巴巴所有业务接入数据库的标准。
同时因为 TDDL AliSQL 组合即分库分表中间件 MySQL 方式在阿里的成功验证其他国内互联网厂商也都紧随其后分库分表中间件的方案在国内得到了普及。
2015 年TDDL 以中间件的形态在阿里云上发布名为 DRDS 即分布式关系型数据库。 此后DRDS 继续迭代。迭代过程中也尝试解决了中间件形态几个比较大的问题。 2016 年通过外部系统来尝试解决此形态下扩容的问题。2017 年基于 MySQL XA 实现了内置的分布式事务能力。2018 年为了解决此组合的运维复杂度进行了产品形态上一体化设计的尝试。2019 年阿里对过去 10 年的技术实践和 5 年的上云经验进行了重新思考并对产品架构做了全新的梳理和设计。
2020 阿里发布了全新一代的产品架构并将 DRDS 产品品牌升级到了 PolarDB-X。在 2021 年云栖大会PolarDB-X 正式对外开源。
回顾产品发展的历史可以得出两个显而易见的结论PolarDB-X 产品的出发点就是 MySQL 因此产品后续的迭代都是以兼容 MySQL 作为目标之一
第二通过近 10 年的不断探索从中间件形态到分布式数据库形态并没有不可跨越的技术鸿沟。
二、怎么做兼容以 CDC 为例 CDCChange Data Capture 即增量数据捕捉用来解决一些特定的业务问题。
后台系统一般可以分为上层业务系统和下层数据库系统。业务最原始的数据都存在数据库系统中。一份重要数据有很多问题需要考虑其中之一便是如何解决数据孤岛的问题——如果想进一步挖掘这份数据的价值如何将它与其他生态系统进行互通 MySQL 通过 Binlog 特性来打通与下游工具或系统的互通。Binlog 可以简单地理解为单一的队列队列按照时间顺序严格记录了 MySQL 里面所有数据的变更过程。下游工具或系统通过消费队列来实时获取到 MySQL 里数据的变更。 PolarDB-X 提供 CDC 能力首先需要考虑能否提供完全兼容 MySQL Binlog 的 CDC 能力。在分布式系统中提供上述能力会面临若干问题而这些问题都由同一个原因引起。
分布式数据库系统中通常有多个计算节点和存储节点如上图所示的 CN 和 DN 节点。多个节点会产生多个事件队列会面临以下几个问题
① 在不同队列里事件之间的顺序如何确定
② 通常分布式事务会涉及到多个队列如何找到分布事务包含的所有增量事件以保证分布式事务的完整性
③ 分布式系统中 DDL 操作不可能在所有 CN 或 DN 节点中同时生效也就意味着在若干个增量的事件队列里可能会存在不同版本的 schema 如何解决
④ 分布式系统很大的特点就是弹性自动扩缩容所引发的事件队列的增减问题如何处理
针对以上问题进行非常详细的分析之后我们最终得出的结论是这些问题可解但代价较高而最终工程量在可接受范围之内。因此我们将 CDC 这项能力的目标设计为保持与 MySQL Binlog 的体验完全一致。
实现此功能后 MySQL 能够订阅 Binlog 的工具或系统可以从 MySQL 无缝切换到 PolarDB-X这项能力被称为 Global Binlog (全局 Binlog)。
全局 Binlog 能力已于 2021 年云栖大会发布。此后我们进行了持续迭代包括稳定性相关的继续优化、性能的优化且验证了更多下游工具或系统。
以 Flink CDC 为例Flink CDC 已经提供了 MySQL Connector 的连接方式。因为 PolarDB-X 提供了一种与 MySQL Binlog 完全兼容的全局 Binlog 能力所以可以将 Flink CDC 的 MySQL Connector 直接与 PolarDB-X 进行互通。
最终从产生接入的想法到 Flink CDC 的 github 上出现支持 PolarDB-X 数据库作为源端整个过程只花费不到一周的时间充分证明了做到与 MySQL Binlog 完全兼容之后带来的便利性。
Global Binlog 与 Flink CDC 连接演示——双十一交易大屏模拟
https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/d/ud/363370843639.mp4 去年在云栖大会开源之后到现在我们的工作又有了一些进展。上图橙色部分是已经在 2.1 版本里实现的新功能主要是对下游工具或系统的验证。
下一步我们会验证更多工具尝试支持 GTID以及实现 Binlog 多流的能力。 前文解决了数据库下游的问题上游的问题也不可忽视。
分布式数据库是用来处理特定的情况下比如其高并发或扩展性遇到问题的数据库类型这也意味着业务在上线之初通常采用单机形态的数据库。而从原来的单机数据库往分布数据库迁移或切换时如何平滑、有效地完成迁移也是不得不考虑的问题。
MySQL 实现平滑迁移主要通过其原生的主备复制能力以保持主节点和备节点之间的实时增量同步即 replication 能力。它所用的 SQL 指令为change master 。
而如果 PolarDB-X 提供同样的能力是否可行
经过分析之后我们认为可行但有一定的工程量。因此最后结论依然是提供与 MySQL 完全兼容的复制能力称为 Replica 。
Replication 演示 https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/d/ud/362371229925.mp4
本次演示以 MySQL 为主,PolarDB-X 为备搭建一条主备同步链路以展示 PolarDB-X 的 Replica 能力。
以上这两个例子就是 PolarDB-X 开源后在 MySQL 兼容方向上新加入的一些能力。 PolarDB-X Replication 拥有如下特性
① 产品体验上能够支持 MySQL 原生的 change master 指令即可以在 PolarDB-X 里直接输入 change master 指令来搭建 MySQL 到 PolarDB-X 主备同步链路。
源端也支持以 PolarDB-X 作为主库意味着可搭建 PolarDB-X 到 PolarDB-X 主备同步的链路。支持 DDL 同步以及支持事务复制、行级复制用户可以在性能和事务的完证性两个方面进行选择。
② 性能方面单条复制链路目前支持 1.5 万 RPS 没有大事务等特殊场景下支持 1 秒以内的同步延迟。
③ 目前已验证的上游系统包括 MySQL/ MariaDB 和 PolarDB-X后续会尝试验证其他系统。
下一步我们的工作主要将围绕以下三方面开展接入多流能力使得PolarDB-X 和 PolarDB-X 之间的同步链路有更强的性能增强适配 global Binlog 的 GTID 能力使得同步链路在事务复制时可以支持并行复制能力适配更多源端。
三、完全兼容 MySQL 吗 MySQL 是非常复杂的系统可以将其拆解为若干特性或功能项再进行逐项分析。
首先特性的重要性如何上图中以扇形对应的角度来表示其次PolarDB-X 在这项能力上对 MySQL 的兼容程度有多少上图中以扇形半径来表示。如果 PolarDB-X 做到了与 MySQL 特性完全兼容扇形的半径应该与外面圆的半径相等如果只做到部分兼容则扇形离圆的边缘有一部分空白如果目前 PolarDB-X 还不支持此特性则对应的扇形为空白。
上图显示了评估后的结果。可以看出 PolarDB-X 在基础能力的兼容性上总体表现不错高级特性也兼容了很大一部分但是有部分特性依然不兼容。
PolarDB-X 的目标并不是完全兼容 MySQL而在于上图的下半部分圆—— PolarDB-X 对 MySQL 数据库更多能力的增强或新增。比如并发的读/写、存储容量、单表的容量、弹性、高可用和容灾、HTAP 、企业级特性等能力相对 MySQL 都有了非常大的增强。
四、进入 Kubernetes 生态
PolarDB-X 也是云原生的数据库而云原生以 K8S 为底座。
因此 PolarDB-X 在 K8S 上也做了非常多工作比如基于 K8S 进行了资源的编排、构建了 CICD 流程、进行混沌测试等。
2021年云栖大会我们开放了最基础的 PolarDB-X Operator 能力。而 PolarDB-X 2.1 最新版新增了基于 PrometheusGrafana 监控的系统增强了可观测性。 上图为监控系统页面截图展示了系统的资源、QPS等丰富的监控维度。用户可以在 github 仓库上下载、安装和体验。
另外我们对 Operator 也进行了持续迭代。此前提供的 Operator 只具备基本实例生命周期的管理能力比如实例的创建、销毁等。后续已新增比如扩缩容、升降配、数据自动 rebalance 等能力。 在 K8S 方向上我们还有丰富的规划。上图展示了后续计划的工作。
绿色部分是目前已经完成的用户可以通过开源仓库进行体验
生命周期管理上提供实例的创建、删除、升降级等弹性上支持实例的水平扩缩容、垂直扩缩容、数据rebalance 等高可用和容灾上支持 CN 高可用、 DN 高可用、GMS 高可用、CDC 高可用等监控上支持支持 CN 监控、 DN 监控、GMS 监控等。
黄色部分代表当前正在研发的能力比如备份恢复、SQL审计、 Dashboard 、数据透视等。
白色部分代表未来更长期的规划比如国产化、参数设置功能等。
以上就是我们在云原生能力上的一个规划后续也会有节奏的开放给用户使用。
原文链接
本文为阿里云原创内容未经允许不得转载。
