Как / Самый эффективный способ отправить сообщение многим пользователям? - PullRequest
4 голосов
/ 20 августа 2010

Хорошо, у меня есть сайт с пользователями.Я хочу, чтобы пользователь мог отправить сообщение нескольким пользователям на основе запроса search .

Например.Джон ищет по запросу "Флорида", и этот поиск возвращает 1 миллион пользователей / компаний.Как лучше всего разрешить Джону отправлять сообщения всем тем пользователям / компаниям, которые были возвращены в результате поиска?

Допустим, Сьюзен была одним из этих пользователей.Когда она заходит на сайт, она должна видеть сообщение, которое Джон отправил (поскольку Сьюзен была в результатах, возвращенных поиском)

(NB: сообщения являются внутренними для сайта (не электронные письма))

У меня есть таблица «Message», в которой хранится основное сообщение.

Вариант 1: иметь таблицу участников, в которой хранятся message_id и user_id.Однако для этого потребуется сделать 1 миллион вставок в эту таблицу.

Вариант 2: ????

Есть идеи, какой самый эффективный / лучший способ сделать это?


**** РЕДАКТИРОВАТЬ: Чтобы уточнить для использования этого. ****

Это не спам.

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

Ответы [ 3 ]

2 голосов
/ 20 августа 2010

Таблица USER_MESSAGES довольно мала - это пересечение между СООБЩЕНИЯМИ и ПОЛЬЗОВАТЕЛЯМИ (т.е. получателями). Так что это два столбца внешнего ключа и, возможно, статус. Так что, хотя у него может быть много записей, они не займут много места. Это не значит, что вам нужно хранить экземпляр сообщения для каждого получателя.

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


"Я был просто обеспокоен тем, что стол будет быстро расти. "

У вас всегда есть возможность вести хозяйство за столом. Если получатели удаляют «сообщение», уберите запись пересечения. Возможно, добавьте столбец даты, а затем тайм-аут «сообщений», которые не были прочитаны в определенный период времени. На самом деле это звучит как положительная особенность: учитывая вашу бизнес-модель, отправитель, по-видимому, хочет получать своевременные ответы и не будет заинтересован в ответах на предложение, которому уже три месяца.

"Я надеялся, что будет больше эффективный / элегантный "

Все зависит от вашего определения эффективности. Дисковое хранилище дешево, но относительно медленно. Оперативная память быстрая, но относительно дорогая (хотя через несколько лет SDD будет дешевым). Так что вы хотите оптимизировать? Сколько времени понадобится Джону, чтобы отправить снимок? Сколько времени нужно Сьюзен, чтобы прочитать сообщение? Сколько вы должны потратить на жесткие диски? Сколько времени вы тратите на настройку среднего уровня?

1 голос
/ 20 августа 2010

Одним из решений было бы создание групп пользователей - в зависимости от местоположения из вашего вопроса - чтобы сообщение отправлялось группе, а не каждому человеку. Чтобы управлять, читать или нет, вы могли бы просто иметь функцию «Сообщения группе« Флорида »за последние x дней / недель / что угодно», которую было бы достаточно легко реализовать.

Это избавит вас от необходимости делать миллион вставок. К сожалению, я не уверен в лучшем способе управления входящими сообщениями, но я уверен, что кто-то более знающий, чем я, сможет добавить к тому, что я предложил.

0 голосов
/ 20 августа 2010

Это типичная функция для почтового сервера. Так ..

A. Другим решением было бы просто использовать реальную почтовую систему / сервер в фоновом режиме.

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

В любом случае, подумайте о том, что вы, вероятно, должны предоставлять такие функции, как: чтение сообщения, непрочитанное сообщение, пометка сообщения (как важная и т. Д.), Удаление сообщения. Итак, я считаю, что нет способа избежать одной записи на сообщение на пользователя. Теперь давайте подумаем, сколько сообщений действительно может быть в этой таблице в БД. Если один пользователь имеет в среднем 100 сообщений в своем почтовом ящике (кстати, что огромно, мы говорим о среднем), это будет означать (см. ответ APC ) таблицу с 2 столбцами (целыми числами), имеющими 5 миллионов строк, проиндексированных на user_id. Это не проблема для любой серьезной БД.

B. Теперь, если вы действительно обеспокоены производительностью, вы можете использовать хеш-память / БД (только для сообщений), например Memcached, Tokio Cabinet, CouchDB, MongoDB и т. Д.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...