Facebook 数据库设计？

这很可能是一种多对多的关系:

FriendList (表)

user_id -> users.user_id
friend_id -> users.user_id
friendVisibilityLevel

剪辑

User 表可能没有 user _ email 作为 PK，而 有可能作为唯一键。

用户(表)

user_id PK
user_email
password

保留一个朋友表，其中包含朋友的 UserID 和 UserID (我们称之为 FriendID)。这两列都是回到 Users 表的外键。

一个有用的例子:

Table Name: User
Columns:
UserID PK
EmailAddress
Password
Gender
DOB
Location


TableName: Friends
Columns:
UserID PK FK
FriendID PK FK
(This table features a composite primary key made up of the two foreign
keys, both pointing back to the user table. One ID will point to the
logged in user, the other ID will point to the individual friend
of that user)

示例用法:

Table User
--------------
UserID EmailAddress Password Gender DOB      Location
------------------------------------------------------
1      bob@bob.com  bobbie   M      1/1/2009 New York City
2      jon@jon.com  jonathan M      2/2/2008 Los Angeles
3      joe@joe.com  joseph   M      1/2/2007 Pittsburgh


Table Friends
---------------
UserID FriendID
----------------
1      2
1      3
2      3

这将表明鲍勃与乔和乔都是朋友，乔也是乔的朋友。在这个例子中，我们假设友谊总是两种方式，所以您不需要表中的一行，比如(2,1)或(3,2) ，因为它们已经在另一个方向上表示了。对于友谊或其他关系不是明确的双向关系的示例，您还需要使用这些行来指示双向关系。

我最好的猜测是他们创建了一个 图形结构图形结构。节点是用户，“友谊”是边缘。

保持一个用户表，保持另一个表的边缘。然后你可以保留关于边缘的数据，比如“他们成为朋友的那天”和“认可状态”等等。

您正在寻找外键。基本上，数据库中不能有数组，除非它有自己的表。

示例模式:

Users Table
userID PK
other data
Friends Table
userID   -- FK to users's table representing the user that has a friend.
friendID -- FK to Users' table representing the user id of the friend

看看这些描述如何构建 LinkedIn 和 Digg 的文章:

• Http://hurvitz.org/blog/2008/06/linkedin-architecture
• Http://highscalability.com/scaling-digg-and-other-web-applications

还有“大数据: 来自 Facebook 数据团队的观点”可能会有所帮助:

Http://developer.yahoo.net/blogs/theater/archives/2008/01/nextyahoonet_big_data_viewpoints_from_the_fac.html

此外，还有一篇文章讨论了非关系数据库以及一些公司如何使用它们:

Http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php

您将看到，这些公司正在处理数据仓库、分区数据库、数据缓存和其他更高层次的概念，这些概念是我们大多数人在日常生活中从未涉及过的。或者至少，我们不知道我们知道。

在前两篇文章中有很多链接，它们应该会给你更多的见解。

更新日期: 2014年10月20日

Murat Demirbas 写了一篇关于

Http://muratbuffalo.blogspot.com/2014/10/facebooks-software-architecture.html

高温

关于多对多表的性能，如果有2个32位 int 链接用户 ID，那么对于平均每个200个好友的200,000个用户，基本数据存储量将低于300GB。

显然，您需要一些分区和索引，并且您不会为所有用户将其保留在内存中。

看一下下面的数据库模式 由 Anatoly Lubarsky 逆向工程:

从 RDBMS 中检索用户好友数据的数据是不可能的，因为这些数据在一个固定的时间跨越了5亿 所以 Facebook 使用了一个散列数据库(没有 SQL)来实现这一点，他们开放了一个名为 Cassandra 的数据库。

因此，每个用户都有自己的密钥，好友的详细信息在一个队列中; 要知道 Cassandra 是如何工作的，看看这个:

Http://prasath.posterous.com/cassandra-55

它是一种图形数据库: Http://components.neo4j.org/neo4j-examples/1.2-snapshot/social-network.html

它与关系数据库无关。

谷歌图形数据库。

可能存在一个表，它存储好友 <-> 用户关系，比如“ frnd _ list”，其中有字段‘ user _ id’、‘ frnd _ id’。

每当一个用户将另一个用户添加为好友时，就会创建两个新行。

例如，假设我的 id 是“ deep 9c”，并且我添加了一个 id 为“ akash3b”的用户作为我的朋友，然后在表“ frnd _ list”中创建两个新行，它们的值分别是(‘ deep 9c’，‘ akash3b’)和(‘ akash3b’，‘ deep 9c’)。

现在，当向特定用户显示好友列表时，一个简单的 sql 将执行以下操作: “ select frnd _ id from frnd _ list where user _ id =” 其中是登录用户的 id (存储为会话属性)。

译者:

他们使用一个包含缓存图的堆栈架构来处理堆栈底部 MySQL 以上的所有内容。

答案很长:

我自己对此做了一些研究，因为我很好奇他们是如何处理海量数据并快速搜索的。我见过人们抱怨自定义的社交网络脚本在用户基数增长时变慢。在我对自己与 只要一万用户和 250万的朋友连接进行了一些基准测试之后——甚至没有试图关心组权限、喜欢和墙上的帖子——很快就发现这种方法是有缺陷的。因此，我花了一些时间在网上搜索如何做得更好，并偶然发现了这篇 Facebook 官方文章:

• TAO: Facebook 是社交图表的分散式档案系统
• TAO: 图表的力量。

CREATE TABLE IF NOT EXISTS `friends` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`friend_id` int(11) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

(
select friend_id
from friends
where user_id = 1
) union (
select distinct ff.friend_id
from
friends f
join friends ff on ff.user_id = f.friend_id
where f.user_id = 1
)