这才是真正的表扩展方案

事情变得有意思了,上一篇花1小时撰写的“一分钟”文章,又引起了广泛的讨论,说明相关的技术大家感兴趣,挺好。第一次一篇技术文章的评论量过100,才知道原来“评论精选”还有100上限,甚为欣慰(虽然是以一种自己不愿看到的方式)。

啥,又要为表增加一列属性?》的方案颇有争议:

(1)版本号version + 扩展字段ext

(2)用增加列的key+value方式扩充属性

有些评论,只能说“所谓夏虫,何以语冰”(作者要谦和,请删除)。因自己时间仓促,有些地方没有交代清楚,对不起大伙,实在抱歉。大部分评论还是在进行技术讨论,故今天再熬夜补充说明一下。

零、缘起

讨论问题域:

(1)数据量大、并发量高场景,在线数据库属性扩展

(2)数据库表结构扩展性设计

一、哪些方案一定是不行的

(1)alter table add column

要坚持这个方案的,也不多解释了,大数据高并发情况下,一定不可行

(2)通过增加表的方式扩展,通过外键join来查询

大数据高并发情况下,join性能较差,一定不可行

(3)通过增加表的方式扩展,通过视图来对外

一定不可行。大数据高并发情况下,互联网不怎么使用视图,至少58禁止使用视图

(4)必须遵循“第x范式”的方案

一定不可行。互联网的主要矛盾之一是吞吐量,为了保证吞吐量甚至可能牺牲一些事务性和一致性,通过反范式的方式来确保吞吐量的设计是很常见的,例如:冗余数据。互联网的主要矛盾之二是可用性,为了保证可用性,常见的技术方案也是数据冗余。在互联网数据库架构设计中,第x范式真的没有这么重要

(5)打产品经理

朋友,这是段子么,这一定不可行

二、哪些方案可行,但文章未提及

(1)提前预留一些reserved字段

这个是可以的。但如果预留过多,会造成空间浪费,预留过少,不一定达得到扩展效果。

(2)通过增加表的方式扩展列,上游通过service来屏蔽底层的细节

这个也是可以的。Jeff同学提到的UserExt(uid, newCol1, newCol2)就是这样的方案(但join连表和视图是不行的)

三、哪些读者没有仔细看文章

(1)version+ext太弱了,ext不支持索引

回复:属于没有仔细看文章,文章也提了如果有强需求索引可以使用MongoDB,它就是使用的json存储(评论中有不少朋友提到,还有其他数据库支持json检索)

(2)第二种key+value方案不支持索引

回复:uid可以索引

四、key+value方式使用场景

服务端,wordpress,EAV,配置,统计项等都经常使用这个方案。

客户端(APP或者PC),保存个人信息也经常使用这个方案。

今天的重点

以楼主性格,本不会进行“解释”,上文解释这般,说明这一次,楼主真的认真了。对于技术,认真是好事,认真的男人最可爱(打住,我要吐了)。好了,下面的内容才是今天的重点。

五、在线表结构变更

在《啥,又要为表增加一列属性?》文章的开头,已经说明常见“新表+触发器+迁移数据+rename”方案(pt-online-schema-change),这是业内非常成熟的扩展列的方案(以为大伙都熟悉,没有展开讲,只重点讲了两种新方案,这可能是导致被喷得厉害的源头),今天补充说一下。

user(uid, name, passwd)

扩展到user(uid, name, passwd, age, sex)为例

基本原理是:

(1)先创建一个扩充字段后的新表user_new(uid, name, passwd, age, sex)

(2)在原表user上创建三个触发器,对原表user进行的所有insert/delete/update操作,都会对新表user_new进行相同的操作

(3)分批将原表user中的数据insert到新表user_new,直至数据迁移完成

(4)删掉触发器,把原表移走(默认是drop掉)

(5)把新表user_new重命名(rename)成原表user

扩充字段完成。

优点:整个过程不需要锁表,可以持续对外提供服务

操作过程中需要注意

(1)变更过程中,最重要的是冲突的处理,一条原则,以触发器的新数据为准,这就要求被迁移的表必须有主键(这个要求基本都满足)

(2)变更过程中,写操作需要建立触发器,所以如果原表已经有很多触发器,方案就不行(互联网大数据高并发的在线业务,一般都禁止使用触发器)

(3)触发器的建立,会影响原表的性能,所以这个操作建议在流量低峰期进行

pt-online-schema-change是DBA必备的利器,比较成熟,在互联网公司使用广泛。

楼主非专业的dba,上面的过程有说的不对的地方,欢迎指出。要了解更详细的细节,可以百度一下。有更好的方法,也欢迎讨论,后续会梳理汇总share给更多的朋友。

六、结束

欢迎用批判的眼光看问题,欢迎任何友善的技术讨论,不太欢迎“纯属误导”“非常蠢的方案”这样的评论(但我还是会加精选,任何人都有发声的权利)。

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2016-12-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏vue+shiro

基于vue(element ui) + ssm + shiro 的权限框架

现在的Java世界,各种资源很丰富,不得不说,从分布式,服务化,orm,再到前端控制,权限等等玲琅满目,网上有句话说,语言框架迭代太快了,我学不动了,不如回去搬...

9312
来自专栏杨建荣的学习笔记

DBA和开发同事的代沟(二)(r7笔记第18天)

参考:DBA和开发同事的一些代沟(一)(r7笔记第17天) 有些朋友给我反馈了他们遇到的小故事,我后续再整理整理,看看有多少。 我还是继续来分享我这边碰到的一些...

3313
来自专栏逸鹏说道

.NET技术+25台服务器怎样支撑世界第54大网站

英文原文:StackOverflow Update: 560M Pageviews A Month, 25 Servers, And It's All Abou...

3897
来自专栏CSDN技术头条

.NET技术+25台服务器怎样支撑世界第54大网站

【编者按】StackOverflow是一个IT技术问答网站,用户可以在网站上提交和回答问题。当下的StackOverflow已拥有400万个用户,4000万个回...

2477
来自专栏杨建荣的学习笔记

宕机的那些事儿(r12笔记第44天)

DBA干了这么多年,一直以来有一个疑惑,那就是从半夜的电话中吵醒时,几乎清一色都是宕机类问题,每次我就忍不住想喊,大早上宕机,让不让人睡觉了。但是抱怨归抱怨...

4149
来自专栏知晓程序

玩腻了传纸条、漂流瓶,就用它来跟网友分享「小卡片」吧

今天,知晓程序(微信号 zxcx0101)就为你推荐一款有毒的小程序「一起 Up」,在里面,你不仅可以看到其他用户分享的有趣、有内涵的内容,还能将自己的私货与其...

874
来自专栏北京马哥教育

25台服务器怎样支撑世界第54大网站

摘要:同时使用Linux和Windows平台产品,大量使用静态的方法和类,Stack Overflow是个重度性能控。同时,取代横向扩展,他们坚持着纵向扩展思路...

7119
来自专栏陈满iOS

iOS面试经验总结(某PA金融科技篇)

也许面试官自己也没自己实现过,毕竟有些东西苹果为什么这样设计,若不是苹果公司的工程师无法知道。

1213
来自专栏阮一峰的网络日志

防止网页被嵌入框架的代码

最近,国内开始流行另一种流氓行为:使用框架(Frame),将你的网页嵌入它的网页中。 比如,有一家网站号称自己是"口碑聚合门户",提供全国各个网上论坛的精华内容...

3364
来自专栏张尧博客

10个Linux基础面试问题和答案(1)

3287

扫码关注云+社区

领取腾讯云代金券