Дизайн базы данных для Facebook-подобных сообщений

Ответ 1

MySQL не имеет проблем с миллионами или сотнями миллионов записей, если вы правильно проектируете свою базу данных.

Таким образом, "функция сообщений, такая как Facebook", является довольно широким определением. Как правило, вы определяете таблицу messages, которая связывает каждое сообщение с пользователем, который его создал (т.е. Имеет столбец userId в таблице сообщений). Если вы хотите, чтобы сообщения отправлялись нескольким пользователям, у вас есть таблица message_recipients, определяющая отношение "один ко многим", сохраняя несколько записей, состоящих из messageId и a recipientId. Добавьте соответствующие индексы к этим таблицам, и вы на 80% оттуда.

Таким образом, оставшиеся 20% могут быть убийцами. К сожалению, как вы используете свою базу данных, вы узнаете, что еще вам нужно сделать, и вам нужно будет предоставить гораздо больше подробностей о вашем приложении до того, как эти суждения могут быть сделаны. Например, вы можете подумать о том, чтобы иметь автоматическое архивирование, которое удерживает основную таблицу относительно маленькой и перемещает старые данные в резервные таблицы, к которым можно получить доступ, если это необходимо. Вероятно, вам это не понадобится, но это может помочь в будущем.

Ответ 2

Facebook начал с MySQL, и они переместились только на Cassandra, когда у них было 7 Тб входящих сообщений для более чем 100 миллионов пользователей.

Источник: Лакшман, Малик: Кассандра - децентрализованная структурированная система хранения.

Ответ 3

Если вы планируете обрабатывать большие объемы данных (конечно, миллионы даже не приближаются к квалификации как большие), то нанимайте профессионала-данта. Эффективный и эффективный дизайн базы данных для больших наборов данных является сложной проблемой и требует специалиста.

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

Ответ 4

Если вы правильно создаете свою базу данных, производительность должна ухудшать логарифмически с объемом данных. Другими словами, время выполнения ваших запросов будет расти гораздо медленнее, чем объем данных.

Для достижения этой цели вам нужно быть дисциплинированным в отношении нескольких вещей:

• Ваш дизайн базы данных должен быть надежным. Понимание ER-моделирования и нормализация имеет важное значение. Так понимает анатомия индексов и другие физические структуры данных.
• После того, как у вас есть хорошая нормализованная база данных, подумайте, следует ли разумно денормализовать некоторые "ребра" ее из соображений производительности.
• В течение всего этого процесса помните, какие запросы будут выполняться вашим клиентским приложением ¹:
  • Индексы дизайна соответственно - указате конкретно на запросы, которые, как вам известно, вам понадобятся, не переиндексируйте!
  • Некоторые дизайнерские решения, такие как использование естественных или суррогатных ключей и идентификационные и неидентифицирующие отношения, могут влиять на количество JOIN, которые вам понадобятся.
  • Попробуйте сохранить дизайн базы данных дружественным для сканирования кластеризованного диапазона, индексировать только сканирование и т.д.
• Для использования преимуществ используйте специальные механизмы, такие как clustering, разбиение на разделы, сжатие ключей, материализованные представления (и т.д.). Если СУБД не поддерживает какой-либо механизм, который вы считаете необходимым, не бойтесь переключать СУБД! Например, таблицы InnoDB всегда кластерируются, что является преимуществом при запросе на ПК, но может быть недостатком, если вам нужны вторичные индексы. Если вам нужны как кластерные, так и кучевые таблицы, используйте некоторую СУБД, которая поддерживает их обоих (например, Oracle или MS SQL Server). ²
• Внимательно укажите клиентское приложение. Религиозно использовать связанные параметры и запрос подготовка - вы не только минимизируете накладные расходы на разбор и планирование SQL, но также будете устойчивы к SQL-инъекциям! ORM и библиотеки часто защищают вас от выполнения этого вручную, но вы все равно должны понимать, что происходит "под обложками".
• И последнее, но не менее важное: не ретранслировать по предположениям - measure вместо этого! Производительность базы данных может быть тонким (и довольно сложным) балансирующим действием, а влияние определенных решений может быть не сразу очевидным.

Если вы все это сделаете правильно, вам придется приблизиться к фактическим объемам данных Facebook, прежде чем "классическая" СУБД перестанет быть адекватной. 1000 пользователей и миллионы или сообщения даже не квалифицируются как "большие" в этом контексте.

¹ "Клиент" с точки зрения СУБД - это может быть и средний уровень.

² MyISAM также не сгруппирован, но имеет серьезные ограничения (например, отсутствие поддержки транзакций), которые в любом случае должны дисквалифицировать его от обычного использования.

Ответ 5

Если вы находитесь в бюджете, начните с MySQL и используйте такую ​​систему, как Zend:: DB или более высокоуровневую Doctrine.

Более важно, чтобы было проще переключать DMBS, а затем выбирать СУБД в начале.

Ответ 6

Пока вы настраиваете свои таблицы как реляционные и устанавливаете отношения между таблицами, MySQL должен быть в порядке.

Могу ли я также предложить Postgres?

Ответ 7

Вы не очень точно знаете, что хотите узнать. Хорошо. Я постараюсь дать вам несколько советов.

• Нормализация
• Индексы
• MyISAM для таблиц с высокой нагрузкой
• Денормализация (sic!), но вы должны понимать, что вы делаете.
• Sharding
• Минимальный уровень DB для гибкости

Ответ 8

Шрайдинг, безусловно, не нужен для ваших "широко" требований... Я занимался большим количеством данных и даже не рассматривал разделенные таблицы и реализацию shard до тех пор, пока не было много таблиц, содержащих более миллиарда записей (тогда присоединение к ним могло бы стать немного медленным). Индексируйте свои таблицы с помощью интеллектуальных клавиш, и вы даже можете подумать об использовании структуры типа eav, чтобы узкие таблицы и освободить себя от нулевых возвратов по запросам.

Выше было написано в то время, когда он был спящим, поэтому игнорируйте опечатки;)

Ответ 9

Если вы имеете в виду "что должна выглядеть моя таблица mysql для системы сообщений", я использую следующие столбцы в своей системе сообщений:

message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread

Message_id - auto_increment, очевидно. Fromuser и touser очевидны. Fromstatus и tostatus активны, удалены, очищены, черновики и аналогичные. Fromview и toview настроены на "да" и "нет". Название, текст и дата "poston" очевидны. Тема может потребовать немного усилий с вашей стороны в зависимости от ваших HTML-форм и сценариев отображения сообщений.

Для вашей формы создайте цикл foreach на основе поля "to:" и сохраните копию для каждого получателя.

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

Ответ 10

Я бы сказал, прочитав об объектно-ориентированных базах данных, а также о системах nosql, это очень интересная концепция, активно используемая известными фреймворками, такими как Ruby on rails, что позволяет вам меньше беспокоиться о ваших данных, поскольку вы можете просто сбросить ваш объект прямо в базу данных, я знаю, что это немного не по теме, но менее сложные базы данных означают более простой переход в масштабируемые системы, и я просто распространяю осведомленность

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