Дизайн базы данных Facebook?

Сохранять таблицу друзей, которая содержит 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), потому что они уже представлены в другом направлении. Для примеров, когда дружба или другие отношения невозможны.

Скорее всего, это отношение «многие ко многим»:

FriendList (table)

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

EDIT

В таблице user, вероятно, нет user_email в качестве PK, возможно как уникальный ключ.

users (table)

user_id PK
user_email
password

Помните, что таблицы базы данных предназначены для вертикального роста (больше строк), а не по горизонтали (больше столбцов)

Что касается производительности таблицы «многие ко многим», если у вас есть 2 32-битных целых числа, связывающих идентификаторы пользователей, ваше основное хранилище данных для 200000000 пользователей, в среднем по 200 друзей на каждого, будет чуть меньше 300 ГБ.

Очевидно, вам потребуются некоторые разделы и индексация, и вы не собираетесь хранить это в памяти для всех пользователей.

Взгляните на эти статьи, описывающие, как устроены 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 / theatre / archives / 2008/01 / nextyahoonet_big_data_viewpoints_from_the_fac.html

Также есть эта статья, в которой рассказывается о нереляционных базах данных и о том, как они используются некоторыми компаниями:

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

Вы увидите, что эти компании имеют дело с хранилищами данных, многораздельными базами данных, кэшированием данных и другими концепциями более высокого уровня, с которыми большинство из нас никогда не сталкивается ежедневно. Или по крайней мере, может, мы не знаем, что знаем.

На первые две статьи есть много ссылок, которые должны дать вам больше информации.

ОБНОВЛЕНИЕ 20.10.2014

Мурат Демирбас написал резюме на

• TAO: Facebook распространяется хранилище данных для социального графа (ATC'13)
• F4: система хранения теплых BLOB-объектов Facebook (OSDI'14)

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

HTH

Вы ищете внешние ключи. По сути, у вас не может быть массива в базе данных, если в ней нет собственной таблицы.

Пример схемы:

    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

Лучше всего, чтобы они создали структуру графа . Узлы - это пользователи, а «дружба» - это ребра.

Сохранять одну таблицу пользователей, вести другую таблицу ребер. Затем вы можете хранить данные о ребрах, например «день, когда они стали друзьями», «одобренный статус» и т. Д.

Взгляните на следующую схему базы данных, реконструированную Анатолием Любарским :

Невозможно получить данные из RDBMS для данных о друзьях пользователя для данных, которые пересекают более полумиллиарда в постоянное время поэтому Facebook реализовал это с помощью базы данных хэшей (без SQL), и они открыли базу данных под названием Cassandra.

Таким образом, у каждого пользователя есть свой ключ, а данные о друзьях находятся в очереди; чтобы узнать, как работает cassandra, посмотрите здесь:

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