exam14 2
Реферат к лекции 14-30 Шаблоны проектирования программ и баз данных.
Выполнил: Меликян Георгий, группа ИДБ-18-06
Проверил: Зиновьев Владислав ИДБ-18-05
Структура базы данных — совокупность всех объектов БД и статических данных. Пользовательские данные в понятие структуры БД не входят.
Версия базы данных — определенное состояние структуры базы данных. Обычно у версии есть номер, связанный с номером версии приложения.
Миграция (в данном контексте) — обновление структуры базы данных от одной версии до другой (обычно более новой).
Итак, представьте себе следующую ситуацию: команда из нескольких программистов разрабатывает приложение, которое активно использует базу данных. Время от времени приложение поставляется в продакшн с новыми пакетами обновлений. Любому программисту в процессе написания кода приложения может понадобиться изменить структуру базы данных, а также, сами данные, которые в ней хранятся.
Для того чтобы между версиями двух баз данных (новой и старой) не происходило конфликта, их необходимо правильно "сшивать", иначе говорят - мигрировать.
Структура файлов
Пример того, как в этом случае может выглядеть папка с файлами-миграциями:
Database
|- Baseline.sql
|- 0001.03.01.sql
|- 0002.03.01.sql
|- 0003.03.01.sql
|- 0004.03.02.sql
|- 0005.03.02.sql
|- 0006.03.02.sql
|- 0007.03.02.sql
В этом примере в папке хранятся все файлы, созданные при разработке версии 03. Впрочем, папка может быть и общей для всех версий приложения.
В любом случае, самый первый файл, который появится в такой папке, — основание (Baseline.sql). После этого любое изменение в БД сабмиттится в репозиторий в виде нового файла-миграции с именем вида [номер файла].[версия].[подверсия].sql
Фактически, в этом примере в имени файла содержится полный номер версии БД. То есть после выполнения файла-миграции с именем 0006.03.02.sql база данных обновится с состояния, соответствующего версии 03.02.0005, до версии 03.02.0006.
Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить. В тему вспоминается смешная сцена из «Друзей» :)
Основная идея этого подхода — написание миграционных файлов таким образом, чтобы их можно было выполнить на базе данных больше одного раза. При первой попытке выполнить любую из SQL-команд, изменения будут применены; при всех последующих попытках ничего не произойдет.
Эту идею проще всего уяснить на примере. Допустим, вам нужно добавить в БД новую таблицу. Если вы хотите, чтобы в том случае, если она уже существует, при выполнении запроса не возникло ошибки, — в MySQL для этих целей есть краткий синтаксис:
CREATE TABLE IF NOT EXISTS myTable (id INT(10) NOT NULL, myField VARCHAR(255) NULL, PRIMARY KEY(id));
Благодаря ключевой фразе IF NOT EXISTS, MySQL попытается создать таблицу только в том случае, если таблицы с таким именем еще не существует. Однако такой синтаксис доступен не во всех СУБД; к тому же, даже в MySQL его можно использовать не для всех команд.
Основная идея этого метода отражена в заголовке: структура БД — такой же исходный код, как код PHP, C# или HTML. Следовательно, вместо того, чтобы хранить в репозитории кода файлы-миграции (с запросами, изменяющими структуру БД), нужно хранить только актуальную структуру базы данных — в декларативной форме.
Для простоты примера будем считать, что в каждой ревизии репозитория всегда будет только один SQL-файл: CreateDatabase.sql. В скобках замечу, что в аналогии с исходным кодом можно пойти еще дальше и хранить структуру каждого объекта БД в отдельном файле. Также структуру можно хранить в виде XML или других форматов, которые поддерживаются вашей СУБД.
В файле CreateDatabase.sql будут храниться команды CREATE TABLE, CREATE PROCEDURE, и т.д., которые создают всю базу данных с нуля. При необходимости изменений структуры таблиц, эти изменения вносятся непосредственно в существующие DDL-запросы создания таблиц. То же касается изменений в хранимых процедурах, триггерах, и т.д.
К примеру, в текущей версии репозитория уже есть таблица myTable, и в файле CreateDatabase.sql она выглядит следующим образом:
CREATE TABLE myTable (id INT(10) NOT NULL, myField VARCHAR(255) NULL, PRIMARY KEY(id));
Если вам нужно добавить в эту таблицу новое поле, вы просто добавляете его в имеющийся DDL-запрос:
CREATE TABLE myTable (id INT(10) NOT NULL, myField VARCHAR(255) NULL, newfield INT(4) NOT NULL, PRIMARY KEY(id));
После этого измененный sql-файл сабмиттится в репозиторий кода.
На сегодняшний день разработано множество способов, программ и устройств, предназначенных для защиты данных от потери, но в основе их лежит общий принцип – запись и хранение избыточной информации. В большинстве случаев он реализуется путем создания копий данных.
Различают два основных способа копирования данных:
- резервное копирование,
- архивирование.
Резервное копирование данных (backup) – это процесс сохранения избыточных копий файлов и каталогов, находящихся на локальных дисках, на сменные носители, обычно магнитные ленты. Избыточные копии могут использоваться для восстановления в случае, если оригинальные файлы потеряны или повреждены. Резервное копирование чаще всего планируется на ежедневной основе. При этом любые новые файлы, или файлы, измененные с момента последнего копирования, оказываются на лентах, так что они будут доступны для восстановления на диск.
Архивирование данных (archive) – это процесс получения «слепка» файлов и каталогов в том виде, в котором они располагаются на первичном носителе (обычно диск) в данный момент времени. Образ «слепка» обычно сохраняется на сменном носителе, чаще всего на лентах или оптических дисках. Когда он полностью переписан на сменный носитель, соответствующие файлы могут быть удалены для освобождения места на дисках.
Существует три основных метода резервного копирования данных:
- Полное.
- Инкрементальное.
- Дифференциальное.
При полном резервном копировании заданный набор файлов (например, файловая система) полностью записывается на магнитную ленту. Этот метод самый надежный, но занимает много времени и ведет к большому расходу магнитной ленты. Восстановление информации при полном копировании осуществляется наиболее быстро, так как для этого достаточно только одного записанного образа.
Инкрементальный метод представялет собой поэтапный способ записи информации. При использования этого способа первая запись на ленту является полной копией. При второй записи на ленту помещаются только файлы, которые были изменены со времени первой записи. На третьем этапе копируются файлы, модифицируемые со времени второго этапа, и.т.д, то есть на каждом этапе на ленту переносятся только файлы, атрибуты которых изменились со времени предыдущей записи. По истечении заданного оператором времени цикл повторяется снова и начинается с полной копии файловой системы или каталогов.Данный метод копирования является самым быстрым и ведет к минимальному расходу магнитной ленты. Однако, восстановление информации при инкрементальном копировании – самое длительное: информацию необходимо сначала восстановить с полной копии, а затем последовательно со всех последующих. Тем не менее, это самый популярный метод резервного копирования у системных администраторов, поскольку восстановление информации процедура достаточно редкая в нормально работающей системе.
При дифференциальном методе первая запись на ленту также является полной копией. На последующих этапах копируются только файлы, которые изменились со времени проведения полного копирования. По времени резервного копирования этот метод занимает больше времени, чем при инкрементальном копировании. Однако для восстановления данных достаточно всего двух копий – последней полной и последней дифференциальной копии.
В наборе утилит, прилагающихся к любой СУБД, обязательно есть инструменты для выгрузки и загрузки данных. Данные сохраняются либо в текстовом формате, либо в двоичном формате, специфичном для конкретной СУБД.
Несмотря на простоту и очевидность идеи выгрузки данных, для резервирования нагруженных промышленных баз такой метод применяют редко. Вот причины, по которым выгрузка не подходит для полноценного резервного копирования:
- процесс выгрузки создаёт значительную нагрузку на систему-источник;
- выгрузка занимает много времени – к моменту окончания выгрузки она станет уже неактуальной;
- сделать согласованную выгрузку всей базы данных при высокой нагрузке практически невозможно, поскольку СУБД вынуждена хранить снимок своего состояния на момент начала выгрузки. Чем больше транзакций совершено с момента начала выгрузки, тем больше объём снимка (неактуальных копий данных в PostgreSQL, пространства undo в Oracle, tempdb в Microsoft SQL Server и т. п.);
- выгрузка сохраняет логическую структуру данных, но не сохраняет их физическую структуру – параметры физического хранения таблиц, индексы и др.;
- восстановление индексов при загрузке может занимать значительное время.
Тем не менее, у выгрузки есть и достоинства:
- высокая избирательность: можно выгрузить отдельные таблицы, отдельные поля и даже отдельные строки;
- выгруженные данные можно загрузить в базу данных другой версии, а если выгрузка сделана в текстовом формате, то и в другую базу данных.
Самым же распространённым методом резервного копирования баз данных является копирование файлов базы.
Очевидная идея – остановить базу данных и скопировать все её файлы. Такая резервная копия называется «холодной». Способ крайне надёжный и простой, но у него есть два очевидных недостатка:
- из «холодной» резервной копии можно восстановить только то состояние базы данных, которое было в момент останова; транзакции, сделанные после рестарта базы, в «холодную» резервную копию не попадут;
- далеко не у каждой базы данных есть технологическое окно, когда базу можно остановить.
Если же «холодное» резервное копирование вас устраивает, нужно помнить что
- «холодная» копия иногда должна включать в себя и журналы. Методы определения журналов, которые должны попасть в «холодную» копию, индивидуальны для каждой СУБД. Например, в Oracle необходимо скопировать так называемые online redo, то есть фиксированное количество журнальных файлов в специальном каталоге, причём даже тогда, когда база остановлена корректно. В PostgreSQL нужно сохранить все журналы начиная с журнала, содержащего последнюю контрольную точку, информация о которой содержится в управляющем файле.
- каталог базы данных может содержать достаточно большие файлы временных табличных пространств, которые не обязательно включать в резервную копию.
Чтобы ускорить восстановление на точку, хотелось бы иметь возможность выполнять резервное копирование как можно чаще, но при этом не занимать лишнего места на дисках и не нагружать базу задачами резервного копирования.
Решение задачи – инкрементальное резервное копирование, то есть копирование только тех страниц данных, которые изменились с момента предыдущего резервного копирования. Инкрементальное резервное копирование имеет смысл только для СУБД, использующих изменяемые структуры данных.
Инкремент может отсчитываться как от полной резервной копии (кумулятивная копия), так и от любой предыдущей копии (дифференциальная копия).
Рис. 1 Инкрементальное копирование
Данные имеют огромное значение для бизнеса, предприятия и различного рода организаций, так что обеспечение их сохранности является одной из важнейших задач. Резервирование данных играет в этом процессе основную роль. Первым шагом при обеспечении постоянного доступа к данным является создание системы регулярного резервирования и проверочного восстановления баз данных. При создании новой базы данных следует сразу же создавать сценарии для резервирования и восстановления.