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

七夜未央 2016-04-26 10:14:09
RT~

我现在的初步思路是用户表打算建一百张表来分表存储,这个倒不是很难,我用用户账号(手机号码)去取余存储即可。

但是好友关系没想到好的方案,刚开始想到的最笨的办法就是用一个表来存储用户和好友的关系,但是这样一来的话如果

一个用户有500个好友,那么就有500条记录,这还只是一个用户的,用户多了的话我都不敢想了,还有一种方案是我用

一条记录来存储该用户的所有好友账号,这个字段的值我设置大一点用个verchar来存储,但是好友多了算下来有几十万个字节,

这样好像也不行,求各位大神给点意见,谢谢~
...全文
182 4 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
七夜未央 2016-04-29
  • 打赏
  • 举报
回复
引用 3 楼 gikod 的回复:
[quote=引用 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。 [/quote] 多谢指点
gikod 2016-04-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。
gikod 2016-04-28
  • 打赏
  • 举报
回复
可以看看微博的处理,tim yang的博客上有很多。 分布式数据库比如dynamo如果不做应用级别对应业务逻辑的优化,也不一定能很好地处理这些问题。 我觉得还是要解决分库sharding和共享的问题。 1 你需要多少的一致性? 一般来说,社交只需要办到最终一致性,不太需要太多的强一致性。 或者说,只要办到用户级或者会话级一致性就好。 2 你的规模要多大? 百万、千万、亿、十亿,考虑的问题是不完全一样的 先回答了上面两个问题,之后的问题就可以有答案了。 用户级一致性用用户级sharding就可以办到。 即自小粒度是用户,以用户id为key做hash(你说的除余就可以认为是hash的一种) 回话级一致性,一般是针对单个session,如果用户间有对话,不妨用chat_session_id来做hash,把chat相关的表再做以遍hash,单独分库sharding存储,这个的sharding规则可以分得更多,比如50000张表。 这样至少解决了第一步的负载问题。 另外,如果你考虑系统的维护性和扩展性,那么需要更多的设计,比如更多的初期sharding预留,或者consist hash。 这些推荐你多读更多的资料以后再做设计。
示申○言舌 2016-04-26
  • 打赏
  • 举报
回复
可以考虑表分区。另外如果数据超大,考虑分布式数据库。

56,940

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧