Проектирование баз данных для подобных Facebook [закрытых] сообщений
8 ответов
Если у вас бюджет, начните с MySQL и используйте такую систему, как Zend:: DB или на более высоком уровне доктрины.
Более важно упростить переключение DMBS, а затем сначала выбрать СУБД.
-121--2309913- Список можно получить, находясь в Visual Studio: нажмите Ctl + Alt + E
EDIT : я смог найти этот сайт, который имеет довольно полный список исключений .NET и краткое описание того, что
-121--2585263-MySQL не имеет проблем с миллионами или сотнями миллионов записей, пока вы правильно создаете базу данных.
При этом "функция сообщений, подобная Facebook" является довольно широким определением. Как правило, определяется таблица messages , связывающая каждое сообщение с пользователем, который его создал (т. е. столбец userId в таблице сообщений). Если вы хотите, чтобы сообщения отправлялись нескольким пользователям, у вас есть таблица message _ recipients , определяющая отношение "1 ко многим" путем сохранения нескольких записей, состоящих из startId и recipiveId . Добавьте нужные индексы к этим таблицам, и вы 80% пути там.
При этом, оставшиеся 20% могут быть убийцей. К сожалению, то, как вы используете свою базу данных, будет определять, что еще вам нужно сделать, и вам придется предоставить гораздо больше подробностей о вашем заявлении, прежде чем эти решения могут быть вынесены. Например, может потребоваться решение для автоматического архивирования, которое сохраняет относительно небольшой размер основной таблицы и перемещает старые данные в таблицы резервного копирования, к которым при необходимости можно получить доступ. Вам, наверное, это не понадобится сразу, но это может помочь в будущем.
Facebook начал с MySQL и перешел на Cassandra только тогда, когда у них было 7 ТБ данных о входящих сообщениях более 100 миллионов пользователей.
Источник: Лакшман, Малик: Cassandra - децентрализованная структурированная система хранения данных.
Если вы планируете обрабатывать большие объемы данных (конечно, миллионы даже близко не считаются такими большими), тогда наймите специалиста по базам данных. Эффективное и действенное проектирование базы данных для больших наборов данных - сложная задача, требующая специалиста.
Отвечая на ваш вопрос: да, mysql может легко обрабатывать миллионы записей, если дизайн хороший, и будет кошмаром, если дизайн плохой, как и любая другая современная база данных.
Если вы настроили таблицы как реляционные и установили связи между таблицами, MySQL должен работать нормально.
Могу ли я также предложить Postgres?
Если у вас ограниченный бюджет, начните с MySQL и используйте такую систему, как Zend :: DB или Doctrine более высокого уровня.
Более важно упростить переключение DMBS, чем сначала выбрать СУБД.
Вы не очень точно понимаете, что хотите узнать. Хорошо. Я постараюсь дать вам совет.
- Нормализация
- Индексы
- MyISAM для таблиц с высокой нагрузкой
- Денормализация (sic!), Но вы должны понимать, что делаете
- Шардинг
- Минималистичный уровень БД для гибкости
Если вы имеете в виду «как должна выглядеть моя таблица mysql для системы сообщений», я использую следующие столбцы в моей системе сообщений:
message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread
Message_id, очевидно, является auto_increment. Fromuser и touser очевидны. Fromstatus и tostatus активны, удалены, очищены, черновики и т. Д. Fromview и toview установлены на «да» и «нет». Заголовок, текст и дата публикации очевидны. Тема может потребовать от вас немного усилий в зависимости от ваших html-форм и сценариев отображения сообщений.
Для вашей формы создайте цикл foreach на основе поля «to:» и сохраните копию для каждого получателя.
Я ожидаю, что эта система сообщений будет содержать миллионы, но до миллионов, вероятно, потребуется пара лет. Я делаю это маленьким и простым.
Шардинг определенно не является необходимым для ваших «общих» требований ... Я имел дело с большим количеством данных и даже не рассматривал секционированные таблицы и реализацию сегментов, пока не появилось множество таблиц, содержащих более миллиарда записей (тогда присоединение к ним может быть немного медленным). Индексируйте свои таблицы с помощью интеллектуальных ключей, и вы можете даже подумать об использовании структуры типа eav, чтобы ограничить таблицы и избавить себя от нулевых возвратов по запросам.
Выше было написано в полусне, поэтому не обращайте внимания на опечатки;)