Архитектура системы личных сообщений?

Question

[serious911]

Здравствуйте.

На посещаемом сайте необходимо с нуля создать систему личных сообщений (текст + картинки) для пользователей (примерно как в ВК, но сильно проще). Поделитесь, пожалуйста, опытом как более правильно это сделать с самого начала, чтобы не пришлось потом переделывать на реальных пользователях. Основная задача - хорошо держать большую нагрузку + правильно хранить большие объемы данных (сообщений пользователей) + возможность масштабирования.

Стоит ли использовать для этих целей MongoDB/MySQL? Хранить все сообщения в одной таблице в виде текста? Если разбивать данные на шарды, то что делать с перепиской между пользователями на разных шардах? Что думаете про Node.js + Websockets для этих целей? Как правильно хранить сообщения пользователей на разных серверах?

Спасибо.

Comments

[lega]

> хорошо держать большую нагрузку + правильно хранить большие объемы данных (сообщений пользователей)

В цифрах пожалуйста.

[serious911]

Примерно 50-70к пользователей в сутки. По объемах данных - соответсвенно все сообщения которые пользователи генерируют в день + нужно хранить историю сообщений.

[serious911]

up! Нагрузка примерно 50-70к пользователей в сутки. По объемах данных - соответсвенно все сообщения которые пользователи генерируют в день + нужно хранить историю сообщений.

Answer 1

[nirvimel]

Стоит ли использовать для этих целей MongoDB/MySQL?

PostgreSQL или MySQL, но не в коем случае не NoSQL, который выглядит как панацея только поначалу.
Правильная проектировка структуры БД - залог производительности и нормальной разработки.
Ошибки в структуре БД - бомбы, подложенные под развитие проекта и дальнейшую разработку.

Хранить все сообщения в одной таблице в виде текста?

Все сообщения в одной таблице. Но в базе у вас в итоге окажется 10-20 или больше таблиц с разными метаданными, без которых тексты сообщений не имеют смыла.

Если разбивать данные на шарды,

Не надо этого делать.

Что думаете про Node.js + Websockets для этих целей?

Node.js - тех, кто начинал свою программистскую карьеру с фронтенда, надо на пушечный выстрел не подпускать к принятию архитектурных решений в крупных проектах. Архитектура для архитекторов, js для фронтендеров.
Websockets - чат предполагает push данных с сервера на клиент, а для этой задачи websockets почти не имеет реальных альтернатив на сегодняшний день. То есть все альтернативы - это костыли из времен до websockets.

Как правильно хранить сообщения пользователей на разных серверах?

Для начала нужно определиться с тем зачем это нужно. Потом постараться избавиться от этой опасной идеи.

чтобы не пришлось потом переделывать на реальных пользователях.

Переделывать все равно придется. Такова суровая реальность жизни.

Comments

[lega]

> PostgreSQL или MySQL, но не в коем случае не NoSQL

Для данных с плавающим размером без транзакций, NoSQL самое то, особенно если это хайлоад.

[serious911]

>Если разбивать данные на шарды,
>Не надо этого делать.

Если не разбивать данные на разные части/сервера, то рано или поздно все упрется в размер диска/базы на одном сервере?

Answer 2

[Константин Б.]

Лучше использовать PostgreSQL или MySQL для хранения, но и использовать NoSQl вам никто не запрещает, в нем нужно не хранить, а использовать его как кеш

На чем писать?
На чем умеете на том и пишите

Структура таблиц примерно такая

chat
id|from_user|to_user

message
id|chat_id|date

content
id|message_id|text

attached
id|message_id|path|ext

Answer 3

[4X_Pro]

Ключевой вопрос: коллективные чаты в такой системе возможны?
Если да, то тогда нужны следующие таблицы:
thread (сессия/тема)
thread_user (список пользователей, статус каждого, число сообщений, в том числе и непрочитанных, дата, когда пользователь читал сообщения в этой сессии в последний раз и т.п.)
thread_post — собственно сами сообщения (чтобы оно хранилось в одном экземпляре, а не по одному на каждого пользователя)
thread_links — связка сообщений из thread_post и пользователей (чтобы можно было удалять сообщения, не затрагивая других пользователей).
В остальном — согласен с nirvimel, нужно использовать SQL-решение и писать на том, что хорошо известно.

Comments

[4X_Pro]

В принципе, могу предложить посмотреть код моего форумного движка, там для хранения ЛС я нечто подобное делал.

Answer 4

[xmoonlight]

Кратко: по-канально (одна сессия = один канал) с разбивкой на типы.