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

Question

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

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

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

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

Answer 1

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

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