Спасибо людям, которые не стесняются поделиться своими мыслями и опытом, пусть даже негативным, по многим важным вопросам организации работы с системами БД. Я наткнулся на статью «Версионная миграция структуры БД: почему так лучше не делать», думал прокомментировать ее, но, рассмотрев дату публикации, решил написать свою. Совершенно очевидно, что автор имел собственное представление о значении и смысле слов, вынесенных им в заголовок. А неточное представление привело к тому, что решалась совсем не та задача. На Хабре довольно давно появились статьи, посвященные организации версионной миграции БД. Они легко обнаруживаются поиском по ключевым словам. Вот в этой статье: ВЕРСИОННАЯ МИГРАЦИЯ СТРУКТУРЫ БАЗЫ ДАННЫХ: ОСНОВНЫЕ ПОДХОДЫ приведено отличное введение в терминологию, задачи и основные методики их решения.
Мне хотелось бы на собственном примере рассказать о тех нежданных проблемах, которые без приглашения внезапно возникли перед нашей группой на одной из моих старых работ, и о том, чего нам тогда не хватало, для быстрого и эффективного разрешения ситуации – в общем, тоже негативный опыт — вдруг кому-то пригодится сейчас или в будущем. Несмотря на то, что в нашей компании мы более широко подходим к решению подобных задач, объединяя их под термином «Управление изменениями в БД», я постараюсь оставаться в поле терминологии из статьи выше.
ОПЫТ ПРОШЛЫХ ЛЕТ – О НЕРЕШЕННЫХ ПРОБЛЕМАХ
В 1997 году перед группой разработчиков, куда я только что вошел, была поставлена задача в течение 3 месяцев создать программный комплекс, который реализует автоматизированную технологию, которая должна была лечь в основу бизнес-деятельности всей компании. Дело давнее и, с вашего разрешения, я не буду углубляться в подробности и детали технологии и бизнес-процессов. Важно то, что нужно было обработать и взаимоувязать ежедневно принимаемые данные, поставляемые в значительных объемах из двух независимых внешних источников, накапливать их в хранилище, с минимальными задержками выдавать ответы по произвольным запросам от наших потребителей – менеджеров внутри компании, выполнять прогноз множества показателей на основе ретроспективного анализа накопленных объемов информации. Эта задача была выполнена, была создана типичная внутренняя корпоративная система, которая работает с той поры и до сих дней, успешно видоизменяясь и дорабатываясь в течение всего этого срока.
Первые признаки проблемы появились тогда, когда руководство IT-департамента приказало обеспечить перенос копии этой системы в дата-центр одного из заказчиков. При этом, срок, как водится, был «вчера». Поскольку источником информации были те же самые, что и у нас, потоки данных от того же поставщика, сильно изменять технологию не пришлось, ETL остался практически тем же, список запросов был сужен, набор отчетов чуть изменен и ограничен. Тем не менее, техническая база, на которой все это должно было работать, была уже другая: вместо Oracle там имелась СУБД MS SQL Server. Зато, сама структура базы не изменилась, даже типы данных не потребовали сложной конверсии.
Теперь в нашей поддержке стало две близких по дизайну и функционалу, но различных по реализации версий системы. Скоро сказка сказывается, через некоторое время мы получили в поддержку еще около 30 одинаковых систем для работы в филиалах по всей стране. Deploy новых версий осуществлялся копированием новой версии из центра. С точки зрения версионной миграции это была одна стандартная версия, даже параметры конфигурации всех серверов должны были быть одинаковыми, самодеятельность местных администраторов не просто не поощрялась, а запрещалась, и нарушения этого запрета должны были контролироваться ежедневно. Так же необходимо было иметь контроль за состоянием и содержимым справочников – основы для дальнейшего «сведения» информации из филиальных баз данных в центральную – и содержимое должно было быть гарантировано одинаковым для всех местных баз.
Ну и последним этапом, как многие уже догадались, стало появление еще 4-5 отдельных вариантов для обеспечения работы отделений компании за рубежом. Причем, в каждой стране свой поставщик исходных данных, некоторых элементов данных не хватает, часть необходимой информации «разбросана» по поставляемым наборам, часть показателей рассчитана по другим правилам. Значит, каждый вариант кардинально отличается в ETL-части, и это относится не только к приложениям и процедурам, но и к структурам данных т.н. Stage Database (рабочей БД для выполнения преобразований ETL без помех основной).
Таким образом, разработав систему для сугубо внутреннего использования, спустя короткое время, без каких-либо продуманных на перспективу планов, мы обнаружили себя выступающими в роли содержателей большого зоопарка экзотических версий. И полагаю, не только мы.
Сколь бы общей и краткой не была эта история, из нее можно извлечь некоторые характерные особенности, связанные с миграцией БД.
- Одновременная поддержка большого количества различных версий приложения — объективная реальность, не зависящая от желаний разработчиков или пользователей
- Миграция требуется не только при переносе БД на другой сервер или платформу СУБД, но и при синхронизации БД с имеющимся вариантом (версией, поколением) прикладного ПО
- Отличие версий связано не только с отличиями в логике обработки и структурах БД, но и в различных платформах СУБД, а так же в специальных параметрах настройки на имеющееся «железо».
- Требуется не только управление процессом миграции, но и контроль неизменности схем, данных и настроек, аудит (отчетность) по составу элементов, которые были изменены, кем и на какие значения
- Изменения структуры базы данных при миграции часто влекут за собой дополнительную обработку/преобразование хранимых общих данных
Наверно, нам было легче, поскольку задания «наваливались» постепенно. Да и команда была стабильна, с четко распределенными функциями каждого сотрудника, как по вертикальным направлениям деятельности, так и по частным задачам. Тем не менее, каждый раз, когда в прикладное ПО вносились изменения, все равно плановые или спонтанные, мы должны были перевести всех на новую версию приложения. А версия рабочей БД должна соответствовать этой обновленной версии, надо выполнить версионную миграцию схем, данных, настроек.
В той или иной степени пригодные решения существуют и достаточно распространены. Важно прийти к наиболее удобному и менее трудоемкому методу. Я рассказываю о негативном опыте, поскольку сейчас бы уже выбрал другую технологию, и очень жалею об ее отсутствии в то время.
Казалось бы, чего проще иметь единые скрипты на модификацию всех серверов и в автоматическом режиме выполнять их на каждом сервере!
Первая проблема заключалась в том, что в разных местах версии прикладных программ, на которые надо было переходить, были разные! Единого скрипта модификации не могло существовать, приходилось тратить массу времени на изучение актуального состояния, написание и тестирование скриптов для каждого сервера в отдельности. Тестирование – это отдельный вопрос, поскольку сначала следовало создать тестовый стенд.
Поддержка журнала изменений, которые были внесены на отдельном сервере за время существования старой версии приложения, не принесла облегчения, поскольку если таких изменений было несколько, скрипты синхронизации должны выполняться строго в «правильной» последовательности, причем, в ряде случаев, повторное выполнение одного скрипта является абсолютно недопустимым – результат будет уже необратим.
А теперь помножьте затраченное время на количество разных серверов!
Обратная задача: местный админ решил самостоятельно «улучшить» базу данных или, например, из-за нехватки места на диске, «снес» большой индекс и «забыл» восстановить его после переноса файлов БД на другой носитель. Мы могли бы обнаружить такие изменения настроек и структуры достаточно легко, но нужно иметь именно этот вариант БД в исходном состоянии, чтобы было с чем сравнивать. И если изменения в схеме получалось обнаружить и исправить достаточно быстро, изменения в параметрах конфигурирования сервера или в собственно данных обнаруживались с большими усилиями и за намного более длительный срок. А дальше выполнять всю технологию создания скриптов коррекции и их выполнения. А заодно провести расследование, кто и в какой момент внес эти изменения.
Если бы имелись доступные инструментальные средства, которые автоматически поддерживали подход к структуре БД, как к исходным текстам, аналогично всем привычным системам управления исходными текстами на различных языках программирования, значительно облегчилось бы выполнение следующих задач:
- Обновление БД с конкретной версии на любую другую за один шаг, как на более позднюю, так и возврат к предыдущей;
- Легкое получение скриптов миграции в автоматическом режиме, с возможностью «ручного» внесения исправлений в крайнем случае;
- Создание «с нуля» нового экземпляра БД, соответствующего имеющейся версии приложения;
- Простое создание тестовых/девелоперских экземпляров БД на базе актуальных рабочих БД для ведения разработки на них, которые максимально соответствуют этим рабочим.
- Контроль и аудит нежелательных изменений в экземплярах БД, при необходимости автоматический возврат к эталонному состоянию в сжатые сроки.
Это то, чего так не хватало в описываемой истории. Этот подход не очень эффективно применять без использования каких-то инструментальных решений, но у нас тогда не хватало ни времени, ни ресурсов на разработку собственной полноценной утилиты. Мешала и политика руководства IT-департамента. Тем не менее, сегодня существуют и готовые продукты, реализующие этот подход, каждый со своим набором возможностей и функций. Об одном из возможных решений я планирую рассказать в следующей публикации
Существует множество различных способов и решений хранить и управлять изменениями в БД. Важно найти наиболее приемлемый подход и применить инструмент, который поможет вам повысить степень автоматизации версионной миграции БД, повысить качество и надежность вашей работы, сэкономить ресурсы и время ваших сотрудников. В этой статье я постарался на жизненном примере рассказать, откуда возникают проблемы управления изменениями БД, какие трудности это влечет, и к какому выводу я пришел на базе этого, по большому счету, негативного опыта.
Автор: sandy97
