Что обеспечивает отсутствие избыточности данных в бд увеличение расхода памяти для хранения бд
Обновлено: 06.07.2024
При проектирование базы данных следует учесть то, что какая-то информация может повторяться несколько раз. А каждая повторяющаяся запись – это занятое место на диске, то есть превышение количества информации, необходимого для хранения данных.
Конечно, можно сказать, что сейчас, с появлением терабайтных накопителей, отпала необходимость экономить место на диске. Но информационная избыточность ведет не только к увеличению требуемого объема памяти для хранения информации содержащейся в базе данных.
Избыточность данных в базе данных – это нежелательное явление еще и потому, что при работе с таблицами базы данных, содержащими избыточные данные, возникают проблемы связанные с обработкой информации, - аномалии.
Аномалии в базе данных – это проблемы связанные с обработкой информации, а точнее с удаление данных из базы данных, с модификацией данных в таблице базы данных и аномалия добавления данных в базу данных:
Аномалия включения – это проблема, связанная с добавлением данных в базу данных
Аномалия модификации – это проблема, связанная с изменением данных в базе данных
Аномалия удаления – это проблема, связанная с удаление данных в базе данных
Все эти проблемы связаны с целостностью баз данных, а именно с избыточностью данных в базе данных.
Таким образом, данные не должны быть избыточными. Например, нет необходимости хранить домашний адрес сотрудника компании более, чем в одной таблице, поскольку при этом непроизводительно расходуется дисковое пространство. Кроме того, может возникнуть невообразимая путаница, когда, например, адрес сотрудника в одной таблице не соответствует его же адресу в другой. Какая информация достоверна? Есть ли у вас соответствующие документы для проверки действительного адреса этого сотрудника? Как ни сложно управление информацией само по себе, избыточность данных в этом случае может оказаться настоящим бедствием.
Рассмотрим пример таблицы, которую проектировали не профессиональные разработчики, а обычные пользователи:
Конечно же, такая структура таблицы является неоптимальной по нескольким причинам:
1) данные в таблице являются избыточными. Например, адрес одной и той же фирмы повторяется несколько раз. Если таблица будет большой, то из-за избыточных данных нам потребуется много места на хранение, а производительность работы с таблицей упадет;
2) очень легко ошибиться, указав разный адрес (или адрес по-разному для одной и той же фирмы)
3) при изменении, к примеру, адреса для фирмы, нам потребуется этот адрес поменять во всех записях для данной фирмы.
Кроме того, проблема с данной таблицей заключается в том, что в столбце «Конт.лица» разнородные данные (ФИО, должность, телефон) слиты в единое целое. Один из принципов работы с базами данных заключается в том, что обычно очень просто свести в результате запроса вместе данные из разных столбцов, и очень сложно - произвести дальнейшую детализацию, то есть выделить, к примеру, из последнего столбца номер телефона.
Другой пример избыточности – хранение в таблице полей, значения которые можно получить из других полей. Например, стоимость покупки можно получить, умножив количество на цену; фамилию и инициалы можно получить из полных значений фамилии, имени и отчества и т.д.
Для минимизации избыточности данных используется процесс нормализации, предусматривающий преобразование исходных отношений (таблиц), имеющих избыточность, в новые отношения (таблицы).
Нормальные формы
Будет рассмотрен классический подход, при котором весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером набора ограничений является ограничение первой нормальной формы - значения всех атрибутов отношения атомарны. Поскольку требование первой нормальной формы является базовым требованием классической реляционной модели данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
· первая нормальная форма (1NF);
· вторая нормальная форма (2NF);
· третья нормальная форма (3NF);
· нормальная форма Бойса-Кодда (BCNF);
· четвертая нормальная форма (4NF);
· пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).
Основные свойства нормальных форм:
· каждая следующая нормальная форма в некотором смысле лучше предыдущей;
· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Для дальнейшего изложения нам потребуются несколько определений.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.
Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X (r) R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X (r) R.Z и R.Z (r) R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)
Определение 4. Неключевой атрибут
Неключевым атрибутом называется любой атрибут отношения, не входящий в состав ключа (в частности, первичного).
Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.
Первая нормальная форма
Определение 5.1. Отношение (таблица) находится в первой нормальной форме (1NF), если значения всех ее полей атомарные, и в ней отсутствуют повторяющиеся группы полей.
На «заре» существования реляционных баз данных на количество полей в записи накладывались определенные ограничения. Как следствие, разработчики объединяли несколько предполагаемых полей в одно, чтобы все нужные данные поместить в одну запись. Известно, что если поле содержит несколько значений, то существенно усложняется формирование отношений между полями, считывание данных и выполнение других операций, а необходимость выполнения поиска подстрок и синтаксического анализа полей в значительной степени замедляет работу приложения.
К счастью, сейчас все ограничения на количество полей в записи сняты.
Вторая нормальная форма
Рассмотрим следующий пример схемы отношения:
(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
СОТР_НОМЕР (r) СОТР_ЗАРП
СОТР_НОМЕР (r) ОТД_НОМЕР
ОТД_НОМЕР (r) СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР (r) СОТР_ЗАДАН
Как видно, хотя первичным ключом является составной атрибут (СОТР_НОМЕР, ПРО_НОМЕР), атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа, атрибута СОТР_НОМЕР. В результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого проекта (первичный ключ не может содержать неопределенное значение). При удалении кортежа мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.
Определение 6. Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ)
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
СОТР_НОМЕР (r) СОТР_ЗАРП
СОТР_НОМЕР (r) ОТД_НОМЕР
ОТД_НОМЕР (r) СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем).
Если допустить наличие нескольких ключей, то определение 6 примет следующий вид:
Определение 6
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда оно находится в 1NF, и каждый неключевой атрибут полностью зависит от каждого ключа R.
Здесь и далее мы не будем приводить примеры для отношений с несколькими ключами. Они слишком громоздки и относятся к ситуациям, редко встречающимся на практике.
Третья нормальная форма
Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТР_НОМЕР (r) СОТР_ЗАРП является транзитивной; она является следствием функциональных зависимостей СОТР_НОМЕР (r) ОТД_НОМЕР и ОТД_НОМЕР (r) СОТР_ЗАРП. Другими словами, заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное предположение, но достаточное для примера).
В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела. Т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.
Определение 7. Третья нормальная форма. (Снова определение дается в предположении существования единственного ключа.)
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТР_НОМЕР (r) ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
ОТД_НОМЕР (r) СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму:
Определение 7
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 1NF, и каждый неключевой атрибут не является транзитивно зависимым от какого-либо ключа R.
На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации.
Проектирование баз данных. Информационная избыточность. Избыточность данных в базе данных. Проблемы возникающие из-за информационной избыточности
Как и обещал, эта статья и следующая тоже будут посвящены проектированию баз данных, моделированию баз данных или созданию баз данных, как хотите, так и называйте. Данная публикация посвящена проблемам, которые могут возникнуть при проектирование базы данных, точнее одной из проблем.
Попытаюсь рассказать, как обычно на пальцах, что такое информационная избыточность и избыточность данных в базе данных. Также попытаюсь рассказать о проблемах обработки данных, которые могут возникнуть из-за избыточности информации, затрону тему целостности данных в базе данных. Немного затрону тему нормализации базы данных и нормальных форм, нормальные формы – это тема следующей публикации. Какие нормальные формы бывают и как привести базу данных к нормальной форме. Всё это вы найдете в следующей публикации.
Избавиться от избыточности данных, а следовательно и от аномалий баз данных – это вопрос проектирования баз данных. И решать вопрос устранения избыточности в базе данных следует до того, как вы начали ее реализовывать программно, то есть, до того как начали создавать базу данных в той или иной СУБД, в нашем случае СУБД MySQL.
Чтобы избавиться от информационной избыточности, а вместе с тем решить проблему модификации, удаления и добавления данных вам не потребуется каких-либо специальных программ, достаточно будет представлять структуру проектируемого объекта(заметьте, пока еще не структуру базы данных), иметь под рукой несколько чистых листов бумаги, карандаш или ручку. Но, чтобы начать от чего-то избавляться, нужно знать суть самой проблемы, из-за чего эта проблема возникает и так ли она для вас критична.
Из-за избыточности информации в базе данных возникают не только проблемы модификации, добавления и удаления данных из базы данных, но и остро встает вопрос экономии места на диске, согласитесь глупо хранить одну и ту же информацию в разных местах. Избыточность баз данных тесно связана с нормальными формами. Точнее, информационная избыточность – это отрицательный фактор, влияющий на целостность базы данных, вынуждающий нас приводить свои базы данных к нормальной форме.
Данная публикации как раз и предназначена для тех, кто хочет быстро разобраться с тем, что такое информационная избыточность и избыточность данных в базе данных, а так же тем, кто хочет разобраться с вопросом, как избавиться от избыточности данных.
Информационная избыточность. Избыточность базы данных. Что такое избыточность.
Начнем мы с информационной избыточности и избыточности реляционных баз данных в частности. Поскольку, эта самая избыточность и заставляет нас нормализовывать базы данных.
Для начала напишу умное определение избыточности, а затем постараюсь объяснить его по-русски.
Давайте начнем разбираться с определением избыточности и начнем с термина информационная энтропия.
Информационная энтропия – это мера неопределенности информации, неопределенность появления какого-либо символа. Данное определение появилось в теории электросвязи. Для администратора баз данных информационную энтропию следует интерпретировать немного по-другому: информационная энтропия всё также мера неопределенности информации, но, какая информационная неопределенность может возникнуть в базе данных?
Например, у нас есть база данных, в которой хранится библиотека и есть писатель Иванов И.И., сколько книг написал Иванов И.И.? Бог его знает. Может одну, а может и сто. И сколько раз появится этот Иванов И.И. в нашей таблице, мы не знаем. Такая вот неопределенность информации.
Любая база данных предназначена для хранения информации. И при проектирование базы данных следует учесть то, что какая-то информация может повторяться несколько раз. А каждая повторяющаяся запись – это занятое место на диске. То есть превышение количества информации необходимого для хранения данных.
Конечно, можно сказать, что сейчас, с появлением терабайтных накопителей отпала необходимость экономить место на диске. Но информационная избыточность ведет не только к увеличению требуемого объема памяти для хранения информации содержащейся в базе данных.
Избыточность данных в базе данных – это нежелательное явление еще и потому, что при работе с таблицами базы данных (которые еще называют отношениями), содержащими избыточные данные возникают проблемы связанные с обработкой информации, эти проблемы называются аномалии. Про аномалии баз данных читайте в следующем разделе.
Последствия информационной избыточности в базе данных. Избыточность данных. Аномалии (проблемы) в базе данных.
Как мы уже выяснили, избыточность информации ведет не только к тому, что требуется увеличение объема накопителей, но и приводит к аномалиям в базе данных.
Аномалии в базе данных – это проблемы связанные с обработкой информации, а точнее с удаление данных из базы данных, с модификацией данных в таблице базы данных и аномалия добавления данных в базу данных.
Как вы поняли, в базе данных есть три аномалии:
- Аномалия включения – это проблема, связанная с добавлением данных в базу данных
- Аномалия модификации – это проблема, связанная с изменением данных в базе данных
- Аномалия удаления – это проблема, связанная с удаление данных в базе данных
Все эти проблемы связаны с целостностью баз данных, а именно с избыточностью данных в базе данных. Давайте остановимся подробней на каждой аномалии.
Давайте посмотрим на примере приближенном к реальности, что такое избыточность данных. Допустим, у нас есть таблица, в которой хранятся данные список преподавателей и список предметов, которые они ведут. Естественно, в это таблице присутствует информационная избыточность.
Таблица с информационной избыточностью
Избыточность данных в этой таблице заключается в том, что любой преподаватель может вести несколько предметов, как преподаватель Иванов и для каждого нового предмета приходится добавлять новые записи в таблицу.
Один преподаватель может вести разные предметы, а разные предметы могут вести разные преподаватели. Давайте посмотрим, какие аномалии могут произойти в данном конкретном случае и как можно избавиться от аномалий в конкретном случае.
Аномалия включения. Проблема добавления данных в базу данных.
Избыточность данных очевидна, поскольку произошло дублирование информации, преподаватель Иванов ведет два предмета и его пришлось вписать дважды в таблицу. Но это еще не всё. Допустим, в нашей школе появился новый предмет и мы хотим его добавить в существующую таблицу базы данных, но мы еще не нашли преподавателя для этого предмета. А вписать в таблицу предмет нужно уже сейчас.
В этом случае мы должны присвоить значение NULL каждому атрибуту преподавателя, но делать это никак нельзя, так как атрибут «Код преподавателя» является первичным ключом отношения (первичным ключом таблицы). Результатом попытки создания такой записи будет нарушение целостности данных базы данных, а любая СУБД, в том числе и СУБД MySQL отклонит подобную попытку создания такой записи.
Все вышеописанное является аномалией включения. Чтобы избавиться от аномалии включения нужно разбить таблицу на две: таблица преподавателей и таблица предметов. Примерно это будет выглядеть так:
Избавляемся от избыточности данных в базе данных.
Здесь мы разделили общую таблицу, тем самым избавились от аномалии включения и от возникшей информационной избыточности, то есть от дублирования в базе данных. В принципе то, что мы сделали в данный момент – привели базу данных ко второй нормальной форме.
Вторая нормальная форма позволяет нам избавиться от аномалии включения, а также от дублирования информации в базе данных, то есть мы избавляемся от избыточности информации.
Аномалия модификации. Проблема изменения базы данных.
Следующая проблема, которая может возникнуть из-за избыточности базы данных – это проблема внесения изменений в таблицы базы данных или как ее еще называют – аномалия модификации.
В нашем примере проблема модификации могла бы возникнуть при попытке изменения фамилий преподавателей, например, если бы в этом списке была незамужняя женщина с фамилией Сидорова, то возможно, когда-нибудь она вышла бы замуж и поменяла фамилию, а оператору пришлось бы для каждой записи, в которой имелась фамилия Сидорова заменить на новую фамилию. Это довольно нудная работа. Каждая такая запись или строка таблицы базы данных называется кортежем.
Чтобы избавиться от аномалии модификаций и все связанные с ней проблемы мы можем прибегнуть к предыдущему способу, просто разбиваем одну большую таблицу на две маленьких. То есть, приводим базу данных ко второй нормальной форме или просто нормализуем.
И опять же, таким образом мы избавляемся от дублирования данных в базе данных. Все довольно просто.
Аномалия удаления. Проблема удаления данных из базы данных.
Проблема удаления данных из базы данных – это еще одна проблема, которая появляется, если данные в базе избыточны ее еще называют аномалия удаления. Проблема удаления данных из базы данных заключается в том, что при удаление одной записи или кортежа из таблицы, относящейся к какому-либо из преподавателю, вместе с записью о преподавателе, из базы данных удалится вся информация о предмете, который вел этот преподаватель.
Решается проблема удаления данных из базы данных очень просто, нормализуем базу данных до второй нормальной формы, то есть разделяем таблицу на две, как это показано в разделе посвященном аномалии включения.
Обратите внимание: типы данных у различных СУБД могут быть разными, у MySQL типы данных одни, у какой-либо другой СУБД могут быть другие типы данных, как и у языков программирования. У JavaScript типы данных одни, а у PHP типы данных другие.
Оптимизированные для памяти таблицы требуют наличия достаточного объема памяти для хранения всех строк и индексов в памяти. Поскольку память является ограниченным ресурсом, важно понимать принципы управления загруженностью памяти в системе. Темы в этом разделе описывают распространенные сценарии использования и управления памятью.
При создании новой, оптимизированной для памяти таблицы или переносе существующей на диске таблицы в таблицу Выполняющаяся в памяти OLTP, оптимизированную для памяти, важно иметь оценку требований к памяти для каждой таблицы, чтобы подготовить сервер с достаточным объемом памяти. В этом разделе описывается, как определить объем памяти, необходимый для хранения данных в таблице, оптимизированной для памяти.
Если вы рассматриваете переход от дисковых таблиц к таблицам, оптимизированным для памяти, то перед продолжением чтения посмотрите в разделе Определение, должна ли таблица или хранимая процедура быть перенесена в In-Memory OLTP сведения о том, какие таблицы лучше всего подходят для миграции. Все разделы статьи Миграция в In-Memory OLTP содержат руководство по миграции дисковых таблиц в оптимизированные для памяти.
Основные инструкции по оценке требований к памяти
Начиная с SQL Server 2016 (13.x);, не существует ограничений на размер таблиц, оптимизированных для памяти, хотя таблицы должны умещаться в памяти. В SQL Server 2014 (12.x) размер поддерживаемой данных — 256 ГБ для таблиц SCHEMA_AND_DATA.
Размер оптимизированной для памяти таблицы соответствует размеру данных плюс определенный объем для размещения заголовков строк. При переносе дисковой таблицы в таблицу, оптимизированную для памяти, размер оптимизированной для памяти таблицы будет примерно соответствовать размеру кластеризованного индекса или кучи исходной дисковой таблицы.
Индексы в таблицах, оптимизированных для памяти, как правило, меньше, чем некластеризованные индексы в дисковых таблицах. Размер некластеризованных индексов равен порядка [primary key size] * [row count] . Размер хэш-индексов — [bucket count] * 8 bytes .
Если имеется активная рабочая нагрузка, дополнительная память требуется для управления версиями строк и различных операций. Объем необходимой памяти на практике зависит от рабочей нагрузки, однако для надежности рекомендуется начинать с объема памяти, в два раза превышающего ожидаемый размер оптимизированных для памяти таблиц и индексов и наблюдать, каковы потребности в памяти на самом деле. Объем дополнительных затрат ресурсов на управление версиями строк всегда зависит от характеристик рабочей нагрузки. Так, длительные транзакции увеличивают нагрузку на память особенно сильно. Для большинства рабочих нагрузок, использующих более крупные базы данных (например, более 100 ГБ), расход ресурсов ограничен (25 % и менее).
Эта статья расскажет о том, что такое избыточность базы данных, и как использовать её для повышения производительности.
Избыточность RAID-массива
Избыточность RAID-массива – пожалуй, самый распространённый вид избыточности. RAID расшифровывается как «redundant array of independent disks» (избыточный массив независимых дисков), это значит, что в большинстве конфигураций диски так или иначе зеркалируют друг друга.
Зеркальный массив RAID 1 – базовая реализация избыточности RAID. Он состоит из нескольких (как правило, двух) дисков, которые полностью копируют друг друга. Если один из дисков выходит из строя, вся поддержка, обслуживание и запись данных выполняется вторым диском. Такой массив позволяет ускорить операции чтения, поскольку система может читать данные с любого диска.
В принципе, этот пример относится ко всем RAID-массивам. Теперь особенно хорошо заметно различие между RAID и резервными копиями: любое изменение диска применяется ко всем дискам сразу; то есть, если файл был удалён с одного диска, его сразу не станет и на втором.
Блочная избыточность
Следующий вид избыточности – зеркалирование целых блочных структур. Для этого используется DRBD (distributed replicated block device).
Этот метод чем-то похож на избыточность массивов RAID. Разница заключается в том, где происходит репликация. В RAID-массива, избыточность происходит на уровне приложения. Программное обеспечение RAID управляет физическими устройствами хранения и предоставляет данные приложения с одного из доступных устройств.
Репликация SQL
При работе с базами данных SQL (MySQL, MariaDB, PostgreSQL и т.п.) можно использовать их встроенные функции репликации, чтобы обеспечить отказоустойчивость в случае сбоя основного сервера.
Репликация по типу Master-Slave
Это, пожалуй, самый базовый вид репликации данных SQL. В такой настройке есть один главный сервер, который называется ведущим, или master-сервером. Этот сервер отвечает за все операции записи и обновления данных. Затем данные с этого сервера копируются на ведомый сервер (или slave-сервер).
Эта настройка позволяет распределить операции чтения между несколькими машинами, что может значительно улучшить производительность приложения.
Конечно, увеличение производительности является важным преимуществом; однако не менее важно то, что такая репликация повышает отказоустойчивость. Если master-сервер по какой-либо причине недоступен, операции чтения могут выполняться на серверах slave. Более того, slave-сервер можно перенастроить в master-сервер в случае, если предыдущий master недоступен в течение длительного периода.
Именно на примере репликации master-slave можно увидеть, как репликация данных и резервное копирование могут дополнять друг друга. При такой настройке можно реплицировать данные от ведущего сервера к ведомому. Затем можно временно отключить репликацию, чтобы сохранить данные на slave-сервере в согласованном состоянии, и создать резервную копию базы данных при помощи любого удобного механизма
Примечание: Подробнее о настройке репликации данных по типу master-slave можно прочесть в руководствах:
Репликация по типу master-master
В такой настройке репликации каждый сервер является ведущим, то есть master. Это значит, что каждый сервер может принимать и обновлять данные, после чего изменения будут распространены на остальные серверы. Такая репликация имеет те же преимущества, что и master-slave, и, кроме того, позволяет увеличить производительность с помощью механизма балансировки нагрузки.
Таким образом, если один сервер выходит из строя, то другой может еще и принимать запросы. Конечно, такая конфигурация сложнее, зато она гораздо отказоустойчивее, ведь в случае сбоя не нужно перенастраивать серверы (как при репликации master-slave).
Эту настройку можно совместить с механизмами резервного копирования; для этого нужно отключить один из master-серверов, поскольку во время резервного копирования данные должны находиться в согласованном состоянии. После завершения резервного копирования можно возобновить репликацию.
Примечание: Подробнее о настройке репликации master-master можно прочесть здесь.
Распределение как альтернатива избыточности
Распределенные системы обладают многими преимуществами традиционных настроек избыточности.
Ранее в данном руководстве упоминались RAID-массивы, в частности RAID 1. Ещё один распространённый массив – это RAID 5. Он распределяет данные между несколькими накопителями, а также ведёт контроль по чётности. Информация о чётности хранится на отдельном контрольном диске. Это означает, что в случае отказа одного из дисков любая транзакция может быть восстановлена путём объединения информации о четности на других дисках.
Также существует немало баз данных и других программных решений, предназначенных для распределения данных.
В качестве примера можно привести Riak; это распределенная база данных. Ноды Riak работают точно так же. Между ними нет отношений типа ведущий-ведомый. Объекты, хранящиеся в базе данных, реплицируются.
Однако ноды при этом не содержат полной БД, данные равномерно распределяются между ними. Объекты после репликации размещаются на разных нодах, чтобы обеспечить доступ к данным в случае аппаратных сбоев.
Другим хорошим примером этого подхода является распределённая БД Cassandra. Она основана на тех же принципах, что и Riak, но реализована немного иначе.
Примечание: В следующих статьях можно найти дополнительную информацию по распределённым БД:
Заключение
Как видите, существует множество возможностей для оптимизации работы сервера при помощи избыточности данных. в основном, подход зависит от проблем, которые нужно устранить или предупредить. Кроме того, эти техники можно комбинировать.
Также это руководство хорошо иллюстрирует, что избыточность не заменяет резервное копирование, и наоборот. Избыточные системы всегда в работе и всегда зеркалируют изменения, а это может привести к полной потере данных.
Приложениям, в которых доступ и целостность данных имеют большое значение, необходимо и резервное копирование, и настройка избыточности. Надлежащая реализация этих механизмов гарантирует высокую производительность и надёжную защиту данных.
Читайте также: