Нормализация действительно повреждает производительность в сайтах интенсивного трафика?
Я разрабатываю базу данных, и я хотел бы нормализовать базу данных. В одном запросе я буду, присоединяясь приблизительно к 30-40 таблицам. Это повредит производительность веб-сайта, если это когда-нибудь станет чрезвычайно популярным? Это будет основным запросом, и это будет получать названные 50% времени. Другие запросы я буду присоединяться приблизительно к двум таблицам.
У меня есть выбор прямо сейчас, чтобы нормализовать или не нормализовать, но если нормализация становится проблемой в будущем, мне, вероятно, придется переписать 40% программного обеспечения, и мне может потребоваться долгое время. Нормализация действительно причиняет боль в этом случае? Я должен денормализовать теперь, в то время как у меня есть время?
5 ответов
Цитирую: «нормализовать для правильности, денормализовать для скорости - и только при необходимости»
Я отсылаю вас к: Что касается баз данных Является ли «Нормализовать для правильности, денормализовать для производительности» правильная мантра?
HTH.
Нормализация может снизить производительность. Однако это не повод для преждевременной денормализации.
Начните с полной нормализации, и тогда вы увидите, есть ли у вас проблемы с производительностью. При той скорости, которую вы описываете (1000 обновлений / вставок в день), я не думаю, что вы столкнетесь с проблемами, если только таблицы не будут огромными.
И даже если есть масса вариантов оптимизации базы данных (индексы, подготовленные хранимые процедуры, материализованные представления, ...), которые вы можете использовать.
Может, я что-то упустил. Но если ваша архитектура требует, чтобы вы объединяли от 30 до 40 таблиц в одном запросе, и этот запрос является основным использованием вашего сайта, тогда у вас возникают более серьезные проблемы.
Я согласен с другими, не оптимизируйте свой сайт преждевременно. Однако вам следует оптимизировать вашу архитектуру, чтобы учесть ваш основной вариант использования. соединение 40 таблиц для запроса, выполняемого более 50% времени, не оптимизировано IMO.
Когда производительность важна, обычно есть лучшие альтернативы, чем денормализация:
- Создание соответствующих индексов и статистики для задействованных таблиц
- Кэширование
- Материализованные представления (индексированные представления в MS SQL Server)
- Наличие денормализованной копии ваших таблиц (используется исключительно для запросов, которые в них нуждаются) в дополнение к нормализованным таблицам, которые используются в большинстве случаев (требуется написание кода синхронизации, который может запускаться либо как триггер, либо как запланированное задание в зависимости от необходимой точности данных)
Не выполняйте предварительную оптимизацию. Денормализация - не единственный способ ускорить работу сайта. Ваша стратегия кэширования также очень важна, и если этот запрос из 30-40 таблиц содержит довольно статические данные, кеширование результатов может оказаться лучшей оптимизацией.
Также примите во внимание количество операций записи по количеству считываний. Если вы выполняете примерно 10 операций чтения для каждой вставки или обновления, вы можете сказать, что данные довольно статичны, поэтому вы должны кэшировать их в течение некоторого периода времени.
Если вы в конечном итоге денормализуете свою схему, ваши записи также станут более дорогими и потенциально замедлят работу.
Действительно проанализируйте свою проблему, прежде чем делать слишком много оптимизаций, а также подождите, чтобы увидеть, где на самом деле ваши узкие места в системе, поскольку вы можете в конечном итоге удивиться тому, что вам следует оптимизировать в первую очередь.