Частная система обмена сообщениями, большой стол против множества столиков

Question

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

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

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

Каковы подводные камни / преимущества такого подхода? Я пишу на PHP, будет ли код, необходимый для написания, более громоздким, чем первый вариант с большими таблицами? Будет ли конечный результат с большим количеством меньших таблиц более надежным и беспроблемным, чем одна большая таблица? В случае большого количества одновременно работающих пользователей, как будет сравниваться производительность сервера в случае работы с одной большой таблицей против множества маленьких таблиц?

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

Answer 1

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

• Скорее всего, вы в конечном итоге будете использовать динамические имена таблиц в запросах (SELECT * FROM $username WHERE ...), делая интеллектуальные функции, такие как хранимые процедуры и, возможно, параметризованные запросы, намного сложнее, если не будет невозможным. Обычно это действительно плохая идея.

• Попробуйте переписать SELECT * FROM messages WHERE authorID = 1 ORDER BY date_posted DESC, но там, где "messages" находится где-то между 1 и 30000 различных таблиц. Сохранение моногамных отношений между таблицами сохранит их двунаправленность, что будет более полезным.

Если вы считаете, что размер таблицы действительно будет проблемой, создайте таблицу клонов «архивных сообщений» и периодически перемещайте старые и непрочитанные сообщения туда, где они не будут мешать. Также обратите внимание на то, что большинство программ для форумов с личными сообщениями позволяют ограничивать размеры входящих сообщений. Есть несколько способов решить эту проблему, сохраняя разумность.

Answer 2

Я согласен с @MarkR здесь - в том смысле, что изначально единственная таблица для сообщений - определенно способ продолжить. С течением времени и если у вас получится очень большая таблица, вы можете подумать, как лучше разбить таблицу на части. Это противоречит тому, как я обычно советую проектировать, но мы говорим об одной простой таблице - не огромной корпоративной системе.

Давным-давно (предварительная доступность баз данных SQL) я создал систему, в которой хранятся личные и публичные сообщения, и я могу подтвердить, что как только вы разделите логическую сущность базы сообщений на более чем одно все & sup1; становится намного сложнее; и я сомневаюсь, что для каждого файла правильный подход - накладные расходы будут огромными по сравнению с выгодой.

Избегайте автоинкремента [2] - и использование естественных ключей очень важно для будущей масштабируемости. Хорошая разработка, обеспечивающая возможность вставки и извлечения без блокировки, принесет больше пользы.

---

& ПОД1; Индексирование, создание потоков, поиск, очистка / архивирование.

& sup2; Естественные ключи лучше, если вы можете найти их для своих данных, так как автоинкрементный идентификатор не описывает данные вообще, а базы данных хороши для определения местоположения на основе первичного ключа, поэтому естественный первичный ключ может улучшить ситуацию. Автоинкремент может вызвать проблемы с распределенной базой данных; он также пропускает данные при внешнем представлении (чтобы увидеть количество зарегистрированных пользователей, просто создайте новую учетную запись и проверьте свой идентификатор пользователя). Если вы не можете найти естественный ключ, тогда UUID (или GUID) все еще может быть лучшим вариантом - при условии, что база данных имеет хорошую поддержку для этого в качестве первичного ключа. См. Когда использовать автоинкрементный первичный ключ, а когда нет

Answer 3

Создание одной таблицы на пользователя определенно не будет хорошо масштабироваться, когда большое количество пользователей с небольшим количеством сообщений. То, как MySQL обрабатывает открытие / закрытие таблиц, очень большое количество таблиц (скажем,> 10 тыс.) Становится совершенно неэффективным, особенно при запуске и завершении работы сервера, а также при попытке резервного копирования нетранзакционных таблиц.

Однако то, как вы сформулировали свой вопрос, звучит как случай преждевременной оптимизации. Сначала сделайте так, а потом исправьте проблемы с производительностью. Это всегда правильный способ делать вещи.

Разделение / разбиение станет необходимым, как только ваша шкала станет достаточно высокой. Но в то же время есть много других поводов для беспокойства. Сначала рассортируйте их:)

Одна таблица - это правильный путь перехода от ПО СУБД. Я рекомендую вам использовать его, пока не узнаете лучше.

Answer 4

Зависит от того, как работает ваша система сообщений. Есть ли проблема cuncurrency? Должно ли оно быть масштабируемым, поскольку приложение может вместить больше клиентов?

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

Модель данных для приложения реального времени рекомендуется "нормализовать" (таблица разделения) из-за "блокировки и фиксации" и проблемы избыточности данных.

1. Политика блокировки зависит от поставщика базы данных. Если у вас есть таблицы, которые имеют обновления и выбираются одновременно с приложением, возникает проблема «Блокировка» (уровень страницы, уровень строки, уровень таблицы в зависимости от поставщика). Некоторая плохая конструкция БД и приложения полностью блокирует таблицу, поэтому сообщение никогда не проходит.

2. Проблема с повторной привязкой стала более понятной. Если вы используете только одну таблицу, некоторая информация (например, о пользователе. Я думаю, один пользователь может отправить несколько сообщений) будет избыточной.

Попробуйте гуглить с "нормализацией", "блокировкой" ..

Answer 5

Разделение больших объемов данных на более мелкие наборы имеет смысл, если вы пытаетесь избежать проблем с блокировкой: например, - блокировка таблицы сообщений - выполнение больших выборок или одновременное обновление огромных объемов данных. В этом случае длительные запросы могут блокировать всю таблицу, и все должны ждать ... Вы должны спросить себя, произойдет ли это в вашем случае? По крайней мере, для меня это выглядит так, будто система обмена сообщениями не будет иметь таких вещей, потому что вся информация помещается в таблицу или извлекается из нее в довольно небольших наборах. Если это приложение, ориентированное на пользователя - например, получение всех сообщений для одного пользователя довольно легко и быстро, то же самое относится и к созданию новых сообщений для того или иного конкретного пользователя ... Если только у вас не будет огромного количества количество пользователей / сообщений в вашей системе.

Разделение данных на несколько таблиц также имеет некоторые недостатки - вам понадобится какая-то система управления или логика, как вы все делите - предоставление отдельной таблицы для каждого пользователя может вскоре превратиться в сотни или тысячи таблиц - что по моему мнение, не то чтобы приятно. Поэтому, вероятно, вам понадобятся другие критерии для разделения данных. Если вы хотите, чтобы логика разбиения была динамичной и легко настраиваемой - вам, вероятно, также необходимо как-то сохранить ее в БД. Как видите, сложность растет ...

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