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

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

• 每条记录ext内key都需要重复存储，占据了大量的空间，能否压缩存储;
• cateid已经不足以描述ext内的内容，品类有层级，深度不确定，ext能否具备自描述性;
• 随时可以增加属性，保证扩展性;

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

第二：统一类目属性服务

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

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

画外音：帖子表只存元信息，不管业务含义。

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

画外音：类目表存业务信息，以及约束信息，与帖子表解耦。

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

• 1代表job，属于招聘品类下100子品类，其value必须是一个小于32的[a-z]字符;
• 4代表type，属于二手品类下200子品类，其value必须是一个short;

这样就对原来帖子表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} 

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

• 一级类目是招聘、房产、二手…
• 二手下有二级类目二手家具、二手手机…
• 二手手机下有三级类目二手iphone，二手小米，二手三星…
• …

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

画外音：类目、属性服务像不像电商系统里的SKU扩展服务?

• 品类层级关系，对应电商里的类别层级体系;
• 属性扩展，对应电商里各类别商品SKU的属性;
• 枚举值校验，对应属性的枚举值，例如颜色：红，黄，蓝;

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

第三：统一检索服务

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

• 数据库提供“帖子id”的正排查询需求;
• 所有非“帖子id”的个性化检索需求，统一走外置索引;

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!