Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.2k views
in Technique[技术] by (71.8m points)

社交应用中的双双匹配数据设计

背景
社交用户的双双匹配
男方A,女方B,通过基本信息和异性要求,如年龄,收入等,可以得出一个双方的匹配分值。匹配表结构如下

男方女方男方匹配女方分数女方匹配男方分数
AB9989

已知问题

  1. 现在用户量10W,匹配表数据接近1个亿。如果以后发展到100W,数据量无法想象
  2. 如果用户改变基本信息,那么需要对这个匹配表进行硬删除和新增数据,导致高频的新增和删除,非常耗时和耗性能,影响业务
  3. 考虑过内存数据库,但是发现无法和MYSQL结合,原因是匹配表做为基表,在很多地方和业务表做联合查询
  4. 这个匹配表实际应用中,做了分区,做了索引,但是仅仅为了提高查询速度而已

希望解决

1.不知道有没有架构或者体系,能够解决以上问题
2.考虑过MYSQL的空间索引,但是不知道如何结合


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

我提个不成熟的想法,可能需要去仔细考察具体的可行性

首先,我大胆的猜想一下这个匹配分数在业务中的场景,大致可能有以下几种
(1) C端用户实时查看当前的一个匹配值 —— 场景1
(2) 供给内部其他系统,做为推荐的依据 —— 场景2

其次,按你说的 用户更改信息,就要批量去更改对应的匹配值
那么,实际上这个数据并不是一个需要事先进行处理的一个值,应该是在需要的时候实时去进行计算的

但是由于这个场景的实时性,我们可以考虑用其他的数据库进行处理。
从我浅薄的知识储备中,这种场景可以考虑使用ElasticSearch
对于场景1,则可以根据两个人的数据实时计算一个匹配值,可以考虑复用ES中的权重
对于场景2,则匹配值变为了 匹配文档的某些特征,即通过当前文档的特征,寻求对应的某些特征的文档的操作,再按照自己的规则进行排序打分,同样的,如果可以和查询出的权重进行挂钩,那么这个分数的计算会很方便

如果真的是场景2是主要的业务场景的话,建议去网上搜一下推荐系统的处理


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...