Основные подходы к миграции схем баз данных | Статья в журнале «Молодой ученый»

Отправьте статью сегодня! Журнал выйдет 12 декабря, печатный экземпляр отправим 16 декабря.

Опубликовать статью в журнале

Автор:

Рубрика: Информационные технологии

Опубликовано в Молодой учёный №21 (311) май 2020 г.

Дата публикации: 21.05.2020

Статья просмотрена: 18 раз

Библиографическое описание:

Данильчик, В. В. Основные подходы к миграции схем баз данных / В. В. Данильчик. — Текст : непосредственный // Молодой ученый. — 2020. — № 21 (311). — С. 48-50. — URL: https://moluch.ru/archive/311/70460/ (дата обращения: 29.11.2020).



В статье автор пытается рассказать об основных подходах к миграции схем баз данных.

Ключевые слова: миграция схем баз данных, идемпотентность, конвергентность.

В настоящее время все информационные и информационно-аналитические системы не обходятся без использования баз данных. Изменения в структуре данных [1], которые отражают изменения в реальной морфологии объектов или пользовательских требований, привели к исследованию эволюции схемы и ее версионировании. Управление версиями схемы включает концепцию эволюции схемы, которая в свою очередь включает концепцию модификации или миграции схемы.

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

У большинства подходов есть общий принцип: им необходимо основание — некоторое эталонное состояние базы данных (БД), от которого можно отталкиваться. Что из себя представляет основание — это слепок структуры базы данных [2] для версии, которая принята за базовую. Имея основание, впоследствии всегда можно будет создать БД заново. Чтобы получить БД со структурой самой последней версии, нужно применить к этой базе данных все миграции, созданные в процессе разработки.

При разработке программного продукта и, соответственно, написании кода разработчики пользуются системами контроля версий, такими как Git или Subversion. Данные системы позволяют вести совместный процесс разработки несколькими сотрудниками, хранить только разницу между версиями кода, отслеживать и, при необходимости, возвращаться к конкретной версии исходного кода. В то же время применение систем контроля версий при работе со структурами схем данных ограничено.

Также, одной из причин миграции схем данных является наличие каких-либо аномалий либо увеличение нагрузки при анализе работы программного продукта с базой данных, т. к. быстрота работы БД напрямую зависит от ее структуры и выполненной оптимизации.

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

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

Идемпотентность обеспечивает отсутствие изменений объекта при выполнении скрипта повторно в случае, если скрипт был выполнен успешно при первом его запуске. То есть основная идея этого подхода — написание миграционных файлов таким образом, чтобы их можно было выполнить больше одного раза. При первой попытке выполнить любую из SQL-команд, изменения будут применены; при всех последующих попытках ничего не произойдет.

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

Основные подходы:

Метод инкрементных изменений:

Суть данного метода заключается в хранении всей истории изменения структуры базы данных в виде файлов-скриптов в заранее строго определенном порядке и именовании. Выполнение данных скриптов должно быть в соответствующем порядке.

Самый первый файл, который появится в папке миграции, — основание. После этого любое изменение в БД отражается в виде нового файла-миграции с именем вида [номер файла]. [версия].sql.

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

После выполнения каждого файла-миграции в эту таблицу будет заноситься запись со всеми данными о миграции.

Текущую версию БД можно будет получить из записи с максимальной датой.

Завершающий штрих в этом подходе — программа/скрипт, который будет обновлять БД с текущей версии до последней.

Выполнять миграцию БД автоматически довольно просто, т. к. номер последней выполненной миграции можно получить из служебной таблицы, например, MigrationHistory, которая добавляется разработчиком самостоятельно для хранения списка выполненных файлов-миграций (скриптов). После этого остается только применить все файлы с бо́льшими номерами. Сортировать файлы можно по номеру.

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

Плюсы:

  1. Быстрое и удобное выполнение миграции до последней версии;
  2. Механизм нумерации версий. Номер текущей версии хранится прямо в БД;
  3. Для максимального удобства нужны средства автоматизации выполнения миграций.

Минусы:

  1. При попытке использования модуля миграции на основе существующей базы данных, однако при отсутствии служебной таблицы MigrationHistory, обновить базу данных до последней версии не представляется возможным, т. к. истории о выполненных файлах-миграциях, а также самих миграций нет.

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

Метод идемпотентных изменений:

Примечание: в данном методе используется стандарт SQL-92, который включает в себя базу данных information_schema, которая обеспечивает доступ к метаданным базы данных.

Метаданные представляют собой данные относительно данных, имени базы данных или таблицы, тип данных столбца или привилегии доступа. Внутри information_schema имеется несколько таблиц только для чтения. Они фактически являются представлением (view), а не обычными таблицами, так как не имеется никаких файлов, связанных с ними.

В базе данных information_schema существует таблица с именем tables, которая хранит в себе информацию об описании существующих таблиц.

Каждый пользователь MySQL имеет право обратиться к этим таблицам, но может видеть только строки в таблицах, которые соответствуют объектам, для которых пользователь имеет соответствующие привилегии доступа. В некоторых случаях, пользователи, которые имеют недостаточные привилегии, будут видеть NULL.

Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить.

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

Благодаря ключевой фразе IF NOT EXISTS, MySQL попытается создать таблицу только в том случае, если таблицы с таким именем еще не существует. Однако такой синтаксис доступен не во всех СУБД; к тому же, даже в MySQL его можно использовать не для всех команд.

Полную информацию о структуре базы данных можно получить из специальных системных таблиц, находящихся в базе данных с именем information_schema. Эта база данных и ее таблицы — часть стандарта SQL-92, поэтому этот способ можно использовать на любой из современных СУБД. В предыдущем примере используется таблица information_schema.tables (системная таблица), в которой хранятся данные о всех таблицах. Подобным образом можно проверять существование и метаданные полей таблиц, хранимых процедур, триггеров, схем, и, фактически, любых других объектов структуры базы данных.

Плюсы:

  1. Очень удобное выполнение миграций с любой промежуточной версии до последней — нужно всего лишь выполнить на базе данных один файл.

Минусы:

  1. Потенциально возможны ситуации, в которых будут теряться данные, за этим придется следить. Примером может служить удаление таблицы, и затем создание другой таблицы с тем же именем. Если при удалении проверять только имя, то обе операции (удаление и создание) будут происходить каждый раз при выполнении скрипта, несмотря на то, что когда-то уже выполнялись;
  2. Для того, чтобы изменения были идемпотентными, нужно потратить больше времени (и кода) на их написание.

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

Выводы:

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

Литература:

  1. Версионирование структуры БД с помощью Liquibase [Электронный ресурс] — Режим доступа: http://easy-code.ru/lesson/database-versioning-liquibase
  2. Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с.
Основные термины (генерируются автоматически): баз данных, таблица, последняя версия, данные, изменение, подход, программный продукт, скрипт, служебная таблица, основная идея.


Ключевые слова

миграция схем баз данных, идемпотентность, конвергентность

Похожие статьи

Анализ подходов миграций баз данных в корпоративных...

‒ получение последней версии базы данных одним скриптом. Минусы: ‒ потеря данных (например, если в скрипте изменений требуется удалить таблицу

Flywaydb — программный продукт, использующий 3-й подход. Имеет поддержку огромного количества баз данных.

Пример реализации инструмента для автоматизации процесса...

‒ хранение в скриптах изменения настроек баз данных, сервера и пр.; ‒ хранение всех скриптов для различных рабочих БД в едином каталоге.

В основе данного подхода лежит один скрипт, позволяющий создать новую базу данных с нуля до последней версии.

Разработка базы данных для отдела кадров в программе...

Последний этап моделирования базы данных — переход к физическому уровню модели, на

Основной целью процесса проектирования является генерация физической схемы базы

После генерации SQL-скрипта переходим к созданию базы данных Interbase (IBExpert) и...

Разработка программного модуля тестирования баз данных

Ключевые слова: база данных, СУБД, реляционные базы данных, нереляционные базы данных, NoSQL. Базы данных являются незаменимым инструментом в разработке программного обеспечения.

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

Таблица 1. Сравнение программных продуктов по базовым возможностям.

Программный продукт рассчитывает и формирует более 100 аналитических таблиц, финансовых коэффициентов и

В актуальных версиях программы «1С: Бухгалтерия 8.3» интегрирована...

Концепция базы данных для системы электронного...

Задачей базы данных будет заполнение таблицы HISTORY и построение пути документа с учетом типов документов и загруженности сотрудников. Алгоритм заполнения таблицы: 1) Определение статуса документа, завершен документ или нет.

СУБД Oracle: DDL триггер, как средство контроля изменения...

Контроль изменений в структуре базы данных (БД), с последующим сохранением этих

Начав с вопроса, как отследить изменение структуры таблиц в определенной схеме данных СУБД

Основная идея – это создание триггера, который позволяет отловить событие, связанное с...

Методы выполнения запросов к хранилищу данных в Hadoop...

Рис. 1. Популарность баз данных. Нерелационные базы завоёвывают популярность за последние 5 лет.

Как говорилось выше, одна из основных идей Hadoop и Spark — хранить данные без изменений в форме простых файлов в системе, оптимизированной под большие...

Автоматизация развертывания компонент распределенного...

Первый этап, настройка сервера баз данных: – Получение удаленного доступа к серверу через приложение

Второй этап, настройка программных компонентов системы на узлах филиала: Задачи данного этапа

Основная идея данного средства схожа с идеей Ansible: максимально...

Похожие статьи

Анализ подходов миграций баз данных в корпоративных...

‒ получение последней версии базы данных одним скриптом. Минусы: ‒ потеря данных (например, если в скрипте изменений требуется удалить таблицу

Flywaydb — программный продукт, использующий 3-й подход. Имеет поддержку огромного количества баз данных.

Пример реализации инструмента для автоматизации процесса...

‒ хранение в скриптах изменения настроек баз данных, сервера и пр.; ‒ хранение всех скриптов для различных рабочих БД в едином каталоге.

В основе данного подхода лежит один скрипт, позволяющий создать новую базу данных с нуля до последней версии.

Разработка базы данных для отдела кадров в программе...

Последний этап моделирования базы данных — переход к физическому уровню модели, на

Основной целью процесса проектирования является генерация физической схемы базы

После генерации SQL-скрипта переходим к созданию базы данных Interbase (IBExpert) и...

Разработка программного модуля тестирования баз данных

Ключевые слова: база данных, СУБД, реляционные базы данных, нереляционные базы данных, NoSQL. Базы данных являются незаменимым инструментом в разработке программного обеспечения.

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

Таблица 1. Сравнение программных продуктов по базовым возможностям.

Программный продукт рассчитывает и формирует более 100 аналитических таблиц, финансовых коэффициентов и

В актуальных версиях программы «1С: Бухгалтерия 8.3» интегрирована...

Концепция базы данных для системы электронного...

Задачей базы данных будет заполнение таблицы HISTORY и построение пути документа с учетом типов документов и загруженности сотрудников. Алгоритм заполнения таблицы: 1) Определение статуса документа, завершен документ или нет.

СУБД Oracle: DDL триггер, как средство контроля изменения...

Контроль изменений в структуре базы данных (БД), с последующим сохранением этих

Начав с вопроса, как отследить изменение структуры таблиц в определенной схеме данных СУБД

Основная идея – это создание триггера, который позволяет отловить событие, связанное с...

Методы выполнения запросов к хранилищу данных в Hadoop...

Рис. 1. Популарность баз данных. Нерелационные базы завоёвывают популярность за последние 5 лет.

Как говорилось выше, одна из основных идей Hadoop и Spark — хранить данные без изменений в форме простых файлов в системе, оптимизированной под большие...

Автоматизация развертывания компонент распределенного...

Первый этап, настройка сервера баз данных: – Получение удаленного доступа к серверу через приложение

Второй этап, настройка программных компонентов системы на узлах филиала: Задачи данного этапа

Основная идея данного средства схожа с идеей Ansible: максимально...

Задать вопрос