«Переезд» в другую СУБД: как не потерять данные
Вопросы «переезда» из одной СУБД в другую всплывают регулярно, особенно актуальны они для растущих компаний. В Modus мы сталкиваемся с такими кейсами все чаще и чаще. Поэтому начнем говорить о миграции и о том, как этот процесс проходит для наших пользователей. Сразу оговорюсь, что первая статья будет довольно простая и в большей степени общеобразовательная — для тех, кто только начинает разбираться в вопросе.
Что такое СУБД и причем здесь Modus
Система управления базами данных (СУБД) — это программное обеспечение для создания, хранения, изменения и управлениями данными. В рамках аналитики СУБД может использоваться в качестве источника данных, либо как аналитическое или корпоративное хранилище, где происходит консолидация информации для ее дальнейшего использования.
О причинах популярности запроса на «переезд» из одной СУБД в другую я расскажу ниже. Вне зависимости от обстоятельств, компании хотят мигрировать быстро и продуктивно, без потери накопленных данных и получения некорректных показателей в дашбордах на экранах пользователей.
Решения Modus способны обеспечить классический бесшовный (итерационный) переход между системами управления базами данных: источники из текущей СУБД в дашбордах подменяются на источники из целевой СУБД по мере готовности. Только так можно обойтись без простоев, вызванных миграцией.
Что заставляет компании менять СУБД
Замена системы управления базами данных — это комплексная задача. В числе ключевых причин, подталкивающих компании к таким изменениям:
1. Импортозамещение
Организации, связанные с госсектором, некоторое время назад приступили к форсированному переходу на российское ПО. Коммерческие компании столкнулись с тем же процессом из-за ухода зарубежных поставщиков СУБД. Около 60% проектов по продуктам Modus возникли благодаря запросу на замещение импорта. Все меняют Oracle, Vertica или Teradata на отечественные аналоги.
2. Эволюция
Компании, ориентированные на получение профита за счет данных, вкладывают средства в инфраструктуру и персонал. Однако с течением времени подход к проектированию архитектуры аналитических решений меняется. До 25% наших проектов — это задачи, связанные со стартом или развитием аналитических решений в организациях.
Существуют и другие, менее популярные причины для «переезда» компании в другую СУБД. На практике они встречаются реже:
Затраты на покупку лицензии и поддержку. Бизнес может искать экономичные аналоги с более выгодными и гибкими условиями.
Ограничение функциональности. Текущая система управления базами данных не поддерживает необходимые возможности или не соответствует требованиям команды.
Проблемы безопасности. Уязвимости в текущей СУБД создают угрозы, мешающие защищать данные компании.
Еще одна причина — это переход на облачные решения, которые требуют поддержки других СУБД. Они набирают популярность, потому что позволяют платить только за фактически потраченные вычислительные мощности. Этот тренд развивается последние 2–3 года.
Особенности бесшовной миграции
Итак, компания начинает работать с аналитикой и разворачивает, например, СУБД PostgreSQL в качестве корпоративного/аналитического хранилища данных. Подгружает туда данные из Excel и автоматизирует процессы посредством Modus ETL — подключает новые источники в виде веб-сервисов, учетных систем и пр.
Здесь нужно остановиться и разобраться в подходе, используемом в Modus при работе с данными. По сути, построение стандартного аналитического решения протекает в несколько этапов. После всех исследований, определений источников и целей детальной аналитики наступает фаза реализации.
Modus ETL отвечает:
за подключение к источникам;
за настройку правил сбора данных из источников в хранилище;
за точечную настройку сценариев обработки данных;
за создание витрин данных.
Построение дашбордов на основании витрин производится на аналитическом портале.
Однако в один «прекрасный» день количество отчетов преодолевает критическое значение. Обновление данных забивает все ресурсы, а перед компанией встает вопрос: «Что делать дальше?».
Решение проблемы очевидно: нужно менять архитектуру на более подходящую — переходить на MPP-СУБД (Greenplum), колоночную СУБД (ClickHouse) или делать гибридное хранилище (на Greenplum и ClickHouse соответственно).
В момент замены СУБД пригодится функционал Modus ETL, разработанный как раз для решения этой задачи. Платформа бесшовно переключает на другую СУБД аналитическое или корпоративное хранилище, в котором консолидируется информация. Причем все ранее настроенные сценарии обработки данных модифицируются под новую систему управления базами данных: одно действие заменяет многочасовую работу аналитиков по переписыванию скриптов.
Функция построена на принципе, что каждый шаг преобразования данных в сценариях Modus ETL — это шаблон операции с данными. По сути, это SQL-запрос, обернутый в интерфейс no-code или low-code, который автоматически подстраивается под текущую СУБД. В числе самых частых кейсов — «переезд» из MS SQL на PostgreSQL/Greenplum.
Как не потерять данные при «переезде»
Крупных проблем, которые могут «случиться» в момент миграции данных из одной СУБД в другую, две:
потеря накопленной компанией информации;
получение некорректных показателей в дашбордах на экранах пользователей.
Чтобы этого не произошло, нужно начать процесс с резервного копирования текущего состояния системы. Бэкап нужен, чтобы:
восстановить ценные данные при обнаружении проблем;
провести тестирование текущей и целевой архитектуры;
чувствовать себя намного спокойнее, что тоже важно.
Следующий момент — изучение особенностей целевой системы управления базами данных:
особенностей синтаксиса;
лучших практик;
совместимости функций и типов данных с текущей СУБД.
Далее нужно определить зависимости и уточнить последовательность миграции таблиц, сценариев и дашбордов с учетом зависимостей.
Еще один важный шаг — создание подробного плана миграции. Необходимо проработать:
концептуальный план миграции;
план переноса исторических данных;
план настройки инкрементального обновления;
план создания и настройки витрин данных;
план адаптации дашбордов под новые витрины;
план тестирования и пр.
Когда бэкапы созданы, зависимости определены, а планы — проработаны до мельчайших деталей, можно приступать к непосредственной разработке (миграции).
Полезные советы
Было бы неплохо провести сначала тестовую миграцию на отдельном сервере или в тестовой среде. Так можно выявить возможные проблемы и устранить их до начала работы. Протестировать нужно все этапы, учитывая каждую особенность текущей и целевой СУБД.
Нельзя пренебрегать инструментами миграции — они упрощают работу, автоматизируют процессы и минимизируют риски появления ошибок. Отличным помощником станет решение Modus ETL, способное организовать бесшовный (итерационный) переход между системами.
Не стоит забывать о мониторинге и верификации. По завершении основных работ тщательно проверьте целостность данных и убедитесь, что информация была перенесена в полном объеме. Здесь пригодится копия текущей СУБД, с которой можно сравнить целевую систему.
Документируйте процесс. Создавайте подробную документацию по каждому шагу миграции. Как минимум, чтобы в дальнейшем обосновать затраты на перенос перед вышестоящими руководителями.
«Переезд» с одной СУБД на другую — это сложный процесс, требующий тщательной подготовки. Выполнять его нужно с учетом контроля на каждом этапе. Правильно выполненная миграция минимизирует риски и проблемы, связанные с переносом данных, и обеспечивает успешное внедрение новой системы.
