Как сайты социальных сетей вычисляют обновления друзей?

Ответ 1

Многие из таких социальных сетей, как Twitter, не используют СУБД вообще, а приложение "Очередь сообщений". Многие из них начинаются с уже существующего приложения, такого как RabbitMQ. Некоторые из них становятся достаточно крупными, им приходится сильно настраивать или строить свои собственные. Twitter во второй раз делает это.

Приложение очереди сообщений работает, сохраняя сообщения из одной службы для одной или нескольких других служб. Например, скажем, служба Frank публикует сообщения в очередь foo. Джо и Джилл подписались на Franks foo queue. приложение будет отслеживать, получили ли Джо или Джилл сообщения и как только каждый абонент в очередь получил сообщение, которое оно отбрасывает. Фрэнк снимает сообщения и забывает об этом. Джо и Джилл спрашивают сообщения от foo и получают сообщения, которые еще не получили. Джо и Джилл делают все, что им нужно, с сообщением. Возможно, это не возможно.

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

РЕДАКТИРОВАТЬ: Я должен также упомянуть, что обычно хранилища для такого рода вещей в больших масштабах сильно денормализуются. Поэтому Джо и Джилл могут хранить копию того же самого сообщения. Это считается одобренным, потому что он помогает шкале приложений миллиардам пользователей.

Другое чтение:

• http://www.rabbitmq.com/
• http://qpid.apache.org/

Ответ 2

Основной структурой данных сайтов социальных сетей является graph. На фейсбуке график неориентирован (Когда вы - друг, они вы друг). В twitter график направлен (вы следуете за кем-то, но они не обязательно следуют за вами).

Двумя популярными способами представления графиков являются списки смежности и матрицы смежности.

Список смежности - это просто список ребер на графике. Рассмотрим пользователя с целым идентификатором пользователя.

User1, User2
  1      2
  1      3
  2      3

Неориентированная интерпретация этих записей заключается в том, что пользователь 1 дружит с пользователями 2 и 3, а пользователь 2 также дружит с пользователем 3.

Представление этого в таблице базы данных тривиально. Это много-много отношений, которые мы знакомы. SQL-запросы для поиска друзей конкретного пользователя довольно просты в написании.

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

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

Ответ 3

Трэвис написал отличный пост,

Журналы активности и файлы друзей в Rails и pfeed

Ответ 4

Для небольшого масштаба, делающего соединение с пользователями. Пользователи и пользователи. События и кеширование запросов, вероятно, прекрасны, но довольно быстро замедляются по мере роста друзей и событий. Вы также можете попробовать модель, основанную на событиях, в которой каждый раз, когда пользователь создает событие, запись создается в таблице соединений (возможно, называется "friends_events" ). Таким образом, всякий раз, когда пользователь хочет увидеть, какие события создали их друзья, они могут просто объединиться между своим собственным идентификатором и таблицей friends_events и узнать. Таким образом, вы избегаете захватывать всех пользователей с друзьями, а затем присоединяетесь к своим друзьям с таблицей событий.