1万属性，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); 

其中：

通过扩展属性，可以解决存储的问题。

首先，跨业务属性一般没有组合查询需求。只能建立了若干组合索引，满足房产类别的查询需求。

当业务越来越多时，是不是发现玩不下去了？

新增属性是一种扩展方式，新增表也是一种方式，垂直拆分也是常见的存储扩展方案。

可以这么玩：

tiezi_zhaopin(tid, uid, c1, c2, c3);

tiezi_fangchan(tid, uid, c10, c11, c12, c13);

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

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

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

更具体的：

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

例如：

招聘的帖子，ext为：

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

而二手的帖子，ext为：

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

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

解决了海量异构数据的存储问题，遇到的新问题是：

解决完海量异构数据的存储问题，接下来，要解决的是类目的扩展性问题。

每个业务有多少属性，这些属性是什么含义，值的约束等，耦合到帖子服务里显然是不合理的，那怎么办呢？

抽象出一个统一的类目、属性服务，单独来管理这些信息，而帖子库ext字段里json的key，统一由数字来表示，减少存储空间。

如上图所示，json里的key不再是”salary” ”location” ”money” 这样的长字符串了，取而代之的是数字1,2,3,4，这些数字是什么含义，属于哪个子分类，值的校验约束，统一都存储在类目、属性服务里。

这个表里对帖子中心服务里ext字段里的数字key进行了解释：

这样就对原来帖子表ext扩展属性：

{“1”:”driver”,”2”:8000,”3”:”bj”}

{”4”:”iphone”,”5”:3500}

key和value都做了统一约束。

除此之外，如果ext里某个key的value不是正则校验的值，而是枚举值时，需要有一个对值进行限定的枚举表来进行校验：

这个枚举校验，说明key=4的属性（对应属性表里二手，手机类型字段），其值不只是要进行“short类型”校验，而是value必须是固定的枚举值：

{”4”:”iphone”,”5”:3500}

这个ext就是不合法的，key=4的value=iphone不合法，而应该是枚举属性，合法的应该为：

{”4”:”5”,”5”:3500}

此外，类目属性服务还能记录类目之间的层级关系：

类目服务解释了帖子数据，描述品类层级关系，保证各类目属性扩展性，保证各属性值合理性校验，就是分类信息平台另一个统一的核心服务CMC（Category Management Center）。

通过品类服务，解决了key压缩，key描述，key扩展，value校验，品类层级的问题，还有这样的一个问题没有解决：每个品类下帖子的属性各不相同，查询需求各不相同，如何解决100亿数据量，1万属性的检索与联合检索需求呢？

数据量很大的时候，不同属性上的查询需求，不可能通过组合索引来满足所有查询需求，“外置索引，统一检索服务”是一个很常用的实践：

元数据与索引数据的操作遵循：

对于这个搜索引擎架构，简单说明一下：

为应对100亿级别数据量、几十万级别的吞吐量，业务线各种复杂的复杂检索查询，扩展性是设计重点：

帖子业务，一致性不是主要矛盾，检索服务会定期全量重建索引，以保证即使数据不一致，也不会持续很长的时间。

文章写了很长，最后做一个简单总结，面对100亿数据量，1万列属性，10万吞吐量的业务需求，可以采用了元数据服务、属性服务、搜索服务来解决：

任何复杂问题的解决，都是循序渐进的。思路比结论重要，希望大家有收获。