Денормализация базы данных

Не так давно писал цикл постов про нормальные формы. Сегодня хочу еще рассказать про обратную процедуру — денормализацию.

Что такое денормализация? Это намеренное внесение изменений в нормализованную схему бд, после которых она перестает соответствовать правилам НФ.

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

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

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

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

1.67 avg. rating (38% score) - 9 votes

7 комментариев

  • Денормализацию базы проводят обычно для повышения производительности, реже — для облегчения жизни программистам, разрабатывающим приложения, работающие с этой базой данных. Хотя часто эти цели достигаются одновременно:).

  • Иногда для того, чтобы оставить удобную логичную и нормализованную структуру основной БД, но добиться большего быстродействия, применяют еще один слой — фронтенд БД. Эта БД денормализована и работает только на чтение, в то время как основная работает на запись. Раз в день, час или чаще происходит репликация данных из основной БД в фронтенд БД.

  • Интересно, сколько людей в нашем правительстве дадут правильно определение денормализации, и при этом не спутают её с деноминацией?? =))))

  • Являюсь разработчиком обной cms. Там есть большой и мощьный каталог товаров. В состав каталого входит 10 таблиц. Ну не сделать там иначе никак. Параметры, группы параметров, марки, фотки и т.д. Ну так вот на когда в каталог загрузили 10 т. товаров он стал открываться по 5 сек. Профайлинг показал, что куча времени уходит на джоин таблиц. Было принято решение написать кеш таблицу. Теперь всегда есть дублирующая таблица, синхронизирующаяся с остальными. Каталог стал открываться менее чем за 1 сек.

  • Фристайл, мы писали подобный каталог товаров. Для каждого типа товаров была отдельная таблица свойств + общая таблица с товарами + общая таблица категорий.
    При 1000000+ товаров и 1000+ категорий запросы к базе выполнялись за сотые доли секунды, т.е. порядка 0,01-0,05 сек.

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

  • Денормализация БД — самый эффективный способ увеличить скорость формирования сложных отчетов в загруженой продуктивной среде

  • В запросах к полностью нормализованной базе нередко приходится соединять до десятка, а то и больше, таблиц. А каждое соединение — операция весьма ресурсоемкая. Как следствие, такие запросы кушают ресурсы сервера и выполняются медленно.
    В такой ситуации может помочь:
    1)денормализация путем сокращения количества таблиц. Лучше объединять в одну несколько таблиц, имеющих небольшой размер, содержащих редко изменяемую (как часто говорят, условно-постоянную, или нормативно-справочную) информацию, причем информацию, по смыслу тесно связанную между собой.
    В общем случае, если в большом количестве запросов требуется объединять более пяти или шести таблиц, следует рассмотреть вариант денормализации базы данных.
    2)денормализация путём ввода дополнительного поля в одну из таблиц. При этом появляется избыточность данных, требуются дополнительные действия для сохранения целостности БД.

css.php