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

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

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

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

Спасибо.
  • Вопрос задан
  • 1632 просмотра
Пригласить эксперта
Ответы на вопрос 4
@nirvimel
Стоит ли использовать для этих целей MongoDB/MySQL?

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

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

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

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

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

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

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

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

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

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

Переделывать все равно придется. Такова суровая реальность жизни.
Ответ написан
@Kostik_1993
Fullstack Web Developer | PHP | Laravel | Vue.js
Лучше использовать 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
Ответ написан
Комментировать
XXXXPro
@XXXXPro
Fullstack Web developer
Ключевой вопрос: коллективные чаты в такой системе возможны?
Если да, то тогда нужны следующие таблицы:
thread (сессия/тема)
thread_user (список пользователей, статус каждого, число сообщений, в том числе и непрочитанных, дата, когда пользователь читал сообщения в этой сессии в последний раз и т.п.)
thread_post — собственно сами сообщения (чтобы оно хранилось в одном экземпляре, а не по одному на каждого пользователя)
thread_links — связка сообщений из thread_post и пользователей (чтобы можно было удалять сообщения, не затрагивая других пользователей).
В остальном — согласен с nirvimel, нужно использовать SQL-решение и писать на том, что хорошо известно.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Кратко: по-канально (одна сессия = один канал) с разбивкой на типы.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы