Мне нужно создать ленту активности (поток? Точнее, «жизненный поток») для системы, похожей (такой же) по сходству со многими популярными платформами социальных сетей. Моей первой попыткой было использовать СУБД, но я быстро отказался от этой идеи из-за огромного количества необходимых СОЕДИНЕНИЙ. В поисках других возможных (и более подходящих) подходов я наткнулся на следующий пост:
Как веб-сайты социальных сетей вычисляют обновления друзей?
Приняв совет использовать очередь сообщений, я потратил некоторое время на изучение RabbitMQ и его протокола PubSubHubbub. И я постулировал следующий подход:
1) У каждого пользователя есть «тема»
2) Другие пользователи подписываются на эту тему
3) Когда пользователь выполняет какое-либо действие, публикуется сообщение, которое затем связывается (ссылки разрешены), форматируется (удобен для человека язык, ссылки и т. д.) и агрегированные (X, Y и Z прокомментировали пост P) с помощью PHP-скрипта.
Однако мне все равно придется просматривать каждое сообщение и обрабатывать его (если только мой подход не является полностью неправильным). Итак, в чем разница между хранением всего в РСУБД и использованием очереди сообщений (кроме реализации протокола PubSubHubbub)?
Есть ли более эффективные способы построения такой системы? (Если да, укажите, пожалуйста)
Комментарии / предложения / критика приветствуются. :)
Заранее спасибо!
PS: есть интересная статья о том, как это реализует FriendFeed (http://bret.appspot.com/entry/how-friendfeed-uses-mysql). Однако я чувствую, что «хакерство» выталкивает MySQL из удобного домена (который представляет собой просто реляционные данные, и какой смысл использовать РСУБД без реляционных данных?)
PPS: Другая проблема с использованием очереди сообщений, которую я вижу (возможно, из-за того, что я новичок в этой технологии), заключается в том, что после того, как сообщение получено «Потребителем», оно удаляется из очереди, однако я хочу, чтобы оно сохранялось. на произвольное время.