@kulli
web программист

БД для хранения сообщений чата, какую выбрать?

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

Структура бд:
tbl_dialog:
dialog_id - id Диалога
dialog_one_user_id - id первого юзера
dialog_two_user_id - id второго юзера
dialog_time - время создания диалога

tbl_message
chat_messages_id - id сообщения
chat_messages_text - текст сообщения
chat_messages_fk_dialog_id - id Диалога к которому относится сообщение
chat_messages_fk_user_id - id отправителя
chat_messages_fk_to_user_id - id получателя
chat_messages_ip - ip отправителя
chat_messages_isRead - прочитано ли сообщение получателем
chat_messages_isVisible_one_user - видимость сообщение для первого юзера
chat_messages_isVisible_two_user - видимость сообщение для первого юзера (для возможности отчисти сообщений, если просто удалять тогда сообщение пропадет из истории у обоих юзеров)
chat_messages_time - время отправки сообщения

Вся система работает с бд MySQL - InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?

Вот пока не поздно думаю стоит ли переписывать хранение сообщений на другую NoSQL БД, с ними не работал никогда, почитал доки и на первый взгляд ничего сложного...

В голове вертятся 2 варианта реализации:
1) перевести табличку tbl_message в коллекцию MongoDB и так же писать туда сообщения при каждой отправке (т.е. пользователь отправил 1 сообщение и мы его сразу в бд записали, по одной записи делать буду и так каждое сообщение). Как Mongo будет вести себя при вставке сообщения, когда в коллекции будет за 20 млн записей? Правильная ли эта схема?

1) Записывать каждое сообщение в память в виде массива сообщений (memcached или redis или еще что то - посоветуйте) и по крону допустим каждую минуту или 5 мин брать весь массив сообщений, писать через транзакцию в MySQL, далее чистим массив сообщений для новых записей. Так получается что не будет несколько инсертов в секунду, т.к. сообщения будут храниться в памяти. Но тут опять засада, сможет ли MySQL нормально работать с огромной таблицей 20млн записей?

Сам текст сообщений очень короткий, что то типа "Привет! Как дела?"
  • Вопрос задан
  • 13215 просмотров
Решения вопроса 1
@InoMono
Вполне себе любая развитая современная РСУБД годится для этой задачи.
MySQL, PostgreSQL...

А по мере роста нагрузки - тут не выбором СУБД нужно заморачиваться, а MQ-сервер ставить. Он гораздо легче сравиться с бешенными нагрузками.

Как вариант - Queue на базе Tarantool, например. Я даже не знаю что вы там должны такое сделать, чтобы заткнуть его производительность. При условии того, что на сервере достаточно много оперативной памяти.

Из самого критично подозрительного - полнотекстовый поиск.
Впрочем, полагаю, что полнотекстового поиска средствами MySQL или PostgreSQL вплоне хватит.

Если уж делать прям таки серьезный чат типа Slack, то для полнотекстового поиска я бы вообще отдельную специализированную БД держал бы. Например, SphinxSearch.

Но, для начала, возможностей PostgreSQL или MySQL будет вполне достаточно.

Что до Mongo... Если вам не нужна репликация без консистентности. Зато быстрая...
Так вот если вам не нужна такая репликация, то Монга вам не нужна.

РСУБД будут существенно быстрее.

Вот ежели вы планируете заводить ваш чат в кластер, когда одного сервера вам не хватит, то тут да, тут РСУБД не лучший выбор. Тут бы я рекомендовал как раз Монгу.
Но опять таки кластер серверов для чата вы без MQ не сделайте.

Вывод:

Начните с обычной РСУБД.
Как начнутся затыки - рассмотрите MQ
Как начнется рост до масштаба планеты - рассматрите Монгу.

Вся система работает с бд MySQL - InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?


Вам никто не мешает это проверить.
Сгенерируйте миллион случайных сообщений.

При грамотном использовании индексов - ровным счетом никаких проблем ни на миллионах ни на миллиардах записей.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@mixandrexvbm
Занимаюсь разработкой сайтов на Wordpress
Я для небольшого чата взял MySQL, а структуру по статье проектирование архитектуры чата взял. Сейчас начал перестраивать его на SphinxSearch.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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