Действительно ли нормализация снижает производительность на сайтах с высоким трафиком? - PullRequest
6 голосов
/ 24 апреля 2010

Я проектирую базу данных и хотел бы нормализовать базу данных. В одном запросе я объединю около 30-40 таблиц. Повлияет ли это на производительность сайта, если он станет чрезвычайно популярным? Это будет основной запрос, и он будет вызываться в 50% случаев. К другим запросам я присоединяюсь около двух таблиц.

У меня есть выбор: нормализовать или не нормализовать, но если нормализация станет проблемой в будущем, мне, возможно, придется переписать 40% программного обеспечения, и это может занять много времени. Действительно ли в этом случае нормализация вредит? Должен ли я денормализовать сейчас, пока у меня есть время?

Ответы [ 5 ]

4 голосов
/ 24 апреля 2010

Я цитирую: «нормализуйте для правильности, денормализуйте для скорости - и только при необходимости»

Я имею в виду: С точки зрения баз данных, является ли «Нормализация для корректности, денормализация для производительности» правильной мантрой?

НТН.

3 голосов
/ 24 апреля 2010

Когда речь идет о производительности, обычно есть лучшие альтернативы, чем денормализация:

  • Создание соответствующих индексов и статистики по задействованным таблицам
  • Кэширование
  • Материализованные представления (индексированные представления в MS SQL Server)
  • Наличие денормализованной копии ваших таблиц (используемой исключительно для запросов, которые в них нуждаются), в дополнение к нормализованным таблицам, которые используются в большинстве случаев (требует написания кода синхронизации, который может выполняться как триггер или запланированное задание в зависимости от необходимой точности данных)
1 голос
/ 24 апреля 2010

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

Я согласен с другими, не преждевременно оптимизируйте свой сайт. Тем не менее, вы должны оптимизировать свою архитектуру с учетом вашего основного варианта использования. объединение в 40 таблиц для запроса, выполняемого более 50% времени, не оптимизировано IMO.

1 голос
/ 24 апреля 2010

Нормализация может ухудшить производительность. Однако это не повод преждевременно денормализовать.

Начните с полной нормализации, и вы увидите, есть ли у вас проблемы с производительностью. При скорости, которую вы описываете (1000 обновлений / вставок в день), я не думаю, что вы столкнетесь с проблемами, если таблицы огромные.

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

0 голосов
/ 24 апреля 2010

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

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

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

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

...