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

денормализация и агрегация-это две основные стратегии, используемые для достижения производительности в хранилище данных. Просто глупо предполагать, что это не улучшает производительность чтения! Должно быть, я что-то не понял?

агрегация: Рассмотрим таблицу, содержащую 1 миллиард покупок. Сравните его с таблицей, содержащей одну строку с суммой покупок. Теперь, что быстрее? Выберите сумма (сумма) из таблицы миллиард строк или выберите сумму из столик в один ряд? Конечно, это глупый пример, но он достаточно ясно иллюстрирует принцип агрегации. Почему быстрее? Потому что независимо от того, какую магическую модель/оборудование/программное обеспечение/религию мы используем, чтение 100 байт быстрее, чем чтение 100 гигабайт. Просто.

денормализации: Типичное измерение продукта в розничном хранилище данных содержит множество столбцов. Некоторые столбцы-это простой материал, такой как" имя "или" цвет", но он также имеет некоторые сложные что-то вроде иерархии. Несколько иерархий (ассортимент продукции (5 уровней), предполагаемый покупатель (3 уровня), сырье (8 уровней), способ производства (8 уровней) вместе с несколькими вычисленными числами, такими как среднее время выполнения (с начала года), вес/упаковка меры и т.д. Я поддерживал таблицу измерения продукта с 200 + столбцами, которая была построена из ~70 таблиц из 5 различных исходных систем. Просто глупо спорить о том, является ли запрос нормализованным модель (ниже)

select product_id
  from table1
  join table2 on(keys)
  join (select average(..)
          from one_billion_row_table 
         where lastyear = ...) on(keys)
  join ...table70
 where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7
   and exists(select ... from )
   and not exists(select ...)
   and table20.version_id = (select max(v_id from product_ver where ...)
   and average_price between 10 and 20
   and product_range = 'High-Profile'

...быстрее, чем эквивалентный запрос на денормализованной модели:

select product_id
  from product_denormalized
 where average_price between 10 and 20
   and product_range = 'High-Profile';

почему? Частично по той же причине, что и агрегированный сценарий. Но также и потому, что запросы просто "сложные". Они настолько отвратительно сложны, что оптимизатор (и теперь я собираюсь Oracle specifics) путается и путает планы выполнения. Субоптимальные планы выполнения могут не иметь такого большого значения, если запрос имеет дело с небольшими объемами данных. Но как как только мы начинаем присоединяться к большим таблицам, это важно что база данных получает план выполнения права. Денормализовав данные в одной таблице одним синтезаторным ключом (черт, почему бы мне не добавить больше топлива к этому продолжающемуся огню), фильтры становятся простыми фильтрами диапазона/равенства на предварительно приготовленных столбцах. Дублирование данных в новые столбцы позволяет нам собирать статистику по столбцам, которая поможет оптимизатору в оценке избирательности и тем самым предоставит нам с правильным планом исполнения (ну,...).

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

Итак, следует ли денормализовать базу данных для достижения производительности чтения? Ада нет! Это добавляет так много сложностей в вашу систему, что нет конца тому, сколько способов она будет завинчивать вас, прежде чем вы доставите. Стоит ли это? Да, иногда вам нужно сделать это, чтобы удовлетворить определенные требования к производительности.

обновление 1

PerformanceDBA: 1 строка будет обновляться миллиард раз в день

это означало бы (близкое) требование в реальном времени (что, в свою очередь, привело бы к совершенно другому набору технических требований). Многие (если не большинство) хранилища данных не имеют этого требования. Я выбрал нереалистичный пример агрегации, чтобы понять, почему агрегация работает. Я не хотел объяснять стратегии свертки тоже:)

кроме того, необходимо сопоставить потребности типичного пользователя хранилища данных и типичного пользователя системы OLTP подложки. Пользователь, который хочет понять, какие факторы управляют транспортными расходами, не мог бы заботиться меньше, если 50% сегодняшних данных отсутствует или если 10 грузовиков взорвались и убили водителей. Выполнение анализа в течение 2 лет стоит данных все равно придете к тому же выводу, даже если он самая актуальная информация в его распоряжении.

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

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

под "OLAP" я понимаю, что вы имеете в виду предметно-ориентированную реляционную / SQL - базу данных, используемую для поддержки принятия решений-он же хранилище данных.

нормальная форма (обычно 5-я / 6-я нормальная форма), как правило, является лучшей моделью для хранилища данных. Причины нормализации хранилища данных точно такие же, как и в любой другой базе данных: это уменьшает избыточность и позволяет избежать потенциальных аномалий обновления; это позволяет избежать встроенного смещения и поэтому является самым простым способом поддержки изменения схемы и новых требования. Использование обычной формы в хранилище данных также помогает упростить и согласовать процесс загрузки данных.

нет "традиционного" подхода денормализации. Хорошие хранилища данных всегда были нормализованы.

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

хорошо, здесь идет общий "ваш пробег может варьироваться", "это зависит", "использовать правильный инструмент для каждой работы"," один размер не подходит всем " ответ, с немного "не исправить, если он не сломан" бросил в:

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

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

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

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

сначала мои мнения, затем некоторый анализ

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

это, строго говоря, является false см. Этот вопрос/ответ, Denormalisation в строгом смысле смысла нарушать обычные формы из 1nf-6NF, другие зависимости вставки, обновления и удаления адресуются с принцип ортогональной конструкции.

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

нарушение нормальных форм мая действительно ускорить некоторые извлечение данных (подробности в анализе ниже), но, как правило, это будет также в то же время:

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

анализ

Итак, я сделал заявление, что иногда нарушение нормальных форм может помочь в поиске. Время привести некоторые аргументы

1) Нарушение 1NF

Предположим, у вас есть финансовые отчеты в 6NF. Из такой базы данных вы наверняка сможете получить отчет о том, что такое баланс по каждому счету за каждый месяц.

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

account_balances(month, report)

который будет содержать структурированные остатки XML для каждого счета. Это нарушает 1NF (см. Примечания позже), но позволяет выполнить один конкретный запрос с помощью минимальный ввод-вывод.

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

Примечание: Это на самом деле тривиальный пример, и есть одна проблема с ним - определение 1NF. Предположение, что приведенная выше модель нарушает 1NF, соответствует требованию, что значения атрибута'содержать ровно одно значение из соответствующего домена'.

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

С другой стороны, есть гораздо лучшие способы моделирования этой таблицы, которые были бы более полезны для более широкого круга запросов (например, для получения остатков по одному счету за все месяцы в году). В этом случае вы оправдаете это улучшение, сказав, что это поле не находится в 1NF.

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

2) Нарушение 3NF

предполагая таблицы в 3NF

CREATE TABLE `t` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `member_id` int(10) unsigned NOT NULL,
  `status` tinyint(3) unsigned NOT NULL,
  `amount` decimal(10,2) NOT NULL,
  `opening` decimal(10,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `member_id` (`member_id`),
  CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB

CREATE TABLE `m` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

С данными по образца (строки 1М в Т, 100к в М)

предположим, общий запрос, который вы хотите улучшить

mysql> select sql_no_cache m.name, count(*) 
       from t join m on t.member_id = m.id 
       where t.id between 100000 and 500000 group by m.name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (1.08 sec)

вы можете найти предложения по перемещению атрибута name в таблицу m, которая разбивает 3NF (она имеет FD: member_id -> name и member_id не является ключом t)

после

alter table t add column varchar(255);
update t inner join m on t.member_id = t.id set t.name = m.name;

под управлением

mysql> select sql_no_cache name, count(*) 
       from t where id 
       between 100000 and 500000 
       group by name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (0.41 sec)

заметки: Вышеуказанное время выполнения запроса -разрезать пополам, а

• таблица не была в 5NF/6NF, чтобы начать с
• тест был выполнен с no_sql_cache, поэтому большинство механизмов кэша были исключены (и в реальных ситуациях они играют роль в производительности системы)
• потребление космоса увеличено размером приблизительно 9x имени столбца x 100k строки
• на t должны быть триггеры для сохранения целостности данных, что значительно замедлит все обновления до name и добавит дополнительные проверки, которые вставляют в t, нужно будет пройти
• вероятно, лучшие результаты могут быть достигнуты путем удаления суррогатных ключей и переключения на естественные ключи и / или индексирования или перепроектирования на более высокий NFs

нормализовать правильный путь в долгосрочной перспективе. Но у вас не всегда есть возможность перепроектировать ERP компании (который, например, уже только в основном 3NF) - иногда вы должны достичь определенной задачи в рамках заданных ресурсов. Конечно, это только краткосрочное "решение".

итог

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

• строго говоря, для нарушение NFs
• свободно, введение любых зависимостей вставки, обновления и удаления (оригинал Кодда цитата комментарии о нормализации поговорка: 'нежелательными(!) зависимости вставки, обновления и удаления", см. Некоторые подробности здесь)

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

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

еще одна вещь, которая может пролить свет на то, что есть очень важная разница между логическая модель и физическая модель.

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

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

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

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

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

двумя наиболее популярными методологиями построения хранилища данных (DW), по-видимому, являются Билл Инмон и Ральф Кимбалл.

методология Инмона использует нормализованный подход, в то время как Кимбалл использует размерное моделирование-де-нормализованную схему звезды.

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

Я не могу комментировать подход 6NF ни на Якорное моделирование, потому что я никогда не видел и не участвовал в проекте DW с использованием этой методологии. Когда дело доходит до реализаций, мне нравится путешествовать по хорошо проверенным путям, но это только я.

Итак, подводя итог, должен ли DW быть нормализован или де-нормализован? Зависит от выбранной вами методологии-просто выберите одну и придерживайтесь ее, по крайней мере, до конца проекта.

EDIT-пример

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

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

дело в том, что беспорядок скрипта python и SQL занимал восемь часов (да, e-i-g-h-t часов), чтобы работать каждый день. Излишне говорить, что база данных и приложение были построены в течение многих лет несколькими партиями разработчиков-так, не совсем ваш 5NF.

пришло время воссоздать унаследованную вещь из DW. Хорошо, чтобы это было коротким, это сделано, и требуется 3 минуты (t-h-r-e-e минут), чтобы произвести его, шесть секунд на суб-отчет. И я спешил доставить, поэтому даже не оптимизировал все запросы. Это фактор 8 * 60 / 3 = В 160 раз быстрее , не говоря уже о преимуществах удаления восьмичасового задания с рабочего сервера. Думаю, я еще могу побриться минутку-другую, но сейчас это никого не волнует.

в качестве точки интереса я использовал метод Кимбалла (размерное моделирование) для DW, и все, что используется в этой истории, является открытым исходным кодом.

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

EDIT 2

в качестве точки интереса, Билл Инмон имеет красиво написанный документ на своем веб-сайте -- Повесть о двух архитектурах.

проблема со словом "денормализованный" заключается в том, что оно не указывает, в каком направлении идти. Это все равно что пытаться добраться из Чикаго в Сан-Франциско на машине из Нью-Йорка.

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

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

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

Что касается таблиц на основе времени, общепринятый pardigm должен иметь valid_from и valid_to даты в каждой строке. Это все еще в основном 3NF, поскольку он только изменяет семантику с "это единственная и единственная версия этой сущности "на" это единственная версия этой сущности в это время "

упрощение:

база данных OLTP должна быть нормализована (насколько это имеет смысл).

хранилище данных OLAP должно быть денормализовано в таблицы фактов и измерений (для минимизации соединений).