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

Question

Я всегда думал, что базы данных должны быть денормализованы для производительности чтения, как это делается для проектирования баз данных OLAP, и не сильно преувеличивать 3NF для разработки OLTP.

PerformanceDBA в различных сообщениях, например, в Производительность различных подходов к данным, основанным на времени защищает парадигму, что база данных всегда должна быть хорошо спроектирована путем нормализации до 5NF и 6NF (NormalФорма).

Правильно ли я понял (и что я правильно понял)?

Что не так с традиционным подходом денормализации / парадигмы проектирования баз данных OLAP (ниже 3NF) и рекомендацией о том, что 3NF достаточно для большинства практических случаев использования баз данных OLTP?

Например:

• «Простая истина ... в том, что правильно выполненный 6NF является хранилищем данных» (PerformanceDBA)

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

На какие источники я могу ссылаться, пытаясь убедить моих заинтересованных сторон, что базы данных OLAP / хранилища данных должны быть нормализованы?

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

"Было бы неплохо, если бы участники добавили (раскрыли), сколько реальных (без научных проектов) хранилищ данныхреализации в 6NF, в которых они видели или участвовали. Вид быстрого пула. Me = 0. "- Дамир Сударевич

В статье Хранилища данных Википедии рассказывается:

"Нормализованный подход [против размерного подхода Ральфа Кимбалла], также называемый 3NF модель (третья нормальная форма), чьи сторонники называются «инмонитами», верят в подход Билла Инмона, в котором утверждается, что хранилище данных должно моделироваться с использованием модели ER / нормализованной модели. "

Похоже, что нормализованный подход к хранилищу данных (Билл Инмон) воспринимается как не превышающий 3NF (?)

Я просто хочу понять, каково происхождение мифа (илиповсеместное аксиоматическое убеждение), что хранилище данных / OLAP является синонимом денормализации?

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

Answer 1

Мифология

Я всегда думал, что базы данных должны быть денормализованы для чтения, как это делается для проектирования баз данных OLAP, и не сильно преувеличивал 3NF для разработки OLTP.

Есть миф на этот счет. В контексте реляционной базы данных я повторно реализовал шесть очень больших так называемых «ненормализованных» «баз данных»; и выполнил более восьмидесяти заданий, исправляя проблемы других, просто нормализуя их, применяя стандарты и инженерные принципы. Я никогда не видел никаких доказательств мифа. Только люди повторяют мантру, как будто это какая-то магическая молитва.

Нормализация против ненормализованных

(«Денормализация» - это мошеннический термин, которым я отказываюсь его использовать.)

Это научная индустрия (по крайней мере, та, которая поставляет программное обеспечение, которое не ломается; оно отправляет людей на Луну; оно управляет банковскими системами и т. Д.). Это регулируется законами физики, а не магии. Компьютеры и программное обеспечение - это конечные, материальные, физические объекты, подчиняющиеся законам физики. По среднему и высшему образованию я получил:

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

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

• для любого заданного набора ресурсов, Нормализованные таблицы:

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

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

По моему опыту, который доставляет и OLTP, и OLAP из одной и той же базы данных, никогда не было необходимости "нормализовать" мои нормализованные структуры, чтобы получить более высокую скорость запросов только для чтения (OLAP). Это тоже миф.

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

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

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

Почему миф превалирует?

Ну, во-первых, это не распространено среди научных типов, которые не ищут пути преодоления законов физики.

Исходя из своего опыта, я определил три основные причины распространенности:

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

2. Многие кодеры SQL могут писать только простой одноуровневый SQL. Нормализованные структуры требуют немного возможностей SQL. Если у них нет этого; если они не могут производить SELECT без использования временных таблиц; если они не могут писать подзапросы, они будут психологически приклеены к бедру к плоским файлам (что и есть «ненормализованные» структуры), которые они могут обработать.

3. Люди любят читать книги и обсуждать теории. Без опыта. Особенно повторная магия. Это тоник, заменитель реального опыта. Любой, кто действительно нормализовал базу данных правильно, никогда не заявлял, что «нормализация происходит быстрее, чем нормализация». Любому, кто произносит мантру, я просто говорю «покажи мне доказательства», а они никогда не давали никаких доказательств. Таким образом, в действительности люди повторяют мифологию по этим причинам без какого-либо опыта нормализации . Мы стадные животные, а неизвестность - один из наших самых больших страхов.

   Именно поэтому я всегда включаю «продвинутый» SQL и наставничество в любой проект.

Мой ответ

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

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

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

Итак, мы рассмотрели законы физики и применили немного науки.
Мы внедрили стандартную концепцию, согласно которой данные принадлежат корпорации (а не отделам), и корпорация хотела иметь одну версию правды.База данных была чисто реляционной, нормализованной до 5NF.Чистая открытая архитектура, так что любое приложение или инструмент отчета может получить к ней доступ.Все транзакции в хранимых процессах (в отличие от неконтролируемых строк SQL по всей сети).Те же разработчики для каждого приложения кодировали новые приложения после нашего «продвинутого» образования.

Очевидно, наука работала.Ну, это была не моя личная наука или магия, это была обычная инженерия и законы физики.Все это работало на одной платформе сервера баз данных;две пары (производство и DR) серверов были выведены из эксплуатации и переданы другому отделу.5 «баз данных» общим объемом 720 ГБ были нормализованы в одну базу данных общим объемом 450 ГБ.Около 700 таблиц (много дубликатов и дублированных столбцов) были нормализованы в 500 не дублированных таблиц.Он работал намного быстрее, в общем, в 10 раз быстрее, а в некоторых функциях более чем в 100 раз.Это не удивило меня, потому что это было моим намерением, и наука предсказала это, но это удивило людей мантрой.

Больше нормализации

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

Аналогично, 5NF великолепен, но у него есть свои ограничения.Например.Поворот больших таблиц (не маленьких наборов результатов согласно расширению MS PIVOT) был медленным.Поэтому я (и другие) разработал способ предоставления нормализованных таблиц, чтобы Pivoting был (а) легким и (б) очень быстрым.Оказывается, теперь, когда определено 6NF, эти таблицы являются 6NF.

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

• тем быстрее они работают

• и их можно использовать несколькими способами (например, Pivots)

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

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

Прогрессна эту тему.Я всегда был специалистом по базам данных, а не специалистом по хранилищу данных, поэтому мои первые несколько проектов со складами были не полноценными реализациями, а скорее существенными заданиями по настройке производительности.Они были в моей сфере, на продуктах, на которых я специализировался.
Давайте не будем беспокоиться о точном уровне нормализации и т. Д., Потому что мы смотрим на типичный случай.Мы можем считать, что база данных OLTP была достаточно нормализована, но не поддерживала OLAP, и организация приобрела совершенно отдельную платформу OLAP, аппаратное обеспечение;инвестировал в разработку и поддержку массы кода ETL;и т.д. И после внедрения потратил половину своей жизни на управление созданными ими дубликатами.Здесь нужно обвинять авторов книг и поставщиков за огромную трату аппаратного обеспечения и отдельных лицензий на программное обеспечение платформы, которые они заставляют организации покупать.

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

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

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

Но с таблицами 6NF:

• нет строк, только столбцы; мы обслуживаем строки и столбцы с одинаковой скоростью ослепления

• таблицы (т. Е. Представление 5NF структур 6NF) уже организованы в Факты измерений. Фактически они организованы в большее количество измерений, чем когда-либо идентифицировала бы любая модель OLAP, потому что они все измерения.

• Поворот целых таблиц с агрегацией на лету (в отличие от PIVOT небольшого числа производных столбцов) - это (а) простой код и (б) очень быстрый

По определению мы поставляем в течение многих лет реляционные базы данных с минимальной 5NF для использования OLTP и 6NF для требований OLAP.

• Обратите внимание, что это та же самая наука, которую мы использовали с самого начала; перейти от Типичные ненормализованные «базы данных» к 5NF Корпоративная база данных . Мы просто применяем больше проверенной науки и получаем более высокие порядки функциональности и производительности.

• Обратите внимание на сходство между 5NF Корпоративная база данных и 6NF Корпоративная база данных

• Вся стоимость отдельного аппаратного обеспечения OLAP, программного обеспечения платформы, ETL, администрирования, обслуживания исключена.

• Существует только одна версия данных, без аномалий обновления или их обслуживания; одни и те же данные обслуживаются для OLTP в виде строк и для OLAP в виде столбцов

Единственное, что мы не сделали, - это начали новый проект и объявили чистый 6NF с самого начала. Это то, что я выстроил рядом.

Что такое шестая нормальная форма?

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

• Пятая нормальная форма : все функциональные зависимости разрешены в базе данных
  • в дополнение к 4NF / BCNF
  • каждый столбец без PK равен 1 :: 1 со своим PK
  • и никакому другому ПК
  • Нет обновлений Аномалии
    ,
• Шестая нормальная форма : это неприводимая NF, точка, в которой данные не могут быть дополнительно уменьшены или нормализованы (не будет 7NF)
  • в дополнение к 5NF
  • строка состоит из первичного ключа и не более одного неключевого столбца
  • устраняет нулевую проблему

Как выглядит 6NF?

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

Он предназначен для сбора данных мониторинга сервера (сервер базы данных корпоративного класса и ОС) для любого из клиентов за любой период.Мы используем это для удаленного анализа проблем с производительностью и проверки любых настроек производительности, которые мы делаем.Структура не изменилась за более чем десять лет (добавлено, без изменений к существующим структурам), это типично для специализированного 5NF, который много лет спустя был идентифицирован как 6NF.Позволяет полный поворот;любой график или график, который будет нарисован в любом измерении (предусмотрено 22 опорных точки, но это не предел);ломтик и кости;смешивать и сочетать.Обратите внимание, что они все Размеры.

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

▶ Модель статистических данных монитора ◀ .(слишком большой для встроенного; некоторые браузеры не могут загружать встроенный; нажмите на ссылку)

Это позволяет мне создавать эти ▶ диаграммы, подобные этим ◀ , шесть нажатий клавиш после получениянеобработанный файл статистики мониторинга от клиента.Обратите внимание на сочетание и совпадение;ОС и сервер на одном графике;множество пивотов.(Используется с разрешения.)

Читатели, незнакомые со Стандартом моделирования реляционных баз данных, могут найти ▶ IDEF1X нотации ◀ полезными.

6NF Хранилище данных

Это было недавно подтверждено Anchor Modeling , так как теперь они представляют 6NF в качестве модели OLAP «следующего поколения» для хранилищ данных.(Они не предоставляют OLTP и OLAP из единой версии данных, то есть только для нас).

Хранилище данных (только) Опыт

Мой опыт работы сТолько хранилища данных (не упомянутые выше базы данных 6NF OLTP-OLAP) - это несколько важных заданий, в отличие от проектов полной реализации.Результаты не были удивительными:

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

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

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

Обоснованное обоснование хранилища данных

Именно поэтому я указал в других постах единственное действительное обоснование для отдельной платформы хранилища данных, аппаратного обеспечения, ETL, обслуживания и т. Д., Когда существует множество баз данных или «баз данных», все из которых объединяются в центральное хранилище для отчетов и OLAP.

Кимбалл

Необходимо немного рассказать о Кимбалле, поскольку он является основным сторонником "ненормализованной производительности" в хранилищах данных.Согласно моим определениям выше, он один из тех людей, у которых очевидно никогда не нормализовалось в их жизни;его отправная точка была ненормализована (закамуфлирована как «ненормализованная»), и он просто реализовал это в модели измерения факта.

• Конечно, чтобы получить какую-либо производительность, ему пришлось еще больше «нормализовать», создать дополнительные дубликаты и все это оправдать.

  • Таким образом, с шизофренической точки зрения верно то, что «ненормализованные» ненормализованные структуры путем создания более специализированных копий «улучшают производительность чтения». Это не правда, когда целое принимает во внимание; это верно только внутри этого маленького убежища, а не снаружи.

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

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

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

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

Все просто истории, части одной мифологии, которые тусуются вместе и поддерживают друг друга.

Ваша миссия

Если вы решите принять это. Я прошу вас думать самим и перестать развлекать любые мысли, которые противоречат науке и законам физики. Неважно, насколько они распространены, мистические или мифологические. Ищите доказательства чего-либо, прежде чем доверять этому. Будьте научны, проверяйте новые убеждения для себя. Повторение мантры «Денормализовано для производительности» не сделает вашу базу данных быстрее, это только заставит вас чувствовать себя лучше. Как толстый ребенок, сидящий в стороне, говорящий себе, что он может бежать быстрее, чем все дети в гонке.

* * 1397 на этом основании, даже концепция "нормализовать для OLTP", но сделать наоборот, "нормализовать для OLAP" является противоречием. Как могут законы физики работать так, как указано на одном компьютере, а на другом - наоборот? Разум поражает. Это просто невозможно, работать одинаково на каждом компьютере.

Вопросы?

Answer 2

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

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

Денормализация: Типичное измерение продукта в розничном хранилище данных содержит множество столбцов.Некоторые столбцы - простые вещи, такие как «Имя» или «Цвет», но у них также есть некоторые сложные вещи, такие как иерархии.Несколько иерархий (ассортимент продукции (5 уровней), предполагаемый покупатель (3 уровня), сырье (8 уровней), способ производства (8 уровней), а также несколько вычисленных чисел, таких как среднее время выполнения заказа (с начала года)), вес / упаковка меры etcetera etcetera. Я сохранил таблицу измерений продукта с 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) запутывается и портит планы выполнения. Неоптимальные планы выполнения могут быть не такими уж серьезными, если запрос имеет дело с небольшими объемамиданные. Но как только мы начинаем объединяться в большие таблицы, это крайне важно , чтобы база данных правильно понимала план выполнения.После денормализации данных в одной таблице с помощью одного синтаксического ключа (черт, почему я не добавляю больше топлива для этого продолжающегося пожара), фильтры становятся простыми фильтрами диапазона / равенства на предварительно приготовленных столбцах.Дублирование данных в новые столбцы позволяет нам собирать статистику по столбцам, что поможет оптимизатору оценить селективность и, таким образом, предоставить нам надлежащий план выполнения (ну, ...).

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

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

Обновление 1

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Хорошо, здесь идет итог «Ваш пробег может меняться», «Это зависит», «Используйте подходящий инструмент для каждого».Ответ "Задание", "Один размер не подходит всем", с добавлением слова "Не исправлять, если оно не сломано":

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

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

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

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

Answer 5

Сначала моё мнение, потом немного анализа

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

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

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

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

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

Анализ

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

1) Взлом 1NF

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

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

account_balances(month, report)

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

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

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

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

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

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

2) Breaking 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

с образцами данных (1M строк в t, 100k в m)

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

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, поэтому большинство механизмов кэширования были исключены (и в реальных ситуациях они играют роль в производительности системы)
• увеличивается потребление пространстваПримерно в 9 раз размер имени столбца х 100 000 строк
• re должен быть триггером на t, чтобы сохранить целостность данных, что значительно замедлит все обновления имени и добавит дополнительные проверки, которые вставкам в t придется проходить через
• . Вероятно, лучшие результаты могут быть достигнуты при удалении суррогатаключи и переключение на естественные ключи и / или индексацию, или перепроектирование на более высокие NF

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

Итог

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

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

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

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

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

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

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

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

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

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

Answer 6

Проблема со словом «денормализованный» заключается в том, что оно не указывает, в каком направлении идти. Это все равно, что пытаться добраться до Сан-Франциско из Чикаго, отъезжая от Нью-Йорка.схема или схема снежинки конечно не нормализуются.И это, безусловно, работает лучше, чем нормализованная схема в определенных шаблонах использования.Но есть случаи денормализации, когда дизайнер вообще не следовал какой-либо дисциплине, а просто составлял таблицы интуитивно.Иногда эти усилия не увенчались успехом.

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

Answer 7

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

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

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

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

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

РЕДАКТИРОВАТЬ - Пример

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

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

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

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

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

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

РЕДАКТИРОВАТЬ 2

Для интереса у Билла Инмона есть хорошо написанная статья на его веб-сайте: Повесть о двух архитектурах .

Answer 8

Упрощение:

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

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

Answer 9

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

Что касается временных таблиц, то общепринятая парадигма состоит в том, чтобы в каждой строке были даты valid_from и valid_to. Это по-прежнему в основном 3NF, так как он только меняет семантику с «это единственная версия этой сущности» на «это единственная версия этой сущности на данный момент »