Нормализовать или денормализовать на сайтах с высоким трафиком

Эффективность соединения часто переоценивается. Продукты баз данных, такие как Oracle, созданы для очень эффективного объединения. Соединения часто считаются плохо работающими, когда реальной причиной является плохая модель данных или плохая стратегия индексации. Люди также забывают, что денормализованные базы данных очень плохо справляются с вставкой или обновлением данных.

Главное, о чем следует помнить, - это тип приложения, которое вы создаете. Большинство известных веб-сайтов не похожи на обычные корпоративные приложения. Вот почему Google, Facebook и т. Д. Не используют реляционные базы данных. В последнее время эта тема активно обсуждается, и я записал ее в свой блог о.

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

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

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

Искусство планирования емкости довольно хорошее.

Вы можете послушать обсуждение этой темы создателями stack overflow в своем подкасте по адресу:
http://itc.conversationsnetwork.org/shows/detail3993.html

Первое: определите для себя, что означает высокий трафик:

• 50 000 просмотров страниц в день?
• 500 000 просмотров страниц в день?
• 5.000.000 просмотров страниц в день?
• более?

Затем рассчитайте это до вероятных пиковых просмотров страниц в минуту и ​​в секунду. После этого подумайте о данных, которые вы хотите запрашивать для каждого просмотра страницы. Могут ли данные кэшироваться? Насколько динамичны данные, насколько они велики?

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

При полной оптимизации реляционная база данных может быть удивительно быстрой при объединении таблиц!

Реляционная база данных редко используется в качестве серверной части для заполнения кеша или некоторых таблиц денормализованных данных. Я бы не стал делать денормализацию подходом по умолчанию.

(Вы упомянули поиск, посмотрите, например, lucene или что-то подобное, если вам нужен полнотекстовый поиск.)

Определенно лучший лучший ответ: Это зависит ;-)

Для проекта, над которым я работаю, мы пошли по маршруту денормализованных таблиц, поскольку мы ожидаем, что в наших основных таблицах будет высокое соотношение операций записи и чтения (вместо того, чтобы все пользователи обращались к одним и тем же таблицам, мы денормализовали их и установили каждый «пользовательский набор» для использования определенного осколка). Вы можете найти здесь http://highscalability.com/ для примеров того, как "большие сайты" справляются с объемом - Stack Overflow был недавно представлен.

Ни то, ни другое не имеет значения, если вы не кешируете должным образом.