有一类业务场景，没有固定的schema存储，却有着海量的数据行数，架构上如何来实现这类业务的存储与检索呢？58最核心的数据“帖子”的架构实现技术细节，今天和大家聊一聊。
一、背景描述及业务介绍
什么是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);
其中：
通过扩展属性，可以解决存储的问题。
查询需求，又该如何满足呢？
首先，跨业务属性一般没有组合查询需求。只能建立了若干组合索引，满足房产类别的查询需求。
画外音：不敢想有多少个索引能覆盖所有两属性查询