Чат и не прочитанные сообщения пользователя, как правильно спроектировать БД?

Question

[CartmanGui]

Нужно сделать чат что то на подобии как сообщения vkontakte. Т.е любой может создать беседу пригласив в комнату n-е количеств людей, после чего между ними идет общение, в любой момент можно закрыть окно чата но открыв его через определенное время все равно увидеть все сообщение от участников беседы и вот для такого пользователя и нужно сделать вывод сообщение, что у него есть непрочитанные сообщения в конкретном чате(комнате)

Я набросал схему БД, но вот как правильно реализовать возможность получить не прочитанные сообщения для каждого пользователя в комнате не могу сообразить. Была идея связать пользователя и сообщение через вспомогательную таблицу read_user_mess с флагом было ли прочитано сообщение пользователем но напрягает, что при создании сообщение придется делать кучу вставок в read_user_mess для user которые находятся к комнате в которую пришло сообщение такой вариант конечно приемлем если туда будут попадать записи только тех кто прочитал сообщение, а не сразу всех кто находится в комнате но тогда как создать запрос на выборку сообщений не прочитанных пользователем к комнате

Answer 1

[Сергей Протько]

Вставки не проблема, так как вы всеравно должны будете организовать какой-то буфер в памяти, например для reddis и обновлять все это добро пачками а не по одному, и желательно в отдельном потоке, через ZeroMQ например.

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

Comments

[CartmanGui]

а каким образам завязать reddis и mysql? когда делать выгрузку из reddis в mysql

[Сергей Протько]

@CartmanGui: реддис выступает в роли быстрого промежуточного хранилища, у вас должен быть так же скрипт который записывает всю эту информацию в базу и синхронизирует все это добро. Как часто - решать вам.

[Alex]

Redis. Хватит путать людей выдуманными названиями)

[Сергей Протько]

@shoomyst: как-то что-то да... надо бы поспать.

[CartmanGui]

а как быть в ситуации когда нужно делать подгрузку истории сообщений? Т.е пользователь зашел в чат, ему отобразились последние 10 сообщений, при прокрутки скрола до последнего сообщения происходит автоматическая подгрузка еще 10 предыдущих и т.д но т.к сообщения подгружаются из Redis то может сложиться ситуация когда там будет меньше сообщений чем нужно отдать в запросе т.к они уже хранятся в Mysql

[Сергей Протько]

@CartmanGui: историю подгружайте уже из базы. В реддис буфер на запись а не на чтение. А вообще может быть и забейте пока.

Answer 2

[Степан Горопашный]

Если все верно понял, то
У сообщения подразумевается дата.
У пользователя можно писать дату выхода из чата.
соответственно непрочитанные - просто разница по дате.

Comments

[CartmanGui]

да я пока тоже к такому варианту пришел

[CartmanGui]

когда на стороне клиента происходит обрыв то это момент отслеживается через событие в socket.io, но вот если упадет сервер то тогда да могут быть проблемы

Answer 3

[Alexander Kaloshin]

Для хранения недоставленный сообщений целесообразнее использовать redis и сделать это следующим образом:

Если пользователь в данный момент не онлайн, записывать сообщения в редис через rabbtimq (ZeroMQ) специальными воркерами. Тогда удастся размазать нагрузку и не будет пиков.

Так же желательно все сообщения для конкретного пользователя хранить в его "личном" списке, а не списке комнаты, тогда есть возможность (при необходимости) при успешном получении - очищать кеш и redis не будет раздуваться.

Если же необходимо хранить историю сообщений - желательно написать воркер, который раз в n секунд будет забирать данные из кеша и записывать в БД в отдельную коллекцию или таблицу, и так же очищать кеш.

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

Зачем нужна отдельная таблица (коллекция) - так как непрочитанные сообщения - данные, находящиеся постоянно в работе - данная таблица не будет постоянно увеличиваться в размерах (будет, но существенно медленнее, ведь её так же надо очищать), соответственно выборка по данной таблице с учетом индексации будет гораздо быстрее.

Успехов :)