版主大人 本人现在要做一个社交系统,设计到用户和好友管理,数据模型怎么设计合适?

MySql 码拜 6年前 (2016-02-07) 516次浏览
RT~
本人现在的初步思路是用户表计划建一百张表来分表存储,这个倒不是很难,本人用用户账号(手机号码)去取余存储即可。
但是好友关系没想到好的方案,刚开始想到的最笨的办法就是用一个表来存储用户和好友的关系,但是这样一来的话假如
一个用户有500个好友,那么就有500条记录,这还只是一个用户的,用户多了的话本人都不敢想了,还有一种方案是本人用
一条记录来存储该用户的全部好友账号,这个字段的值本人设置大一点用个verchar来存储,但是好友多了算下来有几十万个字节,
这样好像也不行,求各位高手给点意见,谢谢~
解决方案

2

可以考虑表分区。另外假如数据超大,考虑分布式数据库。

10

可以看看微博的处理,tim yang的博客上有很多。
分布式数据库例如dynamo假如不做应用级别对应业务逻辑的优化,也不一定能很好地处理这些问题。
本人觉得还是要解决分库sharding和共享的问题。
1 你需要多少的一致性?
一般来说,社交只需要办到最终一致性,不太需要太多的强一致性。
或说,只要办到用户级或会话级一致性就好。
2 你的规模要多大?
百万、千万、亿、十亿,考虑的问题是不完全一样的
先回答了上面两个问题,之后的问题就可以有答案了。
用户级一致性用用户级sharding就可以办到。
即自小粒度是用户,以用户id为key做hash(你说的除余就可以认为是hash的一种)
回话级一致性,一般是针对单个session,假如用户间有对话,不妨用chat_session_id来做hash,把chat相关的表再做以遍hash,单独分库sharding存储,这个的sharding规则可以分得更多,例如50000张表。
这样至少解决了第一步的负载问题。
另外,假如你考虑系统的维护性和扩展性,那么需要更多的设计,例如更多的初期sharding预留,或consist hash。
这些推荐你多读更多的资料以后再做设计。

28

引用 2 楼 gikod 的回复:

可以看看微博的处理,tim yang的博客上有很多。
分布式数据库例如dynamo假如不做应用级别对应业务逻辑的优化,也不一定能很好地处理这些问题。
本人觉得还是要解决分库sharding和共享的问题。
1 你需要多少的一致性?
一般来说,社交只需要办到最终一致性,不太需要太多的强一致性。
或说,只要办到用户级或会话级一致性就好。
2 你的规模要多大?
百万、千万、亿、十亿,考虑的问题是不完全一样的
先回答了上面两个问题,之后的问题就可以有答案了。
用户级一致性用用户级sharding就可以办到。
即自小粒度是用户,以用户id为key做hash(你说的除余就可以认为是hash的一种)
回话级一致性,一般是针对单个session,假如用户间有对话,不妨用chat_session_id来做hash,把chat相关的表再做以遍hash,单独分库sharding存储,这个的sharding规则可以分得更多,例如50000张表。
这样至少解决了第一步的负载问题。
另外,假如你考虑系统的维护性和扩展性,那么需要更多的设计,例如更多的初期sharding预留,或consist hash。
这些推荐你多读更多的资料以后再做设计。

上面说的是基础信息存储的问题,接下来说说交互通信的问题。
想必社交平台不是只做静态展示的,那么会有IM聊天、Twitter微博的消息和推送、博客朋友圈的文章、互相点赞、评论这些交互。
这些假如上规模,只用mysql肯定是不合适的。
对于负载,还可以考虑的是redis和memcached做缓存,可是对于通信就必须考虑通信中间件。
对于im,可以考虑rabbitmq。
对于微博、博客通知、点赞通知、评论,可以考虑kafka。


CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明版主大人 本人现在要做一个社交系统,设计到用户和好友管理,数据模型怎么设计合适?
喜欢 (0)
[1034331897@qq.com]
分享 (0)