100亿数据1万属性数据架构设计.pdfVIP

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 ）多属性组合查询需求 开始，可能只有⼀个招聘品类，那帖⼦表可能是这么设计的： tie i(tid ,uid , c 1, c2, c3) 那如何满⾜各属性之间的组合查询需求呢？ 容易想到的是通过组合索引： index_ 1(c 1,c2) index_2(c2, c3) index_3(c 1, c3) 随着业务的发展，又新增了⼀个房产类别，新增了若⼲属性，新增了若⼲组合查询， 于是帖⼦表变成了： tie i(tid ,uid , c 1, c2, c3, c 10 , c 11, c 12, c 13) 其中c 1,c2,c3是招聘类别属性，c 10 ,c 11,c 12,c 13是房产类别属性，这两块属性⼀般没有 组合查询需求 但为了满⾜房产类别的查询需求，又要建⽴了若⼲组合索引 （不敢想有多少个索引能 覆盖所有两属性查询，三属性查询） 是不是发现玩不下去了？ 三、友商的玩法 新增属性是⼀种扩展⽅式，新增表也是⼀种⽅式，有友商是这么玩的，按照业务进⾏ 垂直拆分： tie i_ haopin(tid ,uid , c 1, c2, c3) tie i_fangchan(tid ,uid , c 10 , c 11, c 12, c 13) 这些表，这些服务维护在不同的部门，不同的研发同学⼿⾥，看上去各业务线灵活性 强，这恰恰是悲剧的开始： （1）tid如何规范？ （2 ）属性如何规范？ （3 ）按照uid来查询怎么办 （查询⾃⼰发布的所有帖⼦）？ （4 ）按照时间来查询怎么办 （ 新发布的帖⼦）？ （5 ）跨品类查询怎么办 （例如⾸页有哪些信誉好的足球投注网站框）？ （6 ）技术范围的扩散，有的⽤mongo存储，有的⽤mysql存储，有的⾃研存储 （7 ）重复开发了不少组件 （8 ）维护成本过⾼ （9 ）… 想想看，电商的商品表，不可能⼀个类⽬⼀个表的。 四、58 同城的玩法 【统⼀帖⼦中⼼服务】 平台型创业型公司，可能有多个品类，例如58同城的招聘房产⼆⼿，很多异构数据的 存储需求，到底是分还是合，⽆需纠结：基础数据基础服务的统⼀，⽆疑是58同城技 术路线发展roadmap上 正确的决策之⼀，把这个⽅针坚持下来，@⽼崔 @晓飞 这些 ⾼瞻远瞩的先贤功不可没，业务线会有“扩展性”“灵活性”上的微词，后⽂看看先贤们 如何通过⼀些巧妙的技术⽅案来解决的。 如何将不同品类，异构的数据统⼀存储起来，采⽤的就是类似version+ext的⽅式