Структура данных типа "как" Facebook

Ответ 1

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

Используя пример Facebook, у вас может быть что-то вроде этого:

User
------------
UserId (PK)

Item
-------------
ItemId (PK)
ItemType (discriminator column)
OwnerId (FK to User)

Status
------------
ItemId (PK, FK to Item)
StatusText 

RelationshipUpdate
------------------
ItemId (PK, FK to Item)
RelationshipStatus
RelationTo (FK to User)

Like
------------
OwnerId (FK to User)
ItemId (FK to Item)
Compound PK of OwnerId, ItemId

В полной полноте заинтересованности стоит отметить, что Facebook не использует РСУБД для такого рода вещей. Они выбрали решение NoSQL для такого рода хранилищ. Однако это один из способов хранения такой слабосвязанной информации в СУБД.

Ответ 2

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

Однако они используют несколько хранилищ данных типа NoSQL. "Как", скорее всего, приписывается на основе службы, возможно, настраивается в стиле SOA во всей их инфраструктуре. Таким образом, "Like" можно в основном отнести к чему-либо, с чем они хотят, чтобы быть связанным. Все это, с огромной масштабируемостью и не связанными с реляционными проблемами. То, что Facebook не может позволить себе иметь дело с объемом, который они работают.

Они также могут использовать механизм обработки стиля AOP (Aspect Oriented Programming), чтобы "прикрепить" "как" к чему-либо, что может понадобиться на время рендеринга страницы, но я понимаю, что это асинхронная обработка через JavaScript против веб-службу стиля SOA или другой механизм доставки.

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

Ответ 3

У вас может быть таблица с Id, ForeignId и Type. Тип может быть любым, как Фото, Состояние, Событие и т.д. ForeignId будет идентификатором записи в таблице Тип. Это дает возможность как для комментариев, так и для комментариев. Вам нужен только один стол для всех понравившихся, один для всех комментариев и тот, который я описал.

Пример:

Items
Id  | Foreign Id  | Type
----+-------------+--------
  1 |         322 | Photo
  4 |         346 | Status

Likes
Id  | User Id     | Item Id
----+-------------+--------
  1 |         111 | 1

Здесь пользователь с Id 111 любит фотографию с Id 322.

Примечание. Предполагаю, что вы используете РСУБД, но см. ответ Адрона. Facebook делает не использование СУБД для большинства своих данных.

Ответ 4

Я уверен, что Facebook не хранит "как" информацию, как некоторые другие предложили использовать RDBMS. С миллионами пользователей и, возможно, тысячами подобных, мы смотрим на тысячи строк, чтобы присоединиться сюда, что повлияло бы на производительность.

Лучшим подходом здесь является добавление всех "симпатий" в одну строку. Например, таблица с столбцом user_like_id текстового типа данных. Затем добавляется все id, которым понравился пост. В этом случае вы запрашиваете только одну строку, и у вас есть все. Это будет намного быстрее, чем объединение таблиц и подсчет очков.

EDIT: Я не был здесь на этом сайте в последнее время, и я просто обнаружил, что этот ответ был опущен. Ну, здесь пример сообщения с похожим счетом и их аватарами. Это мой проект, где я только что реализовал то, о чем говорю.

Два компонента здесь: 1.) Таблица XREF и 2.) Объект JSON.

Символы все еще хранятся в таблице XREF. Но в то же время данные добавляются к объекту JSON и сохраняются в текстовом столбце в таблице сообщений.

Почему я сохранил такую ​​информацию в текстовом столбце как JSON? Так что нет необходимости делать поиск/объединение db для подобных. Если кто-то не похож на сообщение, объект JSON просто обновляется.

Теперь я не знаю, почему этот ответ ниспровергнут некоторыми пользователями здесь. Этот ответ обеспечивает быстрый поиск данных. Это близко к подходу NoSQL, который представляет собой доступ к данным FB. В этом случае нет необходимости в дополнительном объединении/поиске, чтобы получить информацию о себе.

И вот таблица, в которой есть подобные. Это простое сопоставление XREF между таблицей пользователя и элемента.