Задача создать чат между юзерами. My SQL.
Создаю 2 таблицы messages, users.
users : Список юзеров
messages : Сообщения между юзерами.
Выходит что таблица messages в случае большой нагрузки будет ОГРОМНОЙ (все сообщения между юзерами будут в ней)
Я чувствую что в структуре ошибка! Может есть решение, как правильней организовать структуру базы данных для этой задачи (чат между юзерами).
Не создавать же новую таблицу сообщений для каждого нового юзера.
Здравствуйте, FantasyDD, Вы писали:
FDD>Задача создать чат между юзерами. My SQL. FDD>Создаю 2 таблицы messages, users. FDD>users : Список юзеров FDD>messages : Сообщения между юзерами.
FDD>Выходит что таблица messages в случае большой нагрузки будет ОГРОМНОЙ (все сообщения между юзерами будут в ней) FDD>Я чувствую что в структуре ошибка! Может есть решение, как правильней организовать структуру базы данных для этой задачи (чат между юзерами). FDD>Не создавать же новую таблицу сообщений для каждого нового юзера.
Логически это одна таблица. Для того чтобы справиться с большим объемом данных, надо использовать партиционирование, например, новый раздел на каждый день или месяц
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
S>Логически это одна таблица. Для того чтобы справиться с большим объемом данных, надо использовать партиционирование, например, новый раздел на каждый день или месяц
Одно из решений.
Возможно есть более сложные структуры?
Если юзеров 1000 или более и все активные, иногда запросы на старые диалоги между юзерами. Нагрузка на messages будет неимоверной.
Здравствуйте, FantasyDD, Вы писали:
S>>Логически это одна таблица. Для того чтобы справиться с большим объемом данных, надо использовать партиционирование, например, новый раздел на каждый день или месяц
FDD>Одно из решений. FDD>Возможно есть более сложные структуры? FDD>Если юзеров 1000 или более и все активные, иногда запросы на старые диалоги между юзерами. Нагрузка на messages будет неимоверной.
Что значит неимоверной? Какого типа будут запросы, сколько? Надо выделить ключевые запросы и правильно построить индексы. А неимоверным в таком случае возможно будет только полнотекстовый поиск
Если структура чата подразумевает более сложные типы общения чем просто переписка между двумя участниками, то может быть нужна и другая структура (например, если есть конференции)
Но, чем больше данных тем проще должна быть таблица с сырыми данными, минимум нормализации — так индексы будут работать эффективнее.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, FantasyDD, Вы писали:
S>>Но, чем больше данных тем проще должна быть таблица с сырыми данными, минимум нормализации — так индексы будут работать эффективнее.
FDD>Может быть как вариант создавать каждому новому юзеру новую таблицу сообщений?
Ну это то же самое партиционирование, только по юзерам
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, FantasyDD, Вы писали:
S>>>Но, чем больше данных тем проще должна быть таблица с сырыми данными, минимум нормализации — так индексы будут работать эффективнее.
FDD>>Может быть как вариант создавать каждому новому юзеру новую таблицу сообщений?
S>Ну это то же самое партиционирование, только по юзерам
Каг бы тоже имеет смысл, но партиционирование по датам легко позволит убрать старые записи куда-нибудь подальше....
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Может для каждого юзера создавать в отдельной папке файд данных, и при обращении к нему читать и исправлять данные в файле.
Как то не красиво выглядит.
Здравствуйте, FantasyDD, Вы писали:
FDD>Может для каждого юзера создавать в отдельной папке файд данных, и при обращении к нему читать и исправлять данные в файле. FDD>Как то не красиво выглядит.
Можно прочитанные пользователем сообщения хранить у него на локальном клиенте, а на сервере удалять.
PS. Тут еще нужно определиться какой api будет у чата, а уж потом решать как делать шардинг.
Здравствуйте, FantasyDD, Вы писали:
FDD> Выходит что таблица messages в случае большой нагрузки будет ОГРОМНОЙ (все сообщения между юзерами будут в ней)
Ничего страшного. Правильно приготовленный MySQL себя вполне неплохо ощущает на достаточно больших объемах данных.
FDD> Не создавать же новую таблицу сообщений для каждого нового юзера.
Не надо. Если беспокоит нагрузка (на сайте?), то этот вопрос частично решается партициями в таблице по дате, но в основном за пределами базы (например, кэшированием).
AB>Не надо. Если беспокоит нагрузка (на сайте?), то этот вопрос частично решается партициями в таблице по дате, но в основном за пределами базы (например, кэшированием).
Мне посоветовали историю переписки хранить локально. Если не трудно, скажите в общих чертах как это выглядит.
Болшое спасибо всем за советы и участие! Решение принято.
Основную таблицу юзеров хранить в MySQL базе и для каждого юзера создавать папку в ней хранить переписку в Sqlite файле.
Здравствуйте, FantasyDD, Вы писали:
FDD>Если юзеров 1000 или более и все активные, иногда запросы на старые диалоги между юзерами. Нагрузка на messages будет неимоверной.
С чего ты взял? Смоделируй да померь нагрузку, если уж так пугает. Пока что ты пытаешься решать несуществующую проблему.
Premature optimization is the root of all evil. D. Knuth
Здравствуйте, FantasyDD, Вы писали:
FDD>Выходит что таблица messages в случае большой нагрузки будет ОГРОМНОЙ (все сообщения между юзерами будут в ней) FDD>Я чувствую что в структуре ошибка!
Пока что основной ошибкой выглядит запихивание чата в базу. Чат — это мимолётные, временные данные, и обмен ими через "постоянные" структуры заведомо сомнителен.
Для такой задачи напрашивается некий "чат-сервер", с которым пользователи работают вообще мимо базы. Если есть желание сохранять историю, чат-сервер может писать её в СУБД, и там уже никакой "огромной нагрузки" не будет.
