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

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

RT~

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

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

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

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

这样好像也不行，求各位大神给点意见，谢谢~

...全文

176 4 打赏收藏转发到动态举报

写回复

用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。这些推荐你多读更多的资料以后再做设计。

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。这些推荐你多读更多的资料以后再做设计。