Нормализация базы данных для системы обмена сообщениями, подобной Facebook

#mysql #database #email #normalization #messaging

#mysql #База данных #Адрес электронной почты #нормализация #обмен сообщениями

Вопрос:

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

Я подумываю о создании таблицы сообщений с пятью столбцами:

 ID (PRIMARY KEY)
First_Person (FK user_id)
Second_Person (FK user_id)
Message
date
  

Я беспокоюсь о чтении этой большой таблицы.

поиск всех сообщений для человека (например, user_id 876)

 SELECT * FROM messages WHERE First_Person='876' OR Second_Person='876'
  

и связь между двумя людьми

 SELECT * FROM messages WHERE (First_Person='876' OR Second_Person='876') 
AND (First_Person='1500' OR Second_Person='1500') ORDER DESC BY date
  

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

Комментарии:

1. Итак, где хранится текст сообщения? В другой таблице?

2. Нет, в сообщении столбца (таблица сообщений).

3. Ох. Я прочитал это как «Дата сообщения», потому что в то время оно не редактировалось, чтобы поместить их в блок кода, и все они были в одной строке и не разделялись запятыми. Также вы говорите, что в нем четыре столбца, но, по-видимому, их 5.

4. Вы совершенно правы 🙂 Я добавил дату позже.

Ответ №1:

Вы правы, такая большая таблица непригодна для использования. Если вам нужна реальная система хранения сообщений, лучше посмотрите на решения NoSQL (такие как HBase, Cassandra, MongoDB и т. Д.), Просто вам придется забыть все, что вы знаете о реляционных базах данных.

Однако с MySQL вы все равно можете сделать что-то масштабируемое, если разделить таблицу на очень маленькие части. Сделайте так, чтобы в одной таблице хранились сообщения максимум от 1 тыс. пользователей (вам нужно будет записывать все сообщения дважды, если оба пользователя не из одной таблицы). Кроме того, храните не более 1 тыс. таблиц в одной БД, автоматически создавая другую, когда этот предел достигнут. Наличие нескольких баз данных (даже на одном физическом сервере) упростит администратору базы данных перенос каждой из них на новый сервер, когда текущий становится перегруженным. Чтобы получать сообщения определенного пользователя, ваш код должен будет получить требуемую базу данных / таблицу из имеющейся у вас карты.

Комментарии:

1. Спасибо за наводящий ответ. Поскольку все остальные данные находятся в mysql, неэффективно запускать другой сервер (например, MongoDB) параллельно. Я понимаю, что вы имеете в виду, разбивая строку на несколько таблиц; но я не понял, в чем полезность нескольких баз данных. Каждая таблица сохраняется как отдельный файл; таким образом, на извлечение данных из одной таблицы не влияет наличие других таблиц. Зачем создавать несколько баз данных?

2. Разделение (разбиение) таблицы на несколько делает каждую из них маленькой, поэтому ее можно легко искать, индексировать, изменять.

3. Хранение их всех в одной базе данных будет работать до тех пор, пока ваш диск / процессор не будут способны выполнять чтение / запись при небольшом трафике, но при увеличении популярности вам придется добавить еще один сервер. И естественно перемещать целую базу данных, плюс безопасно. Нет ничего сложного в подключении к переменному хосту в коде, вы получите поддержку горизонтального масштабирования в exchange.