这才是真正的表扩展方案

原创 2017年11月12日 08:29:46

零、缘起

讨论问题域:

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

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

 

一、哪些方案一定是不行

1alter table add column

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

 

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

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

 

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

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

 

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

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


(5)打产品经理

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

 

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

1提前预留一些reserved字段

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

 

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

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

 

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

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

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

 

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

回复:uid可以索引

 

四、key+value方式使用场景

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

客户端(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-changeDBA必备的利器,比较成熟,在互联网公司使用广泛。


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

版权声明:本文为博主原创文章,未经博主允许不得转载。

这才是真正的表扩展方案

事情变得有意思了,上一篇花1小时撰写的“一分钟”文章,又引起了广泛的讨论,说明相关的技术大家感兴趣,挺好。第一次一篇技术文章的评论量过100,才知道原来“评论精选”还有100上限,甚为欣慰(虽然是以一...
  • Flood_Dragon
  • Flood_Dragon
  • 2016年12月21日 08:59
  • 422

2014---努力才是真天赋

不是: “大多数人的努力程度之低,根本轮不到拼天赋的地步” 而是: “大多数人的天赋之低,根本就不知道去努力”...
  • linxi1209163com
  • linxi1209163com
  • 2014年08月28日 09:23
  • 861

告诉你什么才是真正的生活

在一个充满仇恨的世界,我们仍然要满怀希望;在一个充满绝望的世界,我们仍然要敢于梦想。   如果你要送我礼物,我要你上衣的第二颗纽扣,因为那是靠你心脏最近的地方。   当我说“我很好”时,我希望...
  • xiaoyecanfeng
  • xiaoyecanfeng
  • 2011年10月07日 13:23
  • 271

天天说需求,你真的理解需求吗?

之前参加阿里巴巴的线上笔试,又接触了几道考察产品能力的题目,颇有感想。这几天,静下心来,决定谈一谈关于产品三要素问题,希望给那些想要互联网创业的人一些启示。 今天,先说一下产品的基础—-需求。 如...
  • liu94457
  • liu94457
  • 2015年08月27日 19:18
  • 280

37 《这才是心理学》 -豆瓣评分9.0

《这才是心理学》 【 可证伪性是科学心理学的重要标准,伪心理学的惯用伎俩之一就是不可证伪。】         如今各种伪心理学的论调充斥了我们的生活,而这一切源于我们对科学心理学的误解。本期音频,...
  • czg13548930186
  • czg13548930186
  • 2017年07月05日 19:56
  • 642

这才是真正的“匈牙利命名法”

   从刚进大学开始学习 C 语言,就听说了实际开发中会用到的各种变量命名方法,例如常见的匈牙利命名法、骆驼命名法、Pascal 命名法等。 后来自己真正开始用 C/C++ 写程...
  • tyy_ing
  • tyy_ing
  • 2013年12月06日 16:56
  • 316

这才是真正的强者

真正的强者,不是默默流泪的人,而是含泪奔跑的人真正的强者,不是默默流泪的人,而是含泪奔跑的人 以前的我已经死了,现在的我又是另一个人…… 我的观念改变了,我现在才知道,原来我的想法是错误的,最后的结果...
  • n65193481
  • n65193481
  • 2011年04月25日 23:32
  • 40

这才是真正的synchronized

对于synchronized,想必是基础中的基础了,但是我们在使用时,还是会有一些模棱两可的地方,作为一个android程序员,对于java知识决不能只是够用即可,需要向深处挖掘,好了,在这里先要明确...
  • lao_qiang
  • lao_qiang
  • 2017年03月29日 16:02
  • 237

这才是真正的分布式锁

昨晚十点下班,回家花了1个小时写了一篇《一分钟实现分布式锁》,引起读者一些反响,有些朋友反馈“setnx算什么方案”,“没有考虑超时”,“为啥不用zookeeper”,有甚者上升到 “质疑58同城的技...
  • DINGYANG0315
  • DINGYANG0315
  • 2017年12月15日 09:14
  • 82

有才而性缓,有智而气和

“有才而性缓,定属大才;有智而气和,斯为大智。”——弘一法师 这句话的大抵意思是:有才华而能性情平和处世冷静,是大才;满腹谋略而能气定神闲处理人事,是大智。芸芸众生,我们都是普通的聪明人,一生追求甚...
  • icloudmedia
  • icloudmedia
  • 2017年02月27日 14:58
  • 220
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:这才是真正的表扩展方案
举报原因:
原因补充:

(最多只允许输入30个字)