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

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

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

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

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

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

Есть некоторые затраты, да:

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

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

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

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

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

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

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

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

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

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

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

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

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

Допустим, мощность составляет в среднем 2x1.

У вас есть две таблицы, Parent, с p строками. Детский с 2x p рядами.

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

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

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

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

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

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

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