Как правильно реализовать систему обмена сообщениями на MongoDB/NodeJS?
Необходимо реализовать систему обмена сообщениями с помощью MongoDB/NodeJS. Необходимо, чтобы пользователь видел список диалогов с пользователями и при выборе диалога видел полную с ним переписку ( по примеру facebook и vkontakte).
Подскажите какую схему хранения сообщений и диалогов выбрать?
Нужно ли использовать две коллекции Messages и Dialogs и связывать их по айдишникам или все-таки все хранить в одной коллекции?
Какой подход больше подойдет для шардинга?
у монги есть один не приятный нюанс для вашей задачи. В будущем с высокой вероятностью вам прийдется каким-либо образом строить агрегацию данных ваших диалогов, и тогда при любом построении структуры коллекций прийдется делать map/reduce, что у монги получается не очень. Исходя из этих тезисов, я бы посоветовал хранить данные по старинке в чем нибуть реляционном, а горячие данные вливать во что-нибуть простое типа Redis или производных. Такой подход позволит и не проиграть в производительности и избежать проблем в дальнейшем развитии проекта.
P.S. когда то тоже страдал монгой, но потом пришло осознание, что для более менее сложного проекта без РСУБД никуда не деться:)
зависит от текущих задач. В том то и прелесть наличия отдельного стореджа. завтра ваша задача поменяется, вы меняете структуру "горячих данных", при этом процесс записи остается неизменным.
Например: сегодня вам нужно показывать диалоги (основной пост + комментарии), завтра туда добавляются лайки и репосты, послезавтра вы начинаете анализировать темы диалогов и предлагать в них же обсудить тему с заинтересованными людьми.
У меня, если честно, возник такой же вопрос. Если мы говорим о максимальной быстрой передаче сообщний от одного пользователя - другому, тогда уместнее всего, как мне кажется, посмотреть в сторону AMQP (например, RabbitMQ)
@sajgak
> я бы посоветовал хранить данные по старинке в чем нибуть реляционном
> P.S. когда то тоже страдал монгой, но потом пришло осознание, что для более менее сложного проекта без РСУБД никуда не деться:)
Возможно когда-нибудь придет осознание, что "инструмент берут от задачи", а монга и РСУБД могут вместе прекрасно жить в одном проекте выполняя свои задачи.
В свое время делал подобную переписку для сайта с использованием монго, + ко всему использовал редис как брокер сообщений. У меня была как раз схема с раздельным хранением диалогов и самих сообщений.
По-поводу, самой же монги, возможно нестабильный релиз был, но текла она у меня хорошо, до сих пор какие-то серьезные проекты опасаюсь на ней делать, кто может знает как сейчас ситуация?
Расскажите как вас именно хранятся диалоги сообщения (небольшой пример если можно), и как вы производите добавление/чтение сообщений диалога, какие использовали индексы? Наверняка есть какие-нибудь best practices?
Честно сейчас не вспомню все подробности, в общих словах, у меня было две коллекции dialogs и messages, в первой я хранил id диалога, массив пользователей которым он был доступен(в одном диалоге могли общаться более 2х человек, аналог скайпа - чатов или вк), название диалога(тема, т.е. участники могли называть свой диалог, например "Рабочие вопросы"), и соответственно сами сообщения, где был id диалога которому они принадлежат, массивы id юзеров которые прочитали и удалили это сообщение и прикрепленный контент ввиде массива ссылок на графическую и медиа информацию в сети. Упрощенно и словами это было примерно так. Честно сказать у меня текла монга, возможно был нестабильный релиз, если бы не фича с многопользовательскими диалогами, выбрал бы мускул (если бы не хранение массивов и выборка по значениям в нем)
по-поводу чтения сообщений, пользователь заходил в сперва в список диалогов, соответственно при их выборке у меня имелись id и затем при переходе в диалог, серверу передавался его id и происходила выборка сообщений. Сообщение было одно для всех участников (одна запись в БД), только с массивом тех кто еще не прочитал и тех кто его уже удалил (позволило не плодить записи одного и того же), саму же запись производил при публикации сообщения в канал (Redis pub/sub)
Простой
Простой
