网站维护工程师工资,我厂有大量手袋订单外发,tp框架做视频网站,vi设计是什么设计PolarDB-X 2.1 新版本发布
让“MySQL 原生分布式”触手可及
——黄贵#xff08;曲山#xff09;阿里云数据首席架构师
了解更多PolarDB-X 内容#xff1a; https://developer.aliyun.com/topic/polardbx_release
PolarDB-X 2.1 是 PolarDB-X 非常重要的版本#xff0c…PolarDB-X 2.1 新版本发布
让“MySQL 原生分布式”触手可及
——黄贵曲山阿里云数据首席架构师
了解更多PolarDB-X 内容 https://developer.aliyun.com/topic/polardbx_release
PolarDB-X 2.1 是 PolarDB-X 非常重要的版本也是第一次 PolarDB-X 分布式数据库的产品可以作为企业级的分布式数据库真正部署到客户的生产环境使用。
一、一个好的MySQL分布式数据库应该是什么样的 C语言设计的概念 Zero Overhead Abstraction ——0负担抽象原则它有两个重要特性
无须为不用的特性付出代价 C 类用户升级到 C 时如果不使用 C里的高级特性则无须为这些特性付出额外的代价。比如在 C 里面是 structure到 C 里可能是class 。对于 C 中的 structure 和 C 中的 class 如果不带 virtual function 则在内存布局的性能消耗上是等同的不用付出额外的代价。你所使用的代码不可能手写得更好如果想要使用更高级的特性用 C 扩展的能力一定比手写的代码更好即C 提供的语言特性能够很好地帮助到用户。
C 语言的用户升级到 C必然是因为它带来了更新更强的能力比如封装、抽象的能力可以做继承、有多态。另外C 提供了多种编程范式比如面向对象、泛型编程、函数式编程等这些特性都可以极大地拓展语言的抽象带来能力的提升。
同理从单机的 MySQL 数据库升级到分布式 MySQL 数据库我们期望它能有哪些表现
首先是完全兼容可以由单机平滑过渡到分布式系统无需对应用进行改造第二无需对数据库的结构进行改造第三不使用分布式能力则无须付出额外的开销。
单机到分布式最重要的变化是数据会分布在多个节点上对于数据库中很多操作而言尤其是事务是需要付出一些额外代价的。如果事务涉及到多个数据的分区而只是想将分布式系统作为单机数据库来用同样也可以有单表的特性无须付出分布式事务的代价。
升级到分布式系统后能够获得自动伸缩的能力能够天然地利用分布式的特性实现跨地域的高可用还可以处理混合的负载类型包括事务的负载以及分析的负载提供了高性价比的解决方案。
二、让分布式能力透明化 如何实现从单机到分布式完全透明化
以从单机 MySQL 迁移到 PolarDB-X 2.1 版本为例
第一步建表。使用单机 MySQL 上的建表语句、DDL语句在新的分布式数据库上建表无须做任何修改。
第二步让应用跑起来。应用代码也无须做任何修改原有的 SQL 语法、原有的客户端驱动程序都可以直接使用只需要更换新的数据库连接地址。
第三步性能调优。可以使用很多工具做压测包括一些可视化工具能够提供对整个系统 SQL 性能的分析 DAS自动调优工具能够帮助找到热点SQL还可以通过 DDL 建新的索引或对数据分区进行调整对热点 SQL 进行调优。
实现以上整个过程的大部分操作只是诊断和适配无须进行过多改造工作。 对于分布式系统而言要做到透明核心就是对分布式事务的支持。分布式数据库与单机数据库的关键差异在于分布式数据库是以一定的规则将数据做分片然后分布在多个节点上其中核心点在于如何在事务跨了多个数据分片时保证它的 ACID 语义。这其中会涉及到如何做事务的 ACID 保证如何做多版本处理并发的控制。有了事务 ACID 的保证才能在此之上建立全局二级索引。
此外很多其他功能比如备份恢复、时间回溯的查询以及分布式的备份等都需要依赖分布式事务提供的全局一致性能力。数据的导入和导出也需要保证数据有全局快照的能力在任何时间点都能读到一致的版本。
有了全局二级索引和多版本的并发控制等能力的支持即可实现透明的分布式无须显式地指定分区键只需要像单机数库一样创建表即能默认做数据的分区也无须考虑数据分区带来的跨节点事务的处理。表的修改操作和Online DDL 也不会对数据库的其他操作产生影响。 PolarDB-X 实现的是全局一致性的分布式事务
使用 TSO全局 timestamp MVCC 多版本并发控制机制实现的分布式数据库。主要的技术原理是基于 Paxos 做事务日志的同步来保证高可用。
在事务在处理的过程中因为使用了两阶段提交的方式来做分布式事务的处理如果发生了节点失效也可以利用 Paxos 带来的高可用能力保证事务继续进行下去。
另外使用了全局唯一的时间戳以及多版本并发控制的机制来保证它的隔离性实现了 Snapshot Isolation 的隔离级别。
具体流程如下GMS 组件提供全局事务的时间戳在发起事务的过程中如果事务要做提交则会获取提交的时间戳并将其带到所有下面存储节点的参与者上。然后结合事务当前的状态根据时间戳判断事务的可见性。每一条数据上都有其提交的时间戳将其与当前事务的时间戳做比较以决定这条数据在当前的事务中是否可见。
通过上述机制即可实现分布式事务的全局一致性和快照隔离。
本次 2.1 版本发布的最重要的功能就是自动模式数据库的功能。PolarDB-X 在 1.0 版本时代是利用分库分表的模式来进行数据的自动分区。 2.0 的时代引入了全新的 AUTO 模式数据库无需指定分区键。 上图展示了典型的电商交易场景有交易记录表其主键是事务 ID 还有买家和卖家两个重要角色。对于交易的流水而言通常除了按交易的流水日志 ID 查询以外也有可能从买/卖家的维度查询。
表内可能有上亿条记录需要将它创建为分区表。对于分布式数据库 PolarDB-X 而言无需指定特定的分区键。因为这里的分区健如果是按照buyer_id或者seller_id去查询无法做分区裁剪。可以像使用单机数据库一样默认按主键 ID 做数据的分片。分片的算法默认是一致性哈希也支持很多其他算法包括 interval 做范围的划分、 range 的分区等此类算法也可以通过 DDL 语句根据业务特点做调整另外还可以通过多个查询维度建全局二级索引。
上图例子中建了两个全局二级索引分别是买家 ID 和卖家 ID 。往表里面插入数据的时候会针对数据根据数据的分区规则将它均匀地分布在数据节点上。上图右侧两张索引表同样也按照分区规则做了均匀的分布。 数据自动负载均衡的功能使得用户无需关心数据具体分布在哪个数据节点上可由系统自动完成主表以及两张索引表都按照一定的规则做数据的拆分分片以后按照数据的大小和容量均匀分布到各个数据节点上。
有了自动负载均衡的能力以后也就具备了在线扩缩容的能力而在线扩缩容是单机到分布式平滑演进的重要基础。 上图有计算层的 CN 节点也有存储层的 DN 节点。 CN 节点是无状态节点扩容和缩容非常轻量化因为所有 CN 的能力都对等将 SQL 发送到任意 CN 节点都可以实现同样的处理能力得到相同的结果。出于性能的考虑一般会将数据就近调度到临近的 CN 节点上。
因此CN 的扩容非常方便只需简单地将 CN 节点添加到集群上同步到 GMS 节点里即可。
DN 是有状态的数据节点扩缩容需要做数据的迁移。增加了一组数据节点后调度任务管理器会根据当前数据的分布状况将一部分数据迁移到新的数据节点上以此保证所有节点的数据处在均衡的分布状态。
性能和容量方面PolarDB-X 最大可以支持 1024 个节点单节点最大存储 5TB 数据能够满足大部分数据库的容量需求。
缩容同理下线数据节点后会将它缺失的副本补足然后重新均匀分布到其他数据节点上。
从单机数据库迁移到分布式数据库可以基于 Online DDL 的能力动态完成单机大表切换到数据分片的模式。比如原来在单机上非常大的表希望通过分布式系统的数据分布能力对其进行拆分可以通过一些 DDL 的能力动态地修改其分区模式来完成单表到数据分布表的转换。
对于单机分布式而言PolarDB-X 完全兼容了 MySQL 的语义及其行为包括上下游对接的生态比如全局 CDC 可以生成全局一致的 Binlog可以将其作为单机 MySQL 的日志流来使用。不管是同步到下游大数据系统还是作为 MySQL 的备份都可以通过 CDC 来对接。 Online DDL 最大的特点就是在做 DDL 的过程中对当前数据库正在处理的业务 DML 语句没有任何影响,极大减轻了数据库运维人员的负担。数据库难免会遇到一些修改表结构、增加点索引等诉求如果每次都要在业务的低峰期去进行对运维会造成很大困扰而且不够及时。有了 Online DDL的支持以后可以在任意时间点做变更。这些变更包括了创建索引、加减列、变更分区算法。
值得一提的是加列操作使用了 Instant DDL 机制可以只修改元数据无须对全部数据进行修改操作性能极高为毫秒级对业务的影响可以缩减到最小。
此外可以将数据库由单表变成分区表。在分区表上还可以修改分区数、表组以及分区算法等。同时也可以将它修改成广播表在每个数据节点上都有同样的复制表对于频繁做 join 的小表非常有用。这些能力也使得用户可以灵活调整数据表的数据分布方式以满足不同业务负载的需求。
三、分布式是一种全新数据库的模式
分布式是一种全新的数据库模式它不仅是对单机数据库的完全兼容更大的作用是带来了更多更强的能力。PolarDB-X 2.1版本带来了以下卓越的能力
1. 高可用容灾能力 2.1 版本正式引入了 X-Paxos 使用 Paxos 一致性协议保证数据的可靠性以及系统节点失效时的可用性。
它实现了 99.99% 可用性任意节点的故障都不会影响集群的可用数据 0 丢失。
提供了多种部署形态
① 同城三机房默认 2.5 副本。在 Paxos 协议框架下有几种角色包括 leader节点数据事务的主节点它带有两个副本分别是 follower 节点和 logger 节点。logger 节点为了节省成本不存储全量数据只存储日志来保证数据的一致性同时也减少了数据副本的存储另外还有 learner 节点可以做只读的副本。
② 两地的三中心默认五副本。
拥有分布式特性用 Paxos 协议做一致性同步时需要传输日志而在网络上保证大量的日志传输的一致性较为困难。2.1版本支持日志分片的拆分也做了行级热点的写入支持自动合并为很多电商的秒杀业务场景提供了保障另外通过对 follower 节点开放读在 follower 节点上可以将全局 TSO 带过去做一致性版本的读利用 follower 节点的处理能力来提升整个系统的吞吐。 高可用的架构帮助我们提供了一个很好的基础。使得PolarDB-X 在容灾方面也提供了强有力的支撑比如两地三中心的部署方式。采用5 副本221的机制设置了很多规则比如存储副本leader 节点失效重新选主的时候会优先选择同机房的主节点对整个系统服务的可靠性和延时不会带来太大的影响另外机房失效时可以做五副本到三副本的降级操作保证强一致性、持续的处理能力。
主可用区的概念是为了保证在同机范围内做网络访问时最大可能地减小延时。
2. 冷热分离存储 冷热分离存储是基于分布式数据库做的成本上的优化。利用 TTL 机制在创建表的时候指定其过期时间将已经过期的数据归为冷数据做归档的存储。归档存储于 OSS 里相对于本地的在线存储极大降低了成本。与此同时 OSS 上的存储格式进行了高度压缩进一步降低了成本。
归档到 OSS 时采用了开放的格式优点在于可以对接很多开源生态比如Spark、Flink 的生态然后做分析、查询。同时其自身的查询引擎也支持快速查询在 OSS 归档的数据。
3.可观测性 PolarDB-X 的 Dashboard 集成了开源的 Prometheus 等工具做监控、告警分析当前系统的运行状态。另外还建了一套做 performance 的 insight 工具分析数据在各个节点上的分布状况以及他们在分区上的访问频率帮助用户更好地发现系统的性能瓶颈并进行调优。
四、未来往何处去
未来我们会持续在 PolarDB-X 开源版本上做更多投入。 我们会将开源的 codebase 与当前的商业版本对齐所有能力在内核层面完全开源。也会继续做更多企业级能力的增强使 PolarDB-X 完全变为企业级的分布式数据库。
全新的 HTAP 引擎使得 PolarDB-X 同时能够处理事务型和分析型的负载。另外还会做国产化适配调优实现国产化替代的工作包括深度诊断、自动化调优工具以及各种生态的对接等。
原文链接
本文为阿里云原创内容未经允许不得转载。
