需求缘起
产品第一版：用户有用户名、密码、昵称等三个属性,对应表设计：
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”的方式来满足产品新增列的需求，希望没有浪费你这一分钟，有收获就好。
这才是真正的表扩展方案
事情变得有意思了，上一篇花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给更多的朋友。
六、结束
欢迎用批判的眼光看问题，欢迎任何友善的技术讨论，不太欢迎“纯属误导”“非常蠢的方案”这样的评论（但我还是会加精选，任何人都有发声的权利）。
借评论中@张九云 朋友的一句话“不要以为自己见过的就是全世界，任何方案都有使用场景，一切都是tradeoff”作为今天的结尾，谢谢大家的支持，感谢大家。
100亿数据1万属性数据架构设计
一分钟系列之《啥，又要为表增加一列属性？》分享了两种数据库属性扩展思路，被喷得厉害。
第二天补充了一篇《这才是真正的表扩展方案》，分享了互联网大数据高并发情况下，数据库属性扩容的成熟工具及思路。
对于version + ext方案，还是有很多朋友质疑“线上不可能这么用”。
本篇将讲述一下58同城最核心的数据“帖子”的架构实现技术细节，说明不仅不是“不可能这么用”，而是大数据，可变属性，高吞吐场景下的“常用手段”。
一、背景描述及业务介绍
问：什么是数据库扩展的version + ext方案？
使用ext来承载不同业务需求的个性化属性，使用version来标识ext里各个字段的含义。
例如上述user表：
verion=0表示ext里是passwd/nick
version=1表示ext里是passwd/nick/age/sex
优点？
（1）可以随时动态扩展属性，扩展性好
（2）新旧两种数据可以同时存在，兼容性好
不足？
（1）ext里的字段无法建立索引
（2）ext里的key值有大量冗余，建议key短一些
问：什么是58同城最核心的数据？
58同城是一个信息平台，有很多垂直品类：招聘、房产、二手物品、二手车、黄页等等，每个品类又有很多子品类，不管哪个品类，最核心的数据都是“帖子信息”（业务像一个大论坛？）。
问：帖子信息有什么特点？
大家去58同城的首页上看看就知道了：
（1）每个品类的属性千差万别，招聘帖子和二手帖子属性完全不同，二手手机和二手家电的属性又完全不同，目前恐怕有近万个属性
（2）帖子量很大，100亿级别
（3）每个属性上都有查询需求（各组合属性上都可能有组合查询需求），招聘要查职位/经验/薪酬范围，二手手机要查颜色/价格/型号，二手要查冰箱/洗衣机/空调
（4）查询量很大，每秒几10万级别
如何解决100亿数据量，1万属性，多属性组合查询，10万并发查询的技术难题，是今天要讨论的内容。
二、最容易想到的方案
每个公司的发展都是一个从小到大的过程，撇开并发量和数据量不谈，先看看
（1）如何实现属性扩展性需求
（2）多属性组合查询需求
最开始，可能只有一个招聘品类，那帖子表可能是这么设计的：
tiezi(tid,uid, c1, c2, c3)
那如何满足各属性之间的组合查询需求呢？最容易想到的是通过组合索引：
index_1(c1,c2) index_2(c2, c3) index_3(c1, c3)
随着业务的发展，又新增了一个房产类别，新增了若干属性，新增了若干组合查询，于是帖子表变成了：
tiezi(tid,uid, c1, c2, c3, c10, c11, c12, c13)
其中c1,c2,c3是招聘类别属性，c10,c11,c12,c13是房产类别属性，这两块属性一般没有组合查询需求
但为了满足房产类别的查询需求，又要建立了若干组合索引（不敢想有多少个索引能覆盖所有两属性查询，三属性查询）
是不是发现玩不下去了？
三、友商的玩法
新增属性是一种扩展方式，新增表也是一种方式，有友商是这么玩的，按照业务进行垂直拆分：
tiezi_zhaopin(tid,uid, c1, c2, c3)
tiezi_fangchan(tid,uid, c10, c11, c12, c13)
这些表，这些服务维护在不同的部门，不同的研发同学手里，看上去各业务线灵活性强，这恰恰是悲剧的开始：
（1）tid如何规范？
（2）属性如何规范？
（3）按照uid来查询怎么办（查询自己发布的所有帖子）？
（4）按照时间来查询怎么办（最新发布的帖子）？
（5）跨品类查询怎么办（例如首页搜索框）？
（6）技术范围的扩散，有的用mongo存储，有的用mysql存储，有的自研存储
（7）重复开发了不少组件
（8）维护成本过高
（9）…
想想看，电商的商品表，不可能一个类目一个表的。
四、58同城的玩法
- 【统一帖子中心服务】
平台型创业型公司，可能有多个品类，例如58同城的招聘房产二手，很多异构数据的存储需求，到底是分还是合，无需纠结：
基础数据基础服务的统一，无疑是58同城技术路线发展roadmap上最正确的决策之一，
把这个方针坚持下来，@老崔 @晓飞 这些高瞻远瞩的先贤功不可没，
业务线会有“扩展性”“灵活性”上的微词，后文看看先贤们如何通过一些巧妙的技术方案来解决的。
如何将不同品类，异构的数据统一存储起来，采用的就是类似version+ext的方式：
tiezi(tid,uid, time, title, cate, subcate, xxid, ext)
（1）一些通用的字段抽取出来单独存储
（2）通过cate, subcate, xxid等来定义ext是何种含义（和version有点像？）
（3）通过ext来存储不同业务线的个性化需求
例如招聘的帖子：
ext : {“job”:”driver”,”salary”:8000,”location”:”bj”}
而二手的帖子：
ext : {”type”:”iphone”,”money”:3500}
58同城最核心的帖子数据，100亿的数据量，分256库，异构数据mysql存储，上层架了一个服务，使用memcache做缓存，就是这样一个简单的架构，一直坚持这这么多年。
上层的这个服务，就是58同城最核心的统一服务IMC（Imformation Management Center），注意这个最核心，是没有之一。
解决了海量异构数据的存储问题，遇到的新问题是：
（1）每条记录ext内key都需要重复存储，占据了大量的空间，能否压缩存储
（2）cateid已经不足以描述ext内的内容，品类有层级，深度不确定，ext能否具备自描述性
（3）随时可以增加属性，保证扩展性
- 【统一类目属性服务】
每个业务有多少属性，这些属性是什么含义，值的约束等揉不到帖子服务里，怎么办呢？
58同城的先贤们抽象出一个统一的类目、属性服务，单独来管理这些信息，而帖子库ext字段里json的key，统一由数字来表示，减少存储空间。
如上图所示，json里的key不再是”salary” ”location” ”money” 这样的长字符串了，取而代之的是数字1,2,3,4，这些数字是什么含义，属于哪个子分类，值的校验约束，统一都存储在类目、属性服务里。
这个表里对帖子中心服务里ext字段里的数字key进行了解释：
1代表job，属于招聘品类下100子品类，其value必须是一个小于32的[a-z]字符
4代表type，属于二手品类下200子品类，其value必须是一个short
这样就对原来帖子表ext里的
ext : {“1”:”driver”,”2”:8000,”3”:”bj”}
ext : {”4”:”iphone”,”5”:3500}
key和value都做了统一约束。
除此之外，如果ext里某个key的value不是正则校验的值，而是枚举值时，需要有一个对值进行限定的枚举表来进行校验：
这个枚举校验，说明key=4的属性（对应属性表里二手，手机类型字段），其值不只是要进行“short类型”校验，而是value必须是固定的枚举值。
ext : {”4”:”iphone”,”5”:3500} 这个ext就是不合法的（key=4的value=iphone不合法），
合法的应该为 ext : {”4”:”5”,”5”:3500}
此外，类目属性服务还能记录类目之间的层级关系：
（1）一级类目是招聘、房产、二手…
（2）二手下有二级类目二手家具、二手手机…
（3）二手手机下有三级类目二手iphone，二手小米，二手三星…
（4）…
协助解释58同城最核心的帖子数据，描述品类层级关系，保证各类目属性扩展性，保证各属性值合理性校验，就是58同城另一个统一的核心服务CMC（Category Management Center）。
多提一句，类目、属性服务像不像电商系统里的SKU扩展服务？
（1）品类层级关系，对应电商里的类别层级体系
（2）属性扩展，对应电商里各类别商品SKU的属性
（3）枚举值校验，对应属性的枚举值，例如颜色：红，黄，蓝
解决了key压缩，key描述，key扩展，value校验，品类层级的问题，
还有这样的一个问题没有解决：每个品类下帖子的属性各不相同，查询需求各不相同，如何解决100亿数据量，1万属性的查询需求，是58同城面临的新问题。
- 【统一检索服务】
数据量很大的时候，不同属性上的查询需求，不可能通过组合索引来满足所有查询需求，怎么办呢？
58同城的先贤们，从一早就确定了“外置索引，统一检索服务”的技术路线：
（1）数据库提供“帖子id”的正排查询需求
（2）所有非“帖子id”的个性化检索需求，统一走外置索引
元数据与索引数据的操作遵循：
（1）对帖子进行tid正排查询，直接访问帖子服务
（2）对帖子进行修改，帖子服务通知检索服务，同时对索引进行修改
（3）对帖子进行复杂查询，通过检索服务满足需求
这个扛起58同城80%终端请求（不管来自PC还是APP，不管是主页、城市页、分类页、列表页、详情页，很可能这个请求最终会是一个检索请求）的服务，就是58同城另一个统一的核心服务E-search，
这个搜索引擎的每一行代码都来自58同城@老崔 @老龚 等先贤们，目前系统维护者，就是“架构师之路”里屡次提到的@龙神 。
对于这个服务的架构，简单展开说明一下：
为应对100亿级别数据量、几十万级别的吞吐量，业务线各种复杂的复杂检索查询，扩展性是设计重点：
（1）统一的Java代理层集群，其无状态性能够保证增加机器就能扩充系统性能
（2）统一的合并层C服务集群，其无状态性也能够保证增加机器就能扩充系统性能
（3）搜索内核检索层C服务集群，服务和索引数据部署在同一台机器上，服务启动时可以加载索引数据到内存，请求访问时从内存中load数据，访问速度很快
（3.1）为了满足数据容量的扩展性，索引数据进行了水平切分，增加切分份数，就能够无限扩展性能
（3.2）为了满足一份数据的性能扩展性，同一份数据进行了冗余，理论上做到增加机器就无限扩展性能
系统时延，100亿级别帖子检索，包含请求分合，拉链求交集，从merger层均可以做到10ms返回。
58同城的帖子业务，一致性不是主要矛盾，E-search会定期全量重建索引，以保证即使数据不一致，也不会持续很长的时间。
五、总结
文章写了很长，最后做一个简单总结，面对100亿数据量，1万列属性，10万吞吐量的业务需求，58同城的经验，是采用了元数据服务、属性服务、搜索服务来解决的。
再回到文首version + ext的方案，希望朋友有新的收获和感触，帮转哈