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

Ответ 1

Мифология

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему Myth Prevalent?

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

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

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

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

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

  Вот почему я всегда включаю "расширенный" SQL и наставничество в любом проекте.

Мой ответ

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

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

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

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

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

Подробнее Нормализация

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

Аналогично, 5NF велик, но имеет свои ограничения. Например. Поворот больших таблиц (не небольших результирующих наборов в соответствии с расширением MS PIVOT) был медленным. Поэтому я (и другие) разработал способ обеспечения нормализованных таблиц таким образом, чтобы поворот был (а) легким и (б) очень быстрым. Оказывается, теперь, когда определено 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 модели (Star Schema, Dimension-Fact) ориентированы на столбцы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Что выглядит 6NF?

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

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

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

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

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

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

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

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

Опыт работы с данными (только)

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

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

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

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

Допустимое обоснование хранилища данных

Вот почему я заявил в других сообщениях, единственное допустимое обоснование для отдельной платформы хранилища данных, аппаратного обеспечения, ETL, обслуживания и т.д. - это то, где имеется множество баз данных или "баз данных" , все из которых объединены в центральный склад, для отчетов и OLAP.

Кимбалл

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

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

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

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

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

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

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

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

Ваша миссия

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

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

Вопросы?

Ответ 2

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

Aggregation: Рассмотрим таблицу с 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) путается и закручивает планы выполнения. Субоптимальные планы выполнения могут быть не такими большими, если запрос имеет дело с небольшими объемами данных. Но как только мы начнем присоединяться к "Большим таблицам", важно , чтобы база данных правильно выполнила план выполнения. Если денормализовать данные в одной таблице с помощью одного синтаксического ключа (черт, почему бы мне не добавить больше топлива для этого продолжающегося огня), фильтры станут простыми фильтрами диапазона/равномерности на предварительно подготовленных столбцах. Дублирование данных в новые столбцы позволяет нам собирать статистические данные о столбцах, которые помогут оптимизатору оценить селективность и, таким образом, предоставить нам правильный план выполнения (ну,...).

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

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

Обновление 1

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

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

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

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

Анализ

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

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

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

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

account_balances(month, report)

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

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

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

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

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

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

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

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

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

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

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

Нижняя строка

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

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

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

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

Ответ 6

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

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

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

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

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

EDIT - пример

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

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

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

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

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

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

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

В качестве точки интереса Билл Инмон имеет хорошо написанную статью на своем веб-сайте - Сказка о двух архитектурах.

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

Облегчение:

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

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