| 失效链接处理 |
|
100亿数据1万属性数据架构设计 PDF 下载
本站整理下载：
提取码：bl1m
相关截图：
主要内容：
对于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）…
想想看，电商的商品表，不可能一个类目一个表的。
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
