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

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

解决方案

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

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

引用 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。