Действительно ли нормализация снижает производительность на сайтах с высоким трафиком?

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

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

6
c# denormalization normalization performance sql-server-2008

5 ответов

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

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

HTH.

4

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

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

нормализация может привести к снижению производительности. Однако это не повод для преждевременной денормализации.

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

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

1

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

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

1

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

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

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

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

0