Каков наилучший (масштабируемый, быстрый, надежный) подход для реализации Activity Feed, Message Queue или RDBMS или NoSQL DB?

Question

Мне нужно создать фид активности (поток «Жизненный поток», чтобы быть более точным.) Для системы, аналогичной (той же), что и многие популярные социальные сетевые платформы. Моя первоначальная попытка состояла в том, чтобы использовать РСУБД, но быстро отказалась от идеи из-за огромного количества СОБЫТИЙ, необходимых. Продувка для других возможно (и лучше подходит) подходы, я наткнулся на следующее сообщение:

How do social networking websites compute friend updates?

Принимая посоветуете сделать использование очереди сообщений, я потратил некоторое время на изучение RabbitMQ и его протокол PubSubHubbub , И я постулировал следующий подход:

1) Каждый пользователь имеет «тему» ​​
2) Другие пользователи подписаться на тему
3) Когда пользователь выполняет какое-либо действие, сообщение опубликовано, который затем связаны между собой (Референции разрешены), отформатированный (дружественный для человека язык, ссылки и т. Д.) И агрегированные (X, Y и Z комментируют пост P) с помощью PHP-скрипта.

Однако мне все равно придется проходить каждое сообщение и обрабатывать его (если только мой подход не является полностью неправильным). Итак, какая разница между сохранением всего в СУБД и использованием очереди сообщений (кроме реализации протокола PubSubHubbub)?

Есть ли более эффективные способы построения такой системы? (Если да, просьба указать)

Комментарии/Предложения/Критика приветствуется. :)

Заранее спасибо!

P.S .: Есть интересная статья о том, как это реализует FriendFeed (http://bret.appspot.com/entry/how-friendfeed-uses-mysql). Тем не менее, я чувствую, что «хакерство» выталкивает MySQL из его удобного домена (который является просто реляционными данными и какой смысл использовать RDBMS без реляционных данных?)

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

Answer 1

Некоторые советы я хотел бы дать вам:

• Не использовать СУБД, но в оперативной памяти (FAST) базы данных, как, например redis. Как надеюсь, вы согласны со мной в redis benchmarks, redis довольно быстро. В качестве другого побочного элемента я хотел бы указать, что установка redis - это детская игра :).

  сделать

Существует redis-client для PHP, который использует C так, что также будет очень быстро. - Если я вас правильно понимаю, что вы думаете PubSubHubbub таким же, как очереди сообщений, но они не являются:

Стороны (сервера), говорящая протокол PubSubHubbub может получить почти мгновенные уведомления (через webhook обратные вызовы), когда обновляется тема (фид URL), который их интересует.

Versus очереди сообщений:

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

Возможно, вы думаете, что они одинаковы (они имеют некоторые сходства), но они не совпадают. Для моей очереди сообщений я бы сделал redis (redis очень мощный, потому что он также имеет базовую очередь сообщений :)). Вы можете отправить сообщение (единицу работы) в очередь с помощью rpush.

rpush <name of queue> <message> 

Тогда из вашего рабочих процессов можно получать сообщения из очереди с помощью brpop (блокирование всплывающих :))

brpop <name of queue> 0 

нерестится рабочих процессов собираются запустить из cli, чтобы остаться в памяти так что не будет иметь накладных нагрузки PHP в памяти снова и снова.

php worker.php 

Я надеюсь, что это, надеюсь, для вас, и если вы можете иметь любой вопрос, я очень хочу, чтобы ответить на них;)