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

Question

Каковы лучшие практики для проектирования и нормализации баз данных для сайтов с высоким трафиком, таких как stackoverflow?

Следует ли использовать нормализованную базу данных для ведения учета или нормализованную технику или их комбинацию?

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

или

Следует ли денормализовать основную базу данных, но с нормализованными представлениями на уровне приложений для быстрых операций с базой данных?

или какой-то другой подход?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Авторы стека переполнения на своем подкасте могут прослушать дискуссию на эту тему по адресу:
http://itc.conversationsnetwork.org/shows/detail3993.html

Answer 4

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

• 50.000 просмотров страниц в день?
• 500.000 просмотров страниц в день?
• 5.000.000 просмотров страниц в день?
• больше?

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

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

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

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

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

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

Answer 5

Не имеет значения, правильно ли вы кешируете.

Answer 6

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