几千万记录,数据库表结构如何平滑变更?
继续回答知识星球水友提问。 问题域:数据量大、并发量高场景,如何在流量低峰期,平滑实施表结构变更? 画外音,一般来说,是指增加表的属性,因为:
首先,一起看下有哪些常见方案。 (1) 方案一:在线修改表结构。 画外音:alter table add column 数据量大的情况下,锁表时间会较长,造成拒绝服务,一般不可行。 (2) 方案二:通过增加表的方式扩展属性,通过外键join来查询。 举个例子,对:
想要扩展属性,可以通过增加一个表实现:
数据量大的情况下,join性能较差,一般不可行。 (3) 方案三,通过增加表的方式扩展,通过视图来屏蔽底层复杂性。 同上,视图效率较低,一般不使用视图。 画外音:至少58到家禁止使用视图。 (4) 方案四,揍产品经理,阻止她修改需求。... (5) 方案五,提前预留一些reserved字段,加列可复用这些字段。 这个方案可行,但如果预留过多,会造成空间浪费。 (6) 方案六,pt-online-schema-change 对于MySQL而言,这是目前比较成熟的方案,被广大公司所使用。 画外音:我呆过的互联网公司,数据库均使用MySQL。 下面仍以用户表扩展为例,说下这个工具内部的原理与步骤。 假设:
要扩展到:
第一步,先创建一个扩充字段后的新表:
画外音:就是被扩展后的表。 第二步,在原表user上创建三个触发器,对原表user进行的所有insert/delete/update操作,都会对新表user_new进行相同的操作; 第三步,分批将原表user中的数据insert到新表user_new,直至数据迁移完成; 第四步,删掉触发器,把原表移走(默认是drop掉); 第五步,把新表user_new重命名(rename)成原表user; 扩充字段完成,整个过程不需要锁表,可以持续对外提供服务。 操作过程中需要注意:
pt-online-schema-change是DBA必备的利器,比较成熟,在互联网公司使用广泛,要了解更详细的细节,亦可以Google一下。 任何脱离业务的架构设计都是耍流氓。 【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】 戳这里,看该作者更多好文 【编辑推荐】
点赞 0 (编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |