Каким образом денормализация повышает производительность базы данных?

денормализация обычно используется для:

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

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

Быстрый пример?

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

сейчас есть некоторые расходы, да:

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

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

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

одной из таких дисциплин проектирования является star schema. В звезде схема, одна таблица фактов служит центром звезды таблиц. Другие таблицы называются таблицами измерений и находятся на краю схемы. Размеры связаны с таблицей фактов отношениями, которые выглядят как спицы колеса. Схема Star-это в основном способ проецирования многомерного дизайна на реализацию SQL.

тесно связана со звездной схемой Схема снежинки, которая немного сложнее.

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

Star schema design иногда нарушает вторую и третью нормальные формы, но это приводит к большей скорости и гибкость для отчетов и выдержек. Он чаще всего используется в хранилищах данных, витринах данных и базах данных отчетов. Как правило, вы получите гораздо лучшие результаты от star schema или другого ориентированного на извлечение дизайна, чем от просто случайной "денормализации".

критические вопросы денормализации:

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

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

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

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

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

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

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

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

рассмотрим базу данных с правильно нормализованными отношениями родитель-потомок.

предположим, что мощность в среднем равна 2x1.

У вас есть две таблицы, Parent, с p строк. Ребенок с 2х p строк.

операция соединения средством p родительские строки, 2x p дочерние строки должны быть прочитаны. Общее количество прочитанных строк -p + 2x p.

рассмотреть денормализация этого в одну таблицу только с дочерними строками, 2x p. Количество прочитанных строк равно 2x p.

меньше строк == меньше физического ввода-вывода == быстрее.

согласно последнему разделу этой статьи,

https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx

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

преимущества де-нормализации над нормализацией

в основном де-нормализация используется для СУБД, а не для СУБД. Как мы знаем, РСУБД работает с нормализацией, что означает отсутствие повторных данных снова и снова. Но все же повторите некоторые данные при использовании внешнего ключа.

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