Как сделать диалоги как vk, с минимальной нагрузкой?

Question

[vadikjust]

Добрый вечер, возник такой вопрос, как сделать диалоги, например, как в VK. Не нужно предлагать готовые скрипты, нужно просто подтолкнуть на мысль. В голову лезит создать таблицу с диалогами и вносить туда данные в json формате, но потом делать выборку будет сложно. Поэтому пока что тупик. Прошу ваших советов. Заранее спасибо)

Answer 1

[IceJOKER]

dialogs // id, name
dialog_users // dialog_id, user_id
messages // id,  dialog_id, user_id, message
users // id, name

Comments

[Артем]

Данный вариант не плох, но как же удаления сообщений?

[Артем]

Для атачей можно еще в таблицу messages добавить поле is_attachments, на случай если передаем файлы, ну и табличку messages_attachments с полями: message_id, file_name. Так например удобное будет выборку делать по всем атачам.

[AlikDex]

адрес со статьей или примеры быстрых запросов?

[xfg]

Артем: нужно еще таблицу добавить user_messages // user_id, message_id и при записи нового сообщения вставлять по строке для каждого участника диалога.

[Зелимхан Бельтоев]

xfg: зачем отдельную таблицу, когда тут же, в messages, можно добавить user_id (кстати, IceJOKER, у вас сейчас все сообщения "анонимными" получаются)

[xfg]

Зелим Бельтоев: тогда ты нарушишь вторую нормальную форму. Проще говоря, будет избыточность данных, то есть дублирование контента в поле message для каждого участника диалога.

Просто подумай, как бы ты в своем решении реализовал редактирование сообщения, которое уже сохранено в базе. Тебе придется обновлять кучу строк, вместо одной.

[Зелимхан Бельтоев]

xfg: ты серьезно? Если добавить user_id, то будет дублирование и отсутствие возможности редактирования?
Пересмотри с утра, в моем варианте нет ни дублирования, ни отсутствия возможности редактирования + одним запросом можно получить сообщение, а не городить inner join-ы или подзапросы, чтобы связать сообщение с пользователем

[Зелимхан Бельтоев]

xfg: все-таки понял твою мысль, но мы говорим о разном: я о том, что нужно хранить автора сообщения, а ты - о том, что у каждого пользователя должна быть своя цепочка диалога, из которой он может удалять не нужные ему сообщения.
Вопрос на засыпку: как ты хотел реализовать редактирование своего сообщения, если при добавлении оно не привязывается к тебе? =)

[xfg]

Зелим Бельтоев: ну я про редактирование как пример написал, а так да, нужно еще id автора сообщения хранить, чтобы только он мог редактировать. Да верно, у каждого своя цепочка диалога.

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

[IceJOKER]

Зелим Бельтоев: исправил.

[IceJOKER]

xfg: все равно по-моему глупо хранить копии сообщения, хотите, чтоб каждый пользователь мог по отдельности удалять сообщения? не вопрос! Добавьте еще одно поле deleted_by_user (int) , удалил один из пользователей - установили там его id, удалил второй пользователь - проверяем пустое ли это поле, если пустое, значит этот все же первый удалил и устанавливаем туда его id, если не пустой, значит сообщение можно полностью удалить .
а если в беседе несколько участников, то вот тогда придется новую таблицу завести, что-то типа
deleted_messages | user_id message_id deleted_at(тоже думаю пригодится)

[xfg]

IceJOKER: никаких копий нет, все данные во второй нормальной форме. Здесь очевидная связь многие ко многим. Один пользователь может иметь много сообщений и одно сообщение может принадлежать многим пользователям. Следовательно, для такой связи нужна доп. таблица. У вас все тоже самое с таблицей dialog_users, отношение M:M между диалогами и юзерами. Есть у вас в таблице dialog_users какие-то копии? Нет. Так с чего вы вдруг взяли что в таблице user_messages они будут? Эта точно такая же связующая таблица, только между двумя другими сущностями (messages <-> users).

[IceJOKER]

xfg: я вас просто неправильно понял, вы правы

[vadikjust]

А как составить запрос? уже голову сломал.

$get_users = $db->query ( "SELECT d.*, du.*
FROM dialogs d
LEFT JOIN dialog_users du ON du.user_id='$member_id'
WHERE d.dialog_id=du.id_dialog" );

[Евгений Бухарев]

Нужна ли таблица dialogs если у диалога нет названия? что в ней хранить? дату создания и сам ид? Нельзя ли совместить таблицу dialogs и dialog_users ?

[Евгений Бухарев]

Проектирование схемы базы данных для системы сообщений?

Answer 2

[Евгений Бухарев]

Одна таблица с сообщениями, в которой следующий минимум:
id, user_from, user_to, is_new, message, hide_on_user_from,hide_on_user_to,created_at
В гугле есть примеры запросов к такой таблице чтобы вытащить сами диалоги пользователя, ну а непосредственно сам диалог реализовать будет не так сложно

Comments

[Артем]

Данный вариант не предусматривает юзер лист с кем имеет пользователь диалоги.

[Евгений Бухарев]

Артем: как так не предусматривает? Вполне можно сделать выборку по отдельным диалогам у отдельного пользователя

[Артем]

evgenybuckharev: можно, но на несколько миллионов записей не лучшей перфоманс будет

[Евгений Бухарев]

Артем: Как по Вашему будет лучше? разбивать на отдельные таблицы?

[Артем]

evgenybuckharev: а вот как впервом ответе, по крайней мере у меня один в один реализация. Но там проблема с удалением конкретного сообщения, но так как у меня удаляется полностью диалог, мне было достаточно в табличке dialogs_users использовать поле deleted_at, и там уже делать выборку из таблицы messages вида select * from messages where dialog_id = 1 and created_at >= dialogs_users.deleted_at

[Евгений Бухарев]

Артем: По мне с одной таблицей куда проще, я также реализовывал систему сообщений, по началу рассматривал вариант с несколькими таблицами, потом всё таки решил сделать всё на одной, и не раз не пожалел, а в плане вывода диалогов пользователя, допустим на странице диалогов, то достаточно выбрать самые новые сообщения из каждого диалога, и на основе их строить непосредственно вывод, делается это один запросом, и не сказать что он нагруженные, а плане пользования такой таблице все намного проще, заносишь сообщения, удаляешь, никаких сложностей нет

[Артем]

evgenybuckharev: есть один убийственный для этого метода аргумент, включить более чем 2 пользователей в диалог. И так же всё-таки будет быстрее работать с таблицей где только численные значения. Данных меньше при тоже сортировке нужно считывать с диска. Опять же у нас есть поиск по сообщениях, и при таком подходе без группировке не обойтись, ну или нужно будет делать вложенные запросы к таблицы типа limit 1.

[Артем]

evgenybuckharev: просто в одном диалоге может быть к примеру 1 миллион записей, а в таблице диалогов всего 1 запись.

[Зелимхан Бельтоев]

Артем: насколько я знаю, в highload-ах денормализируют БД, добавляя дополнительные таблицы (например, в ВК - это таблица с последними сообщениями в каждом диалоге, чтобы, когда пользователь зайдет на страницу сообщений, можно было одним запросом вернуть список диалогов, а не делать запрос на диалоги + запрос на поиск последний сообщений). Я к тому, чтобы взяли на заметку и такую схему

Answer 3

[Владимир Грабко]

dialog
---------
id
users (в json формате храним всех юзеров что в этом диалоге)

userMessage
----------
userId
dialogId
message

При отправке тупо добавляем по сообщению всем участникам диалога
к примеру если стандартный диалог (вы и друг) то любое сообщение необходимо добавить в бд дважды (вам и другу)

По сути отправляем каждому юзеру это сообщение

UPD.
для юзер листа создаём таблицу в которой в формате json храним все диалоги в которых участвует юзер

Answer 4

[Радость моя]

Вообще если как в вк, то у них в открытом доступе есть исходники сервиса сообщений. (впрочем как и фоток)

https://vk.com/kitphp постучитесь сюда, там все материалы.