Реализация ленты новостей?

Question

[Евгений Селезнев]

Господа, может быть кто-нибудь сталкивался с задачей реализации ленты новостей? Интересуют ваши мысли/решения.


Должно выглядеть примерно так:


У себя в ленте видим свои события + события тех, на кого подписаны

У подписчиков видим только их события.


Мне видится два варианта:

1). Отдельный поток для каждого пользователя (некая структура в БД/канал в комете/etc.)

В данном случае неудобно показывать свой фид — придется тащить фиды всех, на кого подписаны, и их сортировать.


2). При добавлении события пихать его в свой фид + в фиды тех, кто на нас подписан.

Минус — получается довольно большой оверхед (копии одного и того же события хранятся в разных фидах)


Посоветуйте что-нибудь, заранее спасибо.

Answer 1

[Insbrook]

Если у вас не очень много пользователей и настроек ленты почти нет, можно хранить все новости без дублирования и делать выборку, как советовали выше.
Однако, что получится, если есть не только таблица подписчиков, но и таблица с информацией о приватности новостей (кому из подписчиков что показывать), есть таблица с информацией о людях, чьи новости ты не хочешь видеть в своей ленте (однако не удаляешь из друзей, например). Получается, что с каждой такой фичей запрос на вывод новостной ленты будет обрастать JOINами и вложенными запросами, что весьма негативно скажется на производительности работы. В таком случае, лучше пожертвовать памятью сервера и хранить ленту новостей для каждого пользователя отдельно. Тогда вывод ленты может быть простым SELECTом по индексу.

Могу посоветовать статью про ленту обновлений. Возможно, вы будете использовать другую СУБД, однако идеи и мысли могут оказаться полезными.

Comments

[Евгений Селезнев]

Пока использую редис, от идеи РСУБД сразу отказался, за статью спасибо.

Answer 2

[Влад Фролов]

Я вижу это так:
1 таблица со всеми новостями (без дублирования), 1 таблица м2м связь пользователей и новости.
Чтобы отобразить свои новости — делаем выборку по второй таблице, чтобы отобразить события какого-то отдельного человека — выборка по владельцу новости.

Answer 3

[Александр]

все ленты новостей реализуются через сервера очередей
советую rabbitMQ протокол AMQP
на Хабре найдешь кучу статей.

Comments

[korotovsky]

Автор просто видимо не осознает насколько нужным может быть RabbitMQ при _очень_ высокой посещаемости.

[Евгений Селезнев]

осознаю, но помню про преждевременное семяизвержение преждевременную оптимизацию.

Answer 4

[ertaquo]

Имхо, проще всего сделать по первому варианту. Выборкой и сортировкой пусть занимается SQL-сервер, он для этого в частности и предназначен. Реализуется примерно таким простеньким запросом:
SELECT * FROM news WHERE user_id = :current_user_id OR user_id IN (SELECT user_id FROM subscribes WHERE subscriber_id = :current_user_id) ORDER BY `date`

Comments

[ramilexe]

подзапросы не гуд!

[ertaquo]

Почему? Если проиндексировать поля user_id и subscriber_id, выборка будет идти довольно шустро.

[Николай Васильчук]

Ну сделайте 2 запроса, если «подзапросы не гуд»

Answer 5

[korotovsky]

Думаю надо взглянуть сюда: ru.wikipedia.org/wiki/RabbitMQ

Comments

[Евгений Селезнев]

Хранилище, в принципе не важно, меня скорее общий принцип интересует