56,942
社区成员
发帖
与我相关
我的任务
分享【版主大人】 我现在要做一个社交系统，设计到用户和好友管理，数据模型怎么设计合适？
RT~
我现在的初步思路是用户表打算建一百张表来分表存储，这个倒不是很难，我用用户账号（手机号码）去取余存储即可。
但是好友关系没想到好的方案，刚开始想到的最笨的办法就是用一个表来存储用户和好友的关系，但是这样一来的话如果
一个用户有500个好友，那么就有500条记录，这还只是一个用户的，用户多了的话我都不敢想了，还有一种方案是我用
一条记录来存储该用户的所有好友账号，这个字段的值我设置大一点用个verchar来存储，但是好友多了算下来有几十万个字节，
这样好像也不行，求各位大神给点意见，谢谢~
我现在的初步思路是用户表打算建一百张表来分表存储，这个倒不是很难，我用用户账号（手机号码）去取余存储即可。
但是好友关系没想到好的方案，刚开始想到的最笨的办法就是用一个表来存储用户和好友的关系，但是这样一来的话如果
一个用户有500个好友，那么就有500条记录，这还只是一个用户的，用户多了的话我都不敢想了，还有一种方案是我用
一条记录来存储该用户的所有好友账号，这个字段的值我设置大一点用个verchar来存储，但是好友多了算下来有几十万个字节，
这样好像也不行，求各位大神给点意见，谢谢~
...全文
请发表友善的回复…
发表回复
七夜未央 2016-04-29
- 打赏
- 举报
上面说的是基础信息存储的问题，接下来说说交互通信的问题。
想必社交平台不是只做静态展示的，那么会有IM聊天、Twitter微博的消息和推送、博客朋友圈的文章、互相点赞、评论这些交互。
这些如果上规模，只用mysql肯定是不合适的。
对于负载，还可以考虑的是redis和memcached做缓存，可是对于通信就必须考虑通信中间件。
对于im，可以考虑rabbitmq。
对于微博、博客通知、点赞通知、评论，可以考虑kafka。
[/quote]
多谢指点
gikod 2016-04-28
- 打赏
- 举报
上面说的是基础信息存储的问题，接下来说说交互通信的问题。
想必社交平台不是只做静态展示的，那么会有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
- 打赏
- 举报
可以考虑表分区。另外如果数据超大，考虑分布式数据库。
