Как оптимизировать сохранение истории чата в БД?

Question

[MyJaneDoe]

Привет.
Пишу бэкенд для небольшого приложения, в котором планирую сделать чат.
Раньше никогда чатами не занимался, встал вопрос как оптимизировать сохранение истории чата в БД (использую MongoDB).
Мне кажется (я могу ошибаться), что если при получении каждого нового сообщения сохранять его в базу (что-то типа ChatModel.findByIdAndUpdate(chat._id)), то это будет сильно нагружать процессор.

Можно делать по-другому: записывать все прилетающие сообщения в переменную. Затем каждые, например, N сообщений делать апдейт поля в базе, конкатинируя получившуюся строку с уже хранящейся.
Что не нравится здесь:
1) Если сервер упадет, все, что хранилось в переменной пропадет;
2) Такой подход тратит дополнительную оперативную память. Если принять среднюю длину сообщения за nLength, то затраты памяти будут расти как О (N * nLength)

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

Comments

[Александр Романов]

findByIdAndUpdate
Предполагается хранить каждый чат в одном документе? Ограничение на один документ будет мешать большим чатам
Я бы сделал примерно так:
1. Redis - тут кеш последних n сообщений
2. Коллекция чатов в которой 1 запись чата хранится в одном документе примерно с такой структурой:
chat_id
user_id
timestamp
status
message

Answer 1

[Roman K]

Мне кажется (я могу ошибаться), что если при получении каждого нового сообщения сохранять его в базу (что-то типа ChatModel.findByIdAndUpdate(chat._id)), то это будет сильно нагружать процессор.

Зависит от способа организации данных, от самих данных, от нагрузки. Одно дело, когда одновременно ведут диалог 10 человек и другое, когда 10 миллионов.

Можно делать по-другому: записывать все прилетающие сообщения в переменную. Затем каждые, например, N сообщений делать апдейт поля в базе, конкатинируя получившуюся строку с уже хранящейся.

1. Это ненадёжно. Например, у тебя работает 15 разработчиков, каждый из них деплоит 2 раза в день в течении рабочего дня. Итого, каждые ~16 минут у всех теряется несколько рандомных сообщений.
2. Ты хочешь сохранять каждые N сообщений. Представь, что я написал N-1 сообщений и потерялся на год. Уж за год сервер точно один раз передеплоят и все мои сообщения потеряются. Здесь нужны таймеры

В общем, посоветуйте хороший способ реализации быстрого и не слишком затратного способа сохранять историю чата

Установить rocketchat/mattermost/etc.

А если серьёзно, то проводи нагрузочные тесты. Если юзеров будет 1.5 землекопа — сделай просто "как-нибудь". Вот когда миллионы юзеров будут, тогда приходи... А стоп, когда у тебя будут миллионы юзеров, у тебя хватит денег нанять людей, которые перепишут как надо

Comments

[MyJaneDoe]

Представь, что я написал N-1 сообщений и потерялся на год. Уж за год сервер точно один раз передеплоят и все мои сообщения потеряются.

О, а это хороший тейк, я про него даже не подумал. Спасибо.

А стоп, когда у тебя будут миллионы юзеров, у тебя хватит денег нанять людей, которые перепишут как надо

Чтобы миллионы юзеров пришли, все должно изначально быть хорошо. Да и мне самому хочется понять и научиться делать как надо.

Установить rocketchat/mattermost/etc.

Пойду погуглю. Спасибо.

[Roman K]

MyJaneDoe,

Чтобы миллионы юзеров пришли, все должно изначально быть хорошо. Да и мне самому хочется понять и научиться делать как надо.

Это неправда

[MyJaneDoe]

Roman Kitaev, У меня возникла идея: все приходящие сообщения пихать в очередь. Затем раз в N времени считывать сообщения в очереди и сохранять все в базу.
Я хоть и работал с очередями, но мало, поэтому хотел бы спросить у тебя (если вдруг знаешь) насколько такое решение было бы хорошим.

Собственно это реализация описанного тобой выше "Здесь нужны таймеры". При деплое\падении сервера данные не потеряются. Норм ли такой вариант?

[AnenNua]

А что делать если я хочу быть тем человеком, который сделает как надо?