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

Question

[Антон Тихомиров]

Всем привет! Пробую реализовать свою небольшую соц. сеть (для себя, ну и просто тренировка).

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

Что у меня есть из таблиц:

comments - непосредственно все записи друзей и групп.
users - данные всех юзеров и групп (решил юзеров и группы писать в одну таблицу, чтобы джойнить меньше).
friends - данные друзей (кто кого добавил). Соответственно выводим записи только моих друзей.
groups_members - данные групп (кто в какой группе состоит).

В комментах есть колонка user_id - это id юзера, оставившего эту запись, и post_id - это id юзера, для кого была оставлена эта запись, или id группы, если запись была сделана на стене группы.

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

Заранее благодарен.

Answer 1

[Tyranron]

Ну, join'ить это дело можно (подозреваю что там ещё и union'ом прийдётся заливать), но так обычно не делают, потому что это решение потом невозможно будет отмасштабировать. Запрос тяжелый, кеширование поможет плохо, так как активность большая и кеш часто сбрасываться будет и база будет дергаться не многим меньше, ну и если базу надо распилить на 2 и больше серверов, то останемся лапу сосать с join'ами.

Для начала можно сделать так - для конкретного `user_id` (владелец новостной ленты):
1) Первым запросом стягиваем айди всех друзей
2) Вторым запросом стягиваем айди всех групп, в которых состоит
3) Третьим запросом стягиваем из comments все записи WHERE `user_id` IN (группы + друзья) ORDER BY/LIMIT по вкусу.

Преимущества:
Меньшая нагрузка на базу, она будет делать меньше дорогостоящих операций с временными таблицами. По индексам быстрее будет отдавать результат.
Первые 2 запроса можно спокойно закешировать, так как добавляются/удаляются друзья гораздо реже, чем сами посты. Потому по сути сводится всё к одному запросу на сами посты без join'ов.

Минусы:
Больше кода на обработку 3х запросов. Чуть более длительное выполнения скрипта, что, в принципе, не будет ощущаться пользователем, и вообще будет не справедливо, если первые 2 запроса кешировать.

Но если стоит задача масштабироваться, то и такого подхода к делу недостаточно. Там уже надо будет скорее всего жертвовать лишним местом, чтобы сократить расходы на собирание размазанных данных по всем серверам баз, например, вести отдельную таблицу ленты новостей для каждого пользователя, которая будет агрегировать все необходимые айдишники.
UPD: ...как и указал @jarvis

Comments

[Антон Тихомиров]

Вау!) Это... интересно!) По-моему ларчик, хоть фомкой и с размаху, но постепенно откроется :)
Честно сказать, всегда считал, что две и более таблиц можно только джойнить, а о таком решении я даже не подумал!) Юзеров и друзей с комментами я сджойнил успешно, но после того, как весь запрос постепенно стал размером с целую страницу, я понял, что как-то это все нездорОво!)

Тогда возникает еще пара вопросов:
1) У меня кеширование осуществляется просто текстовыми файлами. Будет ли целесообразно иметь для каждого пользователя один файл (вдруг я не сплю ночами, так как мне не дают покоя лавры Паши Дурова, и мне кажется, что в моей сети будут тысячи пользователей))) )? Как-то memcached просто не хочется пока вводить...
2) Если у юзера будет несколько тысяч друзей, например. Не слишком-ли жесткое будет количество id в IN в запросе?
3) Можно ли получить все id и сразу их добавить в запрос мускулом напрямую (что-то типа WHERE `user_id` IN (SELECT `id` FROM...)) или только средствами php?

И большое спасибо за идею, реально, это, пожалуй, то, что нужно!)

[Tyranron]

1) С текстовыми файлами скорее надо отводить один файл под один ключ, а не под юзера. Ведь желательно, чтобы было меньше блокировок, а то пока Вы будете писать значение по одному ключу в файл, кто-то будет пытаться прочесть значение по другому, и ему придется подождать, так как файл заблокирован на запись, а это есть не хорошо. Хорошо будет написать класс-оберточку, и в нем скрыть детали работы с файлами, потому что файлы - это в любом случае на первое время, когда у Вас будет больше одного веб-сервера со скриптами, встанет вопрос сброса кешей, и пробегать все веб-серверы чтобы почистить файлы - явно не вариант, а так - нужно будет всего лишь перепилить класс под мемкеш. Плюс и здесь все неоднозначно...данные, они то разные...есть достаточно иммутабельные, которые не требуют delete, а живут, пока не станут expired, их же можно и в файлах оставить, остальное загнать в memcache/redis.
2) Тысяча ещё норм...но в целом ход мыслей правильный - у этого решения есть свой потолок, как и указывалось раньше. При больших объемах нужно применять другие пути решения.
3) WHERE `user_id` IN (SELECT `id` FROM...) - те же яйца, что и join, только значительно, значительно хуже, потому что мускул будет этот под-запрос выполнять для каждой проверяемой строки, что катастрофически бьет по времени выполнения на больших объемах. Но особенность это конкретно мускула, в оракле/постгресе с этим вроде как лады, не в курсе точно.
Средствами php - что мешает сделать WHERE `id` IN (".implode(',', $ids).")?...или я не понял вопрос.

[Антон Тихомиров]

@Tyranron
1) Хм, почитал про мемкэш на Хабре, пощупал - а что, отличная вещь, как оказалось! Пожалуй, добавлю его в мою обвертку для БД... По сравнению с файлами - просто день и ночь! Век живи - век учись ;)
2) Решил поддать жару и добавил в таблицу 10 000 друзей (к слову, это максимально возможное количество друзей для одного юзера на некоем популярном ресурсе Паши Недурова). Что самое интересное - запрос с таким IN выполнился медленнее не более чем на пару тысячных секунды, разница в скорости почти не заметна что при 1 000, что при 10 000 id в IN, особенно, если специально не обращать на это внимание. Чувствую, что это вин!
Кстати, мне кажется, что запрос на выборку 10 000 строк вида SELECT `id` FROM `friends` WHERE `user_id` = "1" выполняется невероятно быстро! Около 0,06 сек. Или я что-то недопонимаю?) А что будет при высоких нагрузках?
3) Хм, да, и правда, при 10 000 строках уже ощущаются заметные тормоза (на 2 секунды дольше). Это уже очень некультурно!))) Поэтому и правда, сунул в IN массив на php. Кстати, конструкция вида

$ids .= $row['id'].',';
$ids = trim ($ids, ',');

при 10 000 значений тратит на целых 2 Мб ОЗУ меньше, чем

$ids[] = $row['id'];
$ids = implode (',', $ids);

Считаю, что это полезная информация...
Еще раз покорнейше благодарю! ;)

[Tyranron]

2) 0,06 сек. это на самом деле медленно =(
Быстро выполняется, потому что по индексу напрямую данные тянутся. Это мускулу никогда не сложно. Медленно, потому что результат выборки достаточно нехилый и всё это нужно передать по сети.

Answer 2

[jarvis]

Я делал через очередь сообщений, то есть сообщение человека или группы добавляется в ленты каждого его подписчика(многократно)

Все пока одна таблица(пока одна, потом придется увеличить в процессе масштабирования) и такой запрос на получение ленты пользователя с user_id: select * from 'feeds_table' where user_id=id пользователя...., а сама таблица feeds содержит такие поля как user_id( пользователь, которому принадлежит лента, author_id - id автора(кто оставил запись, без разницы группа или пользователь), post (сама запись и вложения). Таким образом запись многократно дублируется, но зато позволяет быстро и в один простой запрос получать ленту.

Comments

[Антон Тихомиров]

@jarvis Ого!) Пользуешься принципом "Главное - что работает!" :)
В принципе да, решение достаточно простое в реализации и в работе, но боюсь представить, что будет на нагруженной системе через год. Потребуется судорожное партицирование или даже шардинг, что экономически будет совершенно не выгодно (доход от этой соц. сети не покроет стоимость оборудования, которая будет уверенно расти).

[Tyranron]

Не согласен. Горизонтальное масштабирование бывает дешевле вертикального....ведь 4 слабеньких сервера (с 4-8 Гб оперативки) обойдутся дешевле чем один мощный-мощный с 128 Гб оперативки и прочими плюшками, а держать смогут больше и будут более отказоустойчивыми.

[Антон Тихомиров]

@Tyranron возможно, но вроде бы на одном сервере распределить все намного легче, чем на нескольких. То есть типа запрос будет иметь вид типа
SELECT `table1`.`id.`, `table2`.name`... (если я правильно понял суть). Реализовывал такое в проекте на будущее. Намучился вообще... Пол движка переписал, а все-равно все как-то все это гротескно и брутально. Да и постоянно что-то шло как-то не так... Заморозил эту идею пока, время покажет....

[Антон Тихомиров]

@Tyranron Не, ну это ж надо же так опечататься!) Имел ввиду запрос вида SELECT `server1`.`table1`.`id.`, server2`.`table2`.name`...

[Tyranron]

@Acuna нет...это ж как Вы собрались с нескольких серверов одновременно одним запросом тянуть данные? Мускул так не умеет...тут надо писать нехилую обвязку для работы со всем этим делом. И никогда нет единого бест-подхода/фреймворка для разработки масштабируемой системы, тут надо под каждую задачу своё и умело это комбинировать вместе.
В общем это не сильно сложнее, если в Вы в теме. Просто для масштабирования нужно мыслить немного иначе, чем принято. Когда привычка так мыслить появляется, то становится не сложно закладывать архитектуру проекта так, чтобы в будущем его можно было отмасштабировать без переписывания с нуля.