【58沈剑架构系列】啥,又要为表增加一列属性?
2018-01-15 10:56
211 查看
需求缘起
产品第一版:用户有用户名、密码、昵称等三个属性,对应表设计:
user(uid, name, passwd, nick)
第二版,产品经理增加了年龄,性别两个属性,表结构可能要变成:
user(uid, name, passwd, nick, age, sex)
假设数据量和并发量比较大,怎么变?
(1)alter table add column?不太可行,锁表时间长
(2)新表+触发器?如果数据量太大,新表不一定装得下,何况触发器对数据库性能的影响比较高
(3)让dba来搞?新表,迁移数据,一致性校验,rename?dba真苦逼
今天分享2个列扩展性设计上几个小技巧,只占大伙1分钟(下班太晚的话,只能写一分钟系列=_=)
方案一:版本号+通用列
以上面的用户表为例,假设只有uid和name上有查询需求,表可以设计为
user(uid, name, version, ext)
(1)uid和name有查询需求,必须设计为单独的列并建立索引
(2)version是版本号字段,它对ext进行了版本解释
(3)ext采用可扩展的字符串协议载体,承载被查询的属性
例如,最开始上线的时候,版本为0,此时只有passwd和nick两个属性,那么数据为:
当产品经理需要扩展属性时,新数据将版本变为1,此时新增了age和sex两个数据,数据变为:
优点:
(1)可以随时动态扩展属性
(2)新旧两种数据可以同时存在
(3)迁移数据方便,写个小程序将旧版本ext的改为新版本的ext,并修改version
不足:
(1)ext里的字段无法建立索引
(2)ext里的key值有大量冗余,建议key短一些
改进:
(1)如果ext里的属性有索引需求,可能Nosql的如MongoDB会更适合
方案二:通过扩展行的方式来扩展属性
以上面的用户表为例,可以设计为
user(uid, key, value)
初期有name, passwd, nick三个属性,那么数据为:
未来扩展了age和sex两个属性,数据变为:
优点:
(1)可以随时动态扩展属性
(2)新旧两种数据可以同时存在
(3)迁移数据方便,写个小程序可以将新增的属性加上
(4)各个属性上都可以查询
不足:
(1)key值有大量冗余,建议key短一些
(2)本来一条记录很多属性,会变成多条记录,行数会增加很多
总结
可以通过“version+ext”或者“key+value”的方式来满足产品新增列的需求,希望没有浪费你这一分钟,有收获就好。
【文章转载自微信公众号“架构师之路”】
产品第一版:用户有用户名、密码、昵称等三个属性,对应表设计:
user(uid, name, passwd, nick)
第二版,产品经理增加了年龄,性别两个属性,表结构可能要变成:
user(uid, name, passwd, nick, age, sex)
假设数据量和并发量比较大,怎么变?
(1)alter table add column?不太可行,锁表时间长
(2)新表+触发器?如果数据量太大,新表不一定装得下,何况触发器对数据库性能的影响比较高
(3)让dba来搞?新表,迁移数据,一致性校验,rename?dba真苦逼
今天分享2个列扩展性设计上几个小技巧,只占大伙1分钟(下班太晚的话,只能写一分钟系列=_=)
方案一:版本号+通用列
以上面的用户表为例,假设只有uid和name上有查询需求,表可以设计为
user(uid, name, version, ext)
(1)uid和name有查询需求,必须设计为单独的列并建立索引
(2)version是版本号字段,它对ext进行了版本解释
(3)ext采用可扩展的字符串协议载体,承载被查询的属性
例如,最开始上线的时候,版本为0,此时只有passwd和nick两个属性,那么数据为:
当产品经理需要扩展属性时,新数据将版本变为1,此时新增了age和sex两个数据,数据变为:
优点:
(1)可以随时动态扩展属性
(2)新旧两种数据可以同时存在
(3)迁移数据方便,写个小程序将旧版本ext的改为新版本的ext,并修改version
不足:
(1)ext里的字段无法建立索引
(2)ext里的key值有大量冗余,建议key短一些
改进:
(1)如果ext里的属性有索引需求,可能Nosql的如MongoDB会更适合
方案二:通过扩展行的方式来扩展属性
以上面的用户表为例,可以设计为
user(uid, key, value)
初期有name, passwd, nick三个属性,那么数据为:
未来扩展了age和sex两个属性,数据变为:
优点:
(1)可以随时动态扩展属性
(2)新旧两种数据可以同时存在
(3)迁移数据方便,写个小程序可以将新增的属性加上
(4)各个属性上都可以查询
不足:
(1)key值有大量冗余,建议key短一些
(2)本来一条记录很多属性,会变成多条记录,行数会增加很多
总结
可以通过“version+ext”或者“key+value”的方式来满足产品新增列的需求,希望没有浪费你这一分钟,有收获就好。
【文章转载自微信公众号“架构师之路”】
相关文章推荐
- 【58沈剑架构系列】100亿数据1万属性数据架构设计
- 【58沈剑架构系列】微服务架构多“微”才合适?
- 【58沈剑架构系列】微服务架构之RPC-client序列化细节
- 啥,又要为表增加一列属性?
- 【58沈剑架构系列】mysql并行复制优化思路
- 【58沈剑架构系列】如何实施异构服务器的负载均衡及过载保护?
- 【58沈剑架构系列】缓存架构设计细节二三事
- 【58沈剑架构系列】DB主从一致性架构优化4种方法
- 【58沈剑架构系列】互联网公司为啥不使用mysql分区表?
- 【58沈剑架构系列】秒杀系统架构优化思路
- 【58沈剑架构系列】这才是真正的表扩展方案
- 【58沈剑架构系列】细聊冗余表数据一致性
- 【58沈剑架构系列】细聊分布式ID生成方法
- 数据库表扩展技巧(啥,又要为表增加一列属性?)续
- 【58沈剑架构系列】究竟啥才是互联网架构“高并发”
- 【58沈剑架构系列】缓存与数据库一致性保证
- 【58沈剑架构系列】即使删了全库,保证半小时恢复
- 【58沈剑架构系列】RPC-client异步收发核心细节?
- 【58沈剑架构系列】TCP接入层的负载均衡、高可用、扩展性架构 -- IM teamtalk项目是这样的
- 【58沈剑架构系列】数据库架构设计的一切