Каков наилучший (масштабируемый, быстрый, надежный) подход к реализации ленты активности, очереди сообщений, СУБД или баз данных NoSQL?

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

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

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

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

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

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

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

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

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

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


person shachibista    schedule 19.01.2011    source источник


Ответы (1)


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

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

    сделать

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

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

По сравнению с очередью сообщений:

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

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

rpush <name of queue> <message>

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

brpop <name of queue> 0

Создание рабочих процессов будет запущено с cli, чтобы оставаться в память, поэтому не придется загружать PHP в память снова и снова.

php worker.php

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

person Alfred    schedule 19.01.2011
comment
Альфред, во-первых, спасибо за ответ и предложения! Очень признателен. ›Если я вас правильно понял, вы думаете, что pubsubhubbub - это› то же самое, что и очередь сообщений, но это не так: Да, я понимаю разницу (если вы читаете мой пост, вы можете видеть, что я использую RabbitMQ в качестве очереди сообщений для протокола PubSubHubbub). Как вы сказали, я читал о Redis (и это отличный учебник: redis.io/topics/twitter- клон). Однако отправка всех обновлений всем подписчикам (с циклом); Разве это не ресурсоемко (учитывая, скажем, миллион записей?) - person shachibista; 20.01.2011
comment
... добавление к моему предыдущему комментарию: Разве модель не должна быть обратной? (Чтобы подписчики получали записи только тогда, когда им нужно, то есть не заранее)? Надеюсь, я смог уточнить. - person shachibista; 20.01.2011
comment
@ a110y С Redis все находится в памяти (не блокируется), поэтому будет молниеносно. Вы можете сделать этот цикл из рабочего процесса (ов) без каких-либо усилий. Вы используете очередь сообщений, чтобы добавить указатель (ссылка на KEY) для твита (сообщения) для каждого пользователя вместо того, чтобы делать очень дорогие JOINS (SQL !!!). Также я хотел бы указать на этот отличный учебник от Саймона, объясняющий redis = ›simonwillison.net/static/2010/redis-tutorial. Надеюсь, это тоже имеет смысл;) - person Alfred; 20.01.2011
comment
+1 за полезную ссылку. Я постараюсь реализовать прототип, прежде чем разгоняться на полной скорости. Однако не могли бы вы немного уточнить свою реализацию? Как лучше всего достичь моей цели? с помощью pub / sub в Redis или метода входящих? Заранее извиняюсь, если мои вопросы кажутся слишком очевидными, я очень новичок в Redis (только 1 день воздействия: p), и мне трудно обернуть мою голову СУБД вокруг других парадигм баз данных (K / V, на основе документов и т. Д. .) - person shachibista; 21.01.2011
comment
@ a110y Извините, но я был в отпуске, но я бы начал с pubsub (масштабируется очень хорошо, но я думаю, что почтовый ящик будет масштабироваться лучше), потому что это очень легко реализовать (1 секунда;)). Но я думаю, что почтовый ящик будет лучше масштабироваться, но это в будущем, когда у вас будет много пользователей;). Вы должны сначала заставить его работать, а затем подумать о проблемах масштабирования, я думаю ... Хотя метод папки входящих сообщений также может быть написан довольно быстро (в течение (может быть, пары) дней;)). Я постараюсь написать что-нибудь, когда у меня будет свободное время ... - person Alfred; 24.01.2011