DDL是结构化查问言语(StructuRedQueryLanguage,SQL)的一局部，1974年IBM钻研人员设计SQL的前身Sequel时有两个指标，准许用户经过Sequel来操纵和定义数据。过后宣布的两篇论文，一篇是广为人知的"SEQUEL:AStructuredEnglishQueryLanguage"，引见如何查问和修负数据，另一篇则专门引见了DDL，可以看出，从一开局DDL就是SQL最关键的组成局部。
随后的几十年中，学术界对DDL要处置的外围疑问形式演变(SchemaEvolution)，也就是不失落数据内容的前提下，扭转数据的定义，启动了少量钻研。当初SchemaEvolution相关钻研的结果曾经宽泛运行在相关型、对象、文档数据库产品中，其中OnlineSchemaChange（在线表结构变卦）才干曾经成为OLTP数据库的规范性能，干流单机OLTP数据库都有自己的成功。
相关型数据库中数据以表为单位存储，读写操作依赖表的形式(Schema)和数据(Data)。DDL理论须要同时修正形式和数据，为了防止并发疑问，早期的数据库成功会在DDL环节中制止指标表上的读写操作（简称锁表）。锁表保障了对形式和数据的修正是原子操作。但某些DDL操作触及复制数据（比如索引构建）口头时期或许在几分钟甚至数小时。OLTP数据库中长时期锁表会对业务发生无法预知的影响，消费环境中无法接受，因此能够与读写操作并行口头是OLTP用户对DDL的外围需求，也是OnlineSchemaChange要处置的疑问。
MySQL从5.6版本开局提供OnlineSchemaChange(OnlineDDL)个性，准许大少数DDL语句与DML并行口头。DDL口头分为_Initialization,Execution,CommitTableDefinition_三个阶段，经过MDL(MetadataLock)包全元数据，上方以CREATEINDEX为例便捷引见MySQLOnlineDDL的成功。
MySQLOnlineDDL的特点
散布式数据库理论是一个集群，出于性能思考，每个节点须要缓存一份Schema。假设继续驳回单机数据库的DDL流程，则须要经过散布式锁来保障加载新版本Schema环节中没有读写操作启动，代价极高，并且当集群内节点不能够相互感知时将变为无法成功的义务。
探讨处置打算之前，以CREATEINDEX为例，看看集群节点经常使用不同版本Schema口头读写操作，带来的详细疑问。
上图展现的是一个存储计算分别架构的散布式数据库，集群由CN(计算节点)和DN(存储节点)造成，每个CN中缓存一份Schema。因为CN0和CN1异步加载Schema，参与索引环节中或许存在一个时辰，CN0以为有索引而CN1以为没有，此时发生两种意外
可以看到，假设同一时辰存在两个Schema版本的状况无法防止，继续沿用单机数据库一步成功Schema版本切换的打算，会造成数据疑问。那么假设一步切换无法行，多步能否处置疑问？VLDB2013上Google工程师给出了一种新的SchemaChange流程，经过参与两个两边形态来处置这个疑问。
GoogleF1的打算引入了两个两边形态，delete_only形态的对象上仅口头删除操作，write_only形态的对象上支持写入，但不准许读取。依然以CREATEINDEX为例
以上两个详细场景为例，说明了打算的有效性，论文7中对全体疑问和打算做了方式化证实，网上有不少资料，团队同窗之前也有过火享，这里不再开展，只罗列论断。
GoogleF1的打算，蕴含两个关键点：
第一个关键点，将保障SchemaChange正确性的条件，从只能有一个版本，降落为最多可以有两个版本。第二个关键点，给出了F1系统保障最多两个版本的成功思绪。
便捷来说，GoogleF1的打算，成功将疑问在散布式数据库系统上成功OnlineSchemaChange转化为设计一种 保障系统中最多有两个Schema版本 的协定，并且给出了一种基于租约的协定成功。
协定内容可以概括为，以租约周期作为时期单位，协调了三个操作的节拍
原始版本的协定十分繁复，易于形容和验证，但因为将DDL口头的最小时长和事务口头的最大时长绑定在一同，经常使用体验上与单机数据库有区别。对此，业界也给出了多种改良打算，比如：
从地下资料可以看出，经常使用存储分别架构的产品对F1打算的改良关键集中在缩短DDL口头周期，DDL口头造成局部长事务被回滚的疑问并没有处置。PolarDB-X在经常使用体验上高度兼容MySQL，须要设计自己的改良协定。
回忆一下要处置的疑问， 保障系统中最多有两个Schema版本 ，隐含的意思是Schema在系统中存在多个拷贝，且每个拷贝的版本或许不同。协定要做的，就是协调每个拷贝的升级操作，给出旧版本从系统中隐没的牢靠时期点。
散布式数据库中有两个中央会缓存Schema
节点上缓存的Schema，理论由每个节点上的后盾线程定时刷新，刷新距离为一个租约周期。假设节点刷新Schema失败，则回滚一切未成功的事务，中止提供服务，直到失掉到最新版本的Schema。这样Schema从V0变卦为V1后，只要要期待一个租约周期，就可以保障一切节点要么曾经在经常使用V1版本，要么回滚了一切经常使用V0的事务，并中止提供服务。
事务中缓存的Schema版本无法升级，因此协定须要协调事务和DDL口头的顺序，确保经常使用V0版本的事务所有commit/rollback之后才继续口头V1到V2的版本变卦。也就是说，关于口头环节中有Schema版本变卦出现的事务，有两种直观的处置
GoogleF1的成功中，经过限度每个事务的最大口头时长为一个租约周期，简化判别事务完结时期的逻辑。引入租约周期的限度后，依照起止时期的不同，可以将事务分为上方几类
可以看到，F1会保障口头时期在一个租约周期内的事务T不受影响，但也影响了无DDL口头时的事务T,T同时会造成DDL口头时长也至少为一个租约周期。CockroachDB在此基础上参与了事务完结监禁租约的机制，将切换为V版本的时期限度为最后一个V版本租约的过时时期，仅当有V版本写入时才判别租约能否失效。这样缩短了DDL的口头时期，并且仅在有DDL口头时限度事务的最大口头时长。
细心剖析可以发现，租约其实有两用途，确定经常使用旧版本的事务完结和保障意外节点上经常使用旧版本的事务无法提交。PolarDB-X在节点外部参与MDL，经过持久失掉旧版本Schema上的exclusiveMDL，排空经常使用旧版本的事务，将切换为V版本的时期限度为T,T完结之后。同时，假设GMS组件确认节点意外，标志旧版本Schema失效，期待一个租约周期后可以保障意外节点上经常使用旧版本的事务无法提交。
从用户角度登程，现实OnlineSchemaChange打算应该满足上方三个特点，没有DDL流程口头时不对事务参与过多额外开支；DDL流程中，事务不会被强迫回滚；DDL的口头时期尽或许短。MySQLOnlineDDL基本合乎上述特点，而存储分别架构的产品都有一些取舍，以下从这三个角度登程，对比现有打算和PolarDB-X的成功
可以看到，PolarDB-X打算有如下特点
PolarDB-X是一个散布式HTAP数据库，驳回存储分别架构，高度兼容MySQL生态，支持OnlineSchemaChange
收到用户的DDL语句后，首先由接受语句的CN节点启动校验，并生成DDLJob提交到GlobalMetaService(GMS)的义务队列中，随后GMS通知CN节点中的DDLWorker支付义务，开局推动DDL流程和Schema版本变卦。
上图展现CREATEGLOBALINDEX的口头环节。DDLWorker动员Schema版本变卦时，首先经过GMS的Sync机制尝试通知其余几点加载新版本并排空经常使用旧版本的事务。假设GMS判定有节点意外，则期待一个租约周期后设置旧版本Schema为失效形态，继续推动Schema版本变卦。事务提交时判别节点能否反常刷新了SchemaCache，以及自己经常使用的Schema能否依然有效，假设不满足则事务回滚。
收到升级元数据版本的通知后，首先审核以后能否曾经加载了该版本的Schema，若尚未加载，加载新版本Schema，之后尝试失掉旧版本上的MDL，若失掉MDL成功，代表节点上经常使用旧版本Schema的事务曾经完结，该节点上的Schema版本变卦成功，前往成功。若失掉MDL失败（超时），前往失误，交给下层重试。
同时，事务的第一条查问口头前，失掉最新Schema版本上的MDL，目前只要S锁和X锁，经过队列保障偏心性，但不须要死锁检测等MySQLMDL的组件。MDL为内存中的锁，不落盘，节点重启时清空。
OnlineSchemaChange是HTAP数据库的必选性能。单机数据库中，Schema只要一个版本，经过加锁来防止DDL和DML并发造成数据疑问，经过增加加锁的范畴来成功OnlineSchemaChange。散布式数据库经过引入两边形态，准许同时存在至少两个Schema版本，防止加锁，支持OnlineSchemaChange的关键点转化为，设计一种节点交互协定，保障系统中至少同时存在两个Schema版本。PolarDB-X成功的协定，联合MDL和租约，不对事务口头引入额外开支；无心外节点的状况下，Schema版本变卦不影响事务口头，有数据回填的DDL操作毫秒级成功；存在意外节点时，仅阻止意外节点上的事务提交，有数据回填的DDL操作分钟级成功，与业界打算坚持分歧。OnlineSchemaChange只是PolarDB-X诸多个性中的一个，想要了解更多内容，欢迎观注群众号内的其余文章。
架构不同，性能不同。 1、架构不同：PolarDB是一种分布式关系型数据库，底层采用了多副本共享存储架构，而MySQL则是一种传统的关系型数据库，底层采用了基于磁盘的存储架构。 2、性能不同：PolarDB的多副本共享存储架构可以提供更高的性能和更快的响应时间，同时还支持自动扩容和缩容，而MySQL的性能则主要取决于硬件配置和数据库优化。
标签： MySQL、 数据库、 SQL、本文地址： https://yihaiquanyi.com/article/4260ff0c056326e1c024.html
上一篇：优化IPC探讨CPU性能的关键起因优化iPhone储...
网站首页
提交收录
收录查询
文章资讯
热门排行
软文发布
自助广告
