Дизайн базы данных для сообщений в Facebook [закрыт]

17

В настоящее время я планирую новую систему в PHP / MySQL и хочу, чтобы моя база данных могла обрабатывать количество данных, которые я планирую хранить. Одной из особенностей моего нового проекта является функция «сообщений», такая как Facebook. Я хочу убедиться, что создаю наилучший опыт для конечного пользователя. Веб-сайт в конечном итоге будет обрабатывать 1000 пользователей с потенциально миллионами сообщений в совокупности. Каким будет наилучший подход для проектирования базы данных? Является ли MySQL правильной базой данных?

    
задан Randy Gonzalez 19.02.2010 в 21:57
источник
  • Задавайте смутные вопросы, получите смутные ответы! –  mjv 19.02.2010 в 22:04
  • @mjv, что неясно –  Jun 26 '12 at 11:00 26.06.2012 в 13:00
  • Является ли это просто мной или «сообщениями типа Facebook» и «наилучшим опытом для конечного пользователя» противоречиво? –  andrewtweber 27.06.2012 в 05:42

10 ответов

16

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

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

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

    
ответ дан zombat 19.02.2010 в 22:09
источник
  • По моему опыту, почти каждый человек или компания преувеличивает свои требования от 10x до 100x реальности, когда они планируют систему. Когда вы сомневаетесь, начните просто, купите 1 сервер и запустите с него веб-сервер и базу данных. Не беспокойтесь о нескольких серверах, пока они вам не понадобятся. Единственная причина иметь несколько серверов с первого дня - это потому, что вы хотите провалиться, и даже тогда вы можете обнаружить, что первоначальные затраты превышают ваши недостатки. –  TravisO 19.02.2010 в 23:06
  • @TravisO - 100% согласен. –  zombat 19.02.2010 в 23:12
  • @TravisO, по крайней мере, с SQL-сервером, вы даже не должны его класть на сервер с чем-либо еще. Сервер SQl предназначен для использования всей памяти сервера и меньше, чем для того, чтобы калечить его. –  HLGEM 27.06.2012 в 19:19
11

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

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

ответ дан Daniel Vassallo 19.02.2010 в 22:04
источник
  • Точно, начните с малого, держите свои затраты на низком уровне. Просто потому, что вы хотите стать следующим Facebook, это не значит, что вам нужно потратить где-нибудь около суммы денег или времени на разработку широкой системы. Каждый успешный сайт стал простым, быстрым и дешевым. Над проектированием вашей системы воняет «преждевременная оптимизация». –  TravisO 19.02.2010 в 23:08
7

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

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

    
ответ дан HLGEM 19.02.2010 в 22:01
источник
3

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

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

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

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

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

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

    
ответ дан Branko Dimitrijevic 26.06.2012 в 16:21
источник
2

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

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

    
ответ дан douwe 19.02.2010 в 22:09
источник
1

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

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

    
ответ дан MRR0GERS 19.02.2010 в 22:02
источник
  • Я имел равный опыт работы с MySQL, PostGres и MS SQL ... Моим предпочтением является MS SQL, но поскольку затраты на запуск очень важны в новых проектах, PostGres будет моим предпочтением для этого или любого проекта. –  TravisO 19.02.2010 в 23:10
0

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

  1. Нормализация
  2. Индексы
  3. MyISAM для таблиц с высокой нагрузкой
  4. Денормализация (sic!), но вы должны понимать, что вы делаете.
  5. Sharding
  6. Минимальный уровень DB для гибкости
ответ дан codeholic 19.02.2010 в 22:14
источник
0

Если вы имеете в виду «что должна выглядеть моя таблица 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:» и сохраните копию для каждого получателя.

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

    
ответ дан Bryan 20.02.2010 в 13:58
источник
0

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

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

    
ответ дан Matt 20.02.2010 в 10:52
источник
0

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

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

ответ дан serdarsenay 29.06.2012 в 12:57
источник