Масштабируемая база данных MySQL для подобного почте обмена сообщениями
Предположите, что у нас есть популярный сайт. Мы должны реализовать подобный почте обмен сообщениями между пользователями. Стандартное решение состоит в том, чтобы использовать 2 таблицы:
Пользователи (user_id)
Сообщения (message_id, sender_id (ссылки user_id), receiver_id (ссылки user_id), предмет, тело).
Этот метод имеет 2 значительных ограничения
- Все сообщения всех пользователей хранятся в одном продвижении таблицы к, он - высокая загрузка и уменьшение полной производительности базы данных.
- Когда кто-то должен отправить сообщение нескольким пользователям одновременно, сообщение копируется (recipients_count) времена.
Другое решение использует 3 таблицы:
Пользователи (user_id)
Sent_messages (sent_id, sender_id (ссылки user_id), предмет, тело)
Received_messages (sent_id, receiver_id (ссылки user_id), предмет, тело)
предмет и тело received_messages копируются с соответствующих полей sent_messages.
Этот метод приводит к
- Денормализовывание базы данных путем копирования информации от одной таблицы до другого
- Пользователи могут на самом деле удалить, отправил/получил сообщения, не удаляя их из получателей/отправителей.
- Сообщения занимают приблизительно в 2 раза больше места
- Каждая таблица загружается приблизительно в 2 раза меньше.
Таким образом, здесь идут вопросы:
- Какой продуманного дизайна лучше для высокой загрузки и масштабируемости? (Я думаю, что это - второе),
- Есть ли другое проектирование баз данных, которое может обработать высокую загрузку?Что это? Каковы ограничения?
Спасибо!
P.S. Я понимаю, что прежде, чем добраться до этих масштабируемость выходит, сайт должен быть очень успешным, но я хочу знать, что сделать, если я должен.
ОБНОВЛЕНИЕ
В настоящее время для первых версий я буду использовать дизайн, предложенный Daniel Vassallo. Но если все будет в порядке в будущем, то дизайн будет изменен на второй. Благодаря Выворачивают для смягчения моего предчувствия об этом.
2 ответа
Вы можете захотеть избежать копирования тела сообщения несколько раз в случае, когда сообщение отправляется нескольким получателям. Вот еще один вариант, который вы можете рассмотреть:
users (user_id)
messages (message_id, sender_id, subject, body)
received_messages (message_id, user_id, address_mode, deleted)
Эта модель может быть больше похожа на twitter, чем на электронную почту, но она может иметь некоторые преимущества.
Правила таковы:
- Сообщение может быть отправлено только одним пользователем, на которого ссылается sender_id каждого сообщения.
- Каждый получатель будет определен в таблице received_messages. Поле address_mode может определять, было ли сообщение отправлено получателю напрямую, или как CC, или, возможно, как BCC. Это поле является необязательным.
- Удаленные получателями сообщения будут отмечены флагом deleted в таблице received_messages.
- Пересланные сообщения и сообщения с ответами должны быть созданы заново с новым идентификатором отправителя. После этого тело сообщения может быть изменено.
Вот некоторые из преимуществ:
- Это занимает меньше места, чем два варианта, упомянутые в исходном вопросе, особенно если пользователи обычно отправляют сообщения нескольким получателям.
- Более простое кэширование таблицы сообщений, поскольку сообщения никогда не дублируются.
- При удалении сообщения получателем не стирается информация о том, что сообщение было отправлено этому пользователю. Оно просто будет помечено как "удаленное" в таблице received_messages.
- И вы также получаете нормализованную модель.
Для большинства приложений, если вы используете оптимистичный уровень изоляции с приведенной выше моделью, у вас не должно быть проблем с производительностью, даже если вы ожидаете, что сообщения будут обмениваться со скоростью несколько в секунду. С другой стороны, если вы ожидаете сотни или тысячи сообщений в секунду, тогда действительно может возникнуть необходимость рассмотреть другие варианты.
В общем случае размер базы данных не будет иметь большого значения. Гораздо важнее скорость.
Поэтому я бы склонялся ко второму варианту. Как вы уже сказали, это значительно упрощает такие вещи, как удаление сообщений, и я уверен, что это очень распространенный способ сделать это.