1万属性，100亿数据，每秒10万吞吐，架构如何设计？

有一类业务场景，没有固定的schema存储，却有着海量的数据行数，架构上如何来实现这类业务的存储与检索呢?58最核心的数据“帖子”的架构实现技术细节，今天和大家聊一聊。

一、背景描述及业务介绍

什么是58最核心的数据?

58是一个信息平台，有很多垂直品类：招聘、房产、二手物品、二手车、黄页等等，每个品类又有很多子品类，不管哪个品类，最核心的数据都是“帖子信息”。

画外音：像不像一个大论坛?

各分类帖子的信息有什么特点?

逛过58的朋友很容易了解到，这里的帖子信息：

• 各品类的属性千差万别，招聘帖子和二手帖子属性完全不同，二手手机和二手家电的属性又完全不同，目前恐怕有近万个属性;
• 数据量巨大，100亿级别;
• 每个属性上都有查询需求，各组合属性上都可能有组合查询需求，招聘要查职位/经验/薪酬范围，二手手机要查颜色/价格/型号，二手要查冰箱/洗衣机/空调;
• 吞吐量很大，每秒几10万吞吐;

如何解决100亿数据量，1万属性，多属性组合查询，10万并发查询的技术难题呢?一步步来。

二、最容易想到的方案

每个公司的发展都是一个从小到大的过程，撇开并发量和数据量不谈，先看看

• 如何实现属性扩展性需求;
• 多属性组合查询需求;

画外音：公司初期并发量和数据量都不大，必须先解决业务问题。

如何满足业务的存储需求呢?

最开始，业务只有一个招聘品类，那帖子表可能是这么设计的：

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); 

在业务各异，数据量和吞吐量都巨大的情况下，垂直拆分会遇到什么问题呢?

这些表，以及对应的服务维护在不同的部门，看上去各业务灵活性强，研发闭环，这恰恰是悲剧的开始：

• tid如何规范?
• 属性如何规范?
• 按照uid来查询怎么办(查询自己发布的所有帖子)?
• 按照时间来查询怎么办(最新发布的帖子)?
• 跨品类查询怎么办(例如首页搜索框)?
• 技术范围的扩散，有的用mongo存储，有的用mysql存储，有的自研存储;
• 重复开发了不少组件;
• 维护成本过高;
• …

画外音：想想看，电商的商品表，不可能一个类目一个表的。

四、58的玩法：三大中心服务

第一：统一帖子中心服务

平台型创业型公司，可能有多个品类，各品类有很多异构数据的存储需求，到底是分还是合，无需纠结：基础数据基础服务的统一，是一个很好的实践。

画外音：这里说的是平台型业务。

如何将不同品类，异构的数据统一存储起来呢?

• 全品类通用属性统一存储;
• 单品类特有属性，品类类型与通用属性json来进行存储;

更具体的：

tiezi(tid, uid, time, title, cate, subcate, xxid, ext); 

• 一些通用的字段抽取出来单独存储;
• 通过cate, subcate, xxid等来定义ext是何种含义;
• 通过ext来存储不同业务线的个性化需求

例如：

招聘的帖子，ext为：

{“job”:”driver”,”salary”:8000,”location”:”bj”} 

而二手的帖子，ext为：

{”type”:”iphone”,”money”:3500} 

帖子数据，100亿的数据量，分256库，通过ext存储异构业务数据，使用mysql存储，上层架了一个帖子中心服务，使用memcache做缓存，就是这样一个并不复杂的架构，解决了业务的大问题。这是58最核心的帖子中心服务IMC(Info Management Center)。

画外音：该服务的底层存储在16年全面切换为了自研存储引擎，替换了mysql，但架构理念仍未变。

（编辑：ASP站长网）