对于 Facebook 等大型社交网站来说，最佳的 RDBMS 解决方案是什么？
我找到了两种可能的解决方案来实现 Facebook 等社交网站的数据库结构。
1.：创建一个“关系”表并将每条友谊插入其中。例如：用户 A 添加 B 作为朋友（AB），然后逻辑将（AB）和（BA）放入“关系”表中。然后它索引第一个属性。
2.：为所有包含好友的用户创建一个唯一的表。大多数数据库都使用近 20 亿个唯一表，因此这不会成为问题；然而，数据库大小将增加近 300 倍（预计每个用户平均有 300 个朋友）。在这种情况下，查询朋友不会有问题（就像 SELECT * FROM 一样简单）
有什么想法吗？我有什么地方说错了吗？ 谢谢大家。
I found out two possible solutions for implementing the database structure for social networking sites like Facebook.
1.: Creating a 'Relationships' table and inserting every friendship into it. For example: user A adds B as friend (A-B), then the logic puts (A-B) and (B-A) into the 'Relationships' table. Then it indexes the first attribute.
2.: Creating a unique table for all the users containing friends. Most databases work with nearly 2 billion unique tables, so it won't be a problem; however, the database size will be nearly 300 times bigger (expecting 300 friends average per user). In this scenario, querying friends would not be a problem (as simple as SELECT * FROM)
Any ideas? Am I wrong somewhere?
Thanks all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您所描述的每用户表解决方案听起来基本上类似于 Oracle 的分区功能。
不完全相关，但我推荐这篇很棒的文章：演示摘要“大规模的高性能：Facebook 的经验教训”
我认为友谊表是他们最不关心的:)
The table-per-user solution that you are describing sounds basically like Oracle's partitions feature.
Not exactly related, but I recommend this awesome post: Presentation Summary “High Performance at Massive Scale: Lessons Learned at Facebook”
I think that the friendships table is the least of their concerns :)
您不必担心最大桌子大小之类的问题。为了创建像 Facebook 这样的网站，您必须将所有表分片/分区到多台机器上。
You don't have to worry about maximum table size and stuff like that. In order to create a site like Facebook you have to shard/partition all your tables to multiple machines anyway.