Я много слышал о денормализации, которая была сделана для повышения производительности определенного приложения. Но я никогда не пытался сделать что-то связанное.
Итак, мне просто интересно, какие места в нормализованной БД ухудшают производительность или, другими словами, какие принципы денормализации?
Как я могу использовать эту технику, если мне нужно улучшить производительность?
Денормализация - это компромисс между временным пространством. Нормализованные данные занимают меньше места, но могут потребовать объединения для построения желаемого набора результатов, следовательно, больше времени. Если он денормализован, данные реплицируются в нескольких местах. Затем это занимает больше места, но желаемый вид данных легко доступен.
Существуют и другие оптимизации во временном пространстве, такие как
Как и при любом таком подходе, это улучшает данные чтения (поскольку они доступны), но обновление данных становится более дорогостоящим (поскольку вам необходимо обновить реплицированные или предварительно вычисленные данные).
Денормализация обычно используется для:
Основная идея денормализации заключается в том, что вы добавите избыточные данные или группу, чтобы иметь возможность получить эти данные более легко - с меньшими затратами; что лучше для выступлений.
Быстрые примеры?
Теперь есть некоторые затраты, да:
Слово "денормализация" приводит к путанице в вопросах дизайна. Попытка получить высокопроизводительную базу данных путем денормализации - это как попытка добраться до места назначения, уезжая из Нью-Йорка. Он не говорит вам, куда идти.
Вам нужна хорошая дисциплина дизайна, которая создает простой и надежный дизайн, даже если этот дизайн иногда противоречит нормам нормализации.
Одна такая проектная дисциплина - это звездная схема. В схеме звезд одна таблица фактов служит центром звездных таблиц. Другие таблицы называются таблицами измерений, и они находятся на краю схемы. Размеры связаны с таблицей фактов отношениями, которые выглядят как спицы колеса. Звездная схема - это в основном способ проецирования многомерного дизайна на реализацию SQL.
Близко связана с звездной схемой схема снежинок, которая немного сложнее.
Если у вас есть хорошая звездная схема, вы сможете получить огромное количество комбинаций ваших данных с не более чем трехсторонним объединением, включающим два измерения и одну таблицу фактов. Не только это, но и многие инструменты OLAP смогут автоматически расшифровать ваш звездный дизайн и дать вам доступ к вашим данным с точным щелчком, детализацией и графическим анализом без дальнейшего программирования.
Дизайн схемы звезд иногда нарушает вторую и третью нормальные формы, но это приводит к большей скорости и гибкости для отчетов и выписок. Он чаще всего используется в хранилищах данных, витринах данных и базах данных отчетов. Как правило, у вас есть гораздо лучшие результаты по схеме звезд или какой-либо другой ориентированной на поиск конструкции, чем от случайной "денормализации".
Критические проблемы денормализации:
Одним из самых простых типов денормализации является заполнение поля идентификатора таблицами, чтобы избежать объединения. Поскольку идентификационные данные не должны меняться, это означает, что проблема синхронизации данных в синхронизации редко возникает. Например, мы заполняем идентификатор клиента на несколько таблиц, потому что нам часто приходится запрашивать их у клиента и не обязательно нужно в запросах любые данные в таблицах, которые будут находиться между таблицей клиента и таблицей, которую мы запрашиваем если данные были полностью нормализованы. Вы все равно должны сделать одно соединение, чтобы получить имя клиента, но это лучше, чем присоединение к 6 родительским таблицам, чтобы получить имя клиента, когда это единственный фрагмент данных, который вам нужен, вне таблицы, которую вы запрашиваете.
Однако для этого не было бы никакой пользы, если бы мы не часто делали запросы, где нужны данные из промежуточных таблиц.
Другой распространенной денормализацией может быть добавление поля имени в другие таблицы. Поскольку имена по своей сути изменяемы, вам необходимо убедиться, что имена остаются в синхронизации с триггерами. Но если это избавит вас от присоединения к 5 таблицам вместо 2, это может стоить немного более длинной вставки или обновления.
Если у вас есть определенные требования, такие как отчетность и т.д., это может помочь денормализовать вашу базу данных различными способами:
ввести определенное дублирование данных, чтобы сэкономить несколько JOIN (например, заполнить определенную информацию в таблице и быть в порядке с дублированными данными, чтобы все данные в этой таблице и не нужно было найти, присоединившись к другой таблице )
вы можете предварительно вычислить определенные значения и сохранить их в столбце таблицы, insteda для их вычисления на лету, каждый раз, чтобы запрашивать базу данных. Разумеется, эти рассчитанные значения могут быть "устаревшими" с течением времени, и вам может потребоваться их перекомпиляция в какой-то момент, но просто чтение фиксированного значения обычно дешевле, чем вычисление чего-либо (например, подсчета дочерних строк).
Существует множество способов денормализации схемы базы данных для повышения производительности, но вам просто нужно знать, что вы попадаете в определенную проблему с этим. Вы должны тщательно взвесить плюсы и минусы - преимущества в производительности и проблемы, с которыми вы сталкиваетесь, - при принятии этих решений.
Рассмотрим базу данных с правильно нормированными отношениями родитель-потомок.
Пусть говорят, что мощность составляет среднее значение 2x1.
У вас есть две таблицы, родительские, с p строк. Ребенок с 2x р строк.
Средство операции соединения для родительских строк p, должно быть прочитано 2x p дочерних строк. Общее количество прочитанных строк равно p + 2x p.
Рассмотрим денормализацию этого в одну таблицу с только дочерними строками, 2x p. Количество прочитанных строк равно 2x p.
Меньше строк == меньше физических операций ввода-вывода == быстрее.
В соответствии с последним разделом этой статьи
https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx
можно использовать виртуальную денормализацию, в которой вы создаете "Представления" с некоторыми денормализованными данными, чтобы быстрее выполнять более простые SQL-запросы, в то время как базовые таблицы остаются нормализованными для более быстрых операций добавления/обновления (если вы можете уйти с обновлением представлений в регулярные интервалы, а не в реальном времени). Я просто занимаюсь классом в Relational Databases, но, из того, что я читал, этот подход кажется мне логичным.
Преимущества де-нормализации над нормализацией
В основном де-нормализация используется для СУБД, а не для РСУБД. Поскольку мы знаем, что РСУБД работает с нормализацией, а это означает, что повторные данные снова и снова не повторяются. Однако при использовании внешнего ключа все же повторяйте некоторые данные.
Когда вы используете СУБД, тогда необходимо удалить нормализацию. Для этого необходимо повторение. Но тем не менее, это повышает производительность, потому что между таблицами нет никакой связи, и каждая таблица имеет неделимое существование.