大数据多属性的数据架构设计
每个公司都是从大到小的发展
（1）如何实现属性扩展性需求
（2）多属性组合查询需求
如何设计？
1.原始的，只有一个分类A
tiezi(tid,uid, c1, c2, c3)
c1,c2,c3是A属性
如何满足各属性之间的组合查询需求，通过组合索引：
index_1(c1,c2) index_2(c2, c3) index_3(c1, c3)
如果增加一个新的类别B
tiezi(tid,uid, c1, c2, c3, c10, c11, c12, c13)
其中c1,c2,c3是A，c10,c11,c12,c13是B
如何满足各属性之间的组合查询需求，再通过所以就不行了
所以这种结构不可取
2.按照业务进行垂直拆分
tiezi_A(tid,uid, c1, c2, c3)
tiezi_B(tid,uid, c10, c11, c12, c13)
这可以通过索引查询
但是也会有新的问题
（1）tid如何规范
（2）属性如何规范
（3）按照uid来查询怎么办
（4）按照时间来查询怎么办
（5）跨品类查询怎么办（例如首页搜索）
……
3.存储异构数据
- 基础数据基础服务的统一
tiezi(tid,uid, time, title, cate, subcate, xxid, ext)
（1）一些通用的字段抽取出来单独存储
（2）通过cate, subcate, xxid等来定义ext是何种含义
（3）通过ext来存储不同业务线的个性化需求
这种异构数据的存储后遇到的新问题是：
（1）每条记录ext内key都需要重复存储，占据了大量的空间，能否压缩存储
（2）cateid已经不足以描述ext内的内容，品类有层级，深度不确定，ext能否具备自描述性
（3）随时可以增加属性，保证扩展性
- 统一类目属性服务
抽象出一个统一的类目、属性服务，单独来管理这些信息，而ext字段里json的key，统一由数字来表示，减少存储空间。
协助解释最核心的数据，描述品类层级关系，保证各类目属性扩展性，保证各属性值合理性校验
基础数据
属性
中心服务里ext字段里的数字key进行了解释：
1代表job，属于招聘品类下100子品类，其value必须是一个小于32的字符
3代表type，属于二手品类下200子品类，其value必须是一个short
如果ext里某个key的value不是正则校验的值，而是枚举值时，需要有一个对值进行限定的枚举表来进行校验
例如type
key=4的属性（对应属性表里二手，手机类型字段），其值不只是要进行“short类型”校验，而是value必须是固定的枚举值
合法的ext : {”4”:”5”,”5”:3500}
如果是电商系统里的SKU扩展
（1）类别
（2）类别商品SKU的属性
（3）枚举值校验，对应属性的枚举值，例如颜色：红，黄，蓝
- 统一检索服务
数据量很大的时候，不同属性上的查询需求，不可能通过组合索引来满足所有查询需求
外置索引，统一检索服务
（1）数据库提供tid的正排查询需求
（2）所有非tid的个性化检索需求，统一走外置索引
元数据与索引数据的操作遵循：
（1）进行tid正排查询，直接访问服务
（2）进行修改，帖子服务通知检索服务，同时对索引进行修改
（3）进行复杂查询，通过检索服务满足需求
大吞吐量，业务复杂的检索查询，扩展性是设计重点：
（1）统一的Java代理层集群，其无状态性能够保证增加机器就能扩充系统性能
（2）统一的合并层C服务集群，其无状态性也能够保证增加机器就能扩充系统性能
（3）搜索内核检索层C服务集群，服务和索引数据部署在同一台机器上，服务启动时可以加载索引数据到内存，请求访问时从内存中load数据，访问速度很快
为了满足数据容量的扩展性，索引数据进行了水平切分，增加切分份数，就能够无限扩展性能
为了满足一份数据的性能扩展性，同一份数据进行了冗余，理论上做到增加机器就无限扩展性能
E-search会定期全量重建索引，以保证即使数据不一致，也不会持续很长的时间
