Свяжитесь с нами
Процесс импортозамещения СУБД на Postgres Pro
20 февраля 2024
Узнайте, как проходит процесс импортозамещения СУБД на Postgres Pro, и какие инструменты при этом используются. Высокая производительность баз данных. Читайте статью.
Содержание
- Что значит «миграция в Postgres Pro»
- Особенности миграции Oracle в Postgres
- Особенности миграции с MySQL на Postgres Pro
- Особенности миграции данных из MS SQL в Postgres Pro
- Как начать миграцию баз данных Postgres Pro
- Технологическая часть миграции данных Postgres Pro
- Инструменты для миграции Postgres Pro
- EMS Data Pump for Postgres Pro
Необходимость миграции баз данных зарубежных проприетарных СУБД (Oracle, MS SQL, DB2 и т. д.) на СУБД Postgres Pro обычно возникает в 4-х случаях:
По данным TAdviser, государственные компании втрое чаще закупают отечественные СУБД. Например, в 2021 году на решения российских разработчиков приходилось около 55 контрактов, а в прошлом году их число составляло уже более 200. Переход на Postgres Pro стал своеобразным «трендом-2022». Но и в 2023 компании нередко обращаются к ИТ-специалистам для миграции баз данных из СУБД Oracle или MSSQL в Postgres Pro. Поэтому вопрос актуальный.
Необходимо отметить, что государственные компании всегда используют в качестве целевой СУБД для миграции именно Postgres Pro, а не свободно-распространяемый PostgreSQL. Причина этого кроется в том, что только Postgres Pro входит в реестр российского ПО для импортозамещения. Также немаловажную роль играет наличие технической поддержки для Postgres Pro.
- Необходимость выполнения постановления Минцифры о применении ПО из реестра российского ПО в информационных системах.
- Снижение лицензионных отчислений и общей стоимости содержания.
- Избавление от потенциальных санкционных рисков в целях обеспечения непрерывности ведения бизнеса.
- Замена устаревших версий СУБД, не обеспечивающих нужного функционала или производительности.
По данным TAdviser, государственные компании втрое чаще закупают отечественные СУБД. Например, в 2021 году на решения российских разработчиков приходилось около 55 контрактов, а в прошлом году их число составляло уже более 200. Переход на Postgres Pro стал своеобразным «трендом-2022». Но и в 2023 компании нередко обращаются к ИТ-специалистам для миграции баз данных из СУБД Oracle или MSSQL в Postgres Pro. Поэтому вопрос актуальный.
Необходимо отметить, что государственные компании всегда используют в качестве целевой СУБД для миграции именно Postgres Pro, а не свободно-распространяемый PostgreSQL. Причина этого кроется в том, что только Postgres Pro входит в реестр российского ПО для импортозамещения. Также немаловажную роль играет наличие технической поддержки для Postgres Pro.
Что значит «миграция в Postgres Pro»
Под миграцией в Postgres Pro нужно понимать процесс переноса информации из одной СУБД в другую. Этот процесс можно выполнять с помощью средств автоматизации или вручную. Выбор конкретного метода зависит от многих факторов. К примеру, реализовать автоматизированную миграцию будет очень непросто, если связь с разработчиком исходной БД утеряна, а соответствующей документации нет.
Кроме того, даже автоматизированная миграция зачастую подразумевает значительный объем ручной работы в тех местах, где автоматизированные средства не могут обеспечить правильный перенос.
Говорить о миграции данных нельзя в отрыве от приложений, использующих эти данные, включая хранимые процедуры, ETL и системы отчетности. Смена СУБД может приводить к необходимости значительных изменений в приложениях.
Кроме того, даже автоматизированная миграция зачастую подразумевает значительный объем ручной работы в тех местах, где автоматизированные средства не могут обеспечить правильный перенос.
Говорить о миграции данных нельзя в отрыве от приложений, использующих эти данные, включая хранимые процедуры, ETL и системы отчетности. Смена СУБД может приводить к необходимости значительных изменений в приложениях.
Особенности миграции Oracle в Postgres
Перенос данных из Oracle в Postgres можно выполнить двумя способами:
Реализовав ту же логику, что на Postgres
БД Oracle останется, со стороны приложения придется заменить запросы к новой базе данных. В таком подходе важно перенести функционал из СУБД-исходник на Postgres, после чего провести тесты для верификации результатов. После завершения миграции в приложении нужно также провести нагрузочный тест. Способ позволяет переехать быстро и с минимальными трудозатратами.
БД Oracle останется, со стороны приложения придется заменить запросы к новой базе данных. В таком подходе важно перенести функционал из СУБД-исходник на Postgres, после чего провести тесты для верификации результатов. После завершения миграции в приложении нужно также провести нагрузочный тест. Способ позволяет переехать быстро и с минимальными трудозатратами.
Полностью «выпилить» логику Oracle
При таком подходе логика максимально переносится в новое приложение. Придется переписывать код. В результате в Oracle останется только БД, которая будет полностью заменена Postgres. Метод более долгий, но и более прозрачный в плане работы с системой.
При таком подходе логика максимально переносится в новое приложение. Придется переписывать код. В результате в Oracle останется только БД, которая будет полностью заменена Postgres. Метод более долгий, но и более прозрачный в плане работы с системой.
Особенности миграции с MySQL на Postgres Pro
Если, к примеру, речь идет о миграции с MySQL на Postgres Pro, то предсказать, какое из решений будет более оптимальным, нереально. Ведь IT-решения все время развиваются, в них появляются принципиально новые функции, расширяются прежние возможности.
А если в качестве примера рассматривать Zabbix миграцию с MySQL на Postgres Pro, среднестатистический пользователь не заметит никакой разницы между этими решениями. Ведь в плане производительности нет отличий, улучшение по типу использования transaction log и buffer понадобится в обеих случаях.
Кроме того, партицирование для MySQL гораздо проще, но в то же время Postgres Pro имеет поддержку foreign key, в отличие от первой, а при высоком IO Postgres Pro показывает себя немного стабильнее.
Поэтому перед переносом данных нужно четко определить цели и провести сравнительный анализ текущей СУБД с Postgres Pro.
А если в качестве примера рассматривать Zabbix миграцию с MySQL на Postgres Pro, среднестатистический пользователь не заметит никакой разницы между этими решениями. Ведь в плане производительности нет отличий, улучшение по типу использования transaction log и buffer понадобится в обеих случаях.
Кроме того, партицирование для MySQL гораздо проще, но в то же время Postgres Pro имеет поддержку foreign key, в отличие от первой, а при высоком IO Postgres Pro показывает себя немного стабильнее.
Поэтому перед переносом данных нужно четко определить цели и провести сравнительный анализ текущей СУБД с Postgres Pro.
Особенности миграции данных из MS SQL в Postgres Pro
Можно выделить 6 нюансов миграции данных из MS SQL в Postgres Pro:
- В синтаксисе SQL есть различия между Postgres Pro и MS SQL. Определенные запросы в MS SQL не будут выполняться в Postgres Pro (будут требовать изменений).
- Не все компоненты и функциональные возможности MS SQL будут иметь точные аналоги в Postgres Pro. К примеру, процедуры/функции MS SQL уникальны для исходной СУБД — без изменений они не могут быть перенесены на Postgres Pro.
- У Postgres Pro большая расширяемость, открытость и гибкость, чем у с MS SQL. Поэтому потребуется больше ресурсов как для настройки, так и для изучения новых возможностей.
- Postgres Pro является регистро-зависимым в отличии от MS SQL, в том числе по отношению к именам объектов (таблиц, ХП и т. д.). Это приводит к необходимости нормализации имен всех объектов БД. У Postgres Pro нет поддержки .NET в качестве расширения, в отличии от MS SQL. Таким образом, все .NET функции, используемые в MSSQL, необходимо будет переписать с использованием других языков, поддерживаемых Postgres Pro.
- Postgres Pro и MS SQL используют разные алгоритмы округления и преобразования данных, что приводит к появлению различий в результатах выполнения одинаковых операций на MS SQL и Postgres Pro.
- Postgres Pro использует механизм версий для обеспечения совместного выполнения запросов, в отличии от MS SQL, который использует блокировки. Это кардинально разные подходы, которые приводят к существенным различиям в выполнении запросов. В худшем случае невозможно обеспечить хорошую производительность мигрированный хранимой процедуры без полного переделывания принципов ее работы.
Как начать миграцию баз данных Postgres Pro
Первым делом нужно разработать стратегию переезда на Postgres Pro:
Все это позволит избежать ошибок, которые позже придется устранять (а это может затянуться на длительное время).
Затем нужно определить состав группы, в которую обязательно должны входить 2 категории экспертов — которые прекрасно знакомы с тонкостями исходной СУБД, и которые идеально понимают работу целевой СУБД.
Также стоит отдельно выбрать специалистов для анализа. Даже если выполняется автоматическая миграция данных Postgres Pro, эти эксперты обеспечат наивысшую степень эффективности и прозрачности процесса.
На следующем шаге нужно составить план. Что он обязательно должен включать объем данных, которые нужно перенести, даты, когда данные были загружены из системы, даты тестов и результатов переноса информации и объемы данных, полученные в рамках тестовой миграции.
В процессе выполнения работ план будет корректироваться и меняться при необходимости.
Также важно четко определить состав данных, подлежащих переносу на Postgres Pro. То есть, что конкретно будет переноситься, а какая информация являются устаревшей и может быть исключена.
На предпоследнем подготовительном этапе нужно определить ключевые методы и параметры проверки эффективности переноса. То есть то, что должно получится в конечном итоге:
На последнем этапе необходимо предусмотреть методы отката после миграции данных Postgres Pro — определить инструменты возврата БД к первоначальному состоянию, если в процессе переноса возникнут сбои или ошибки.
- Выбрать технологии для проведения всех необходимых работ.
- Составить список правил предоставления доступа участникам миграционного проекта.
- Распределить обязанности и убедиться, что все участники хорошо их понимают.
- Разработать план проведения тестов системы после завершения миграции.
Все это позволит избежать ошибок, которые позже придется устранять (а это может затянуться на длительное время).
Затем нужно определить состав группы, в которую обязательно должны входить 2 категории экспертов — которые прекрасно знакомы с тонкостями исходной СУБД, и которые идеально понимают работу целевой СУБД.
Также стоит отдельно выбрать специалистов для анализа. Даже если выполняется автоматическая миграция данных Postgres Pro, эти эксперты обеспечат наивысшую степень эффективности и прозрачности процесса.
На следующем шаге нужно составить план. Что он обязательно должен включать объем данных, которые нужно перенести, даты, когда данные были загружены из системы, даты тестов и результатов переноса информации и объемы данных, полученные в рамках тестовой миграции.
В процессе выполнения работ план будет корректироваться и меняться при необходимости.
Также важно четко определить состав данных, подлежащих переносу на Postgres Pro. То есть, что конкретно будет переноситься, а какая информация являются устаревшей и может быть исключена.
На предпоследнем подготовительном этапе нужно определить ключевые методы и параметры проверки эффективности переноса. То есть то, что должно получится в конечном итоге:
- корректность
- достоверность
- отсутствие беспричинных дублей
- согласованность
На последнем этапе необходимо предусмотреть методы отката после миграции данных Postgres Pro — определить инструменты возврата БД к первоначальному состоянию, если в процессе переноса возникнут сбои или ошибки.
Технологическая часть миграции данных Postgres Pro
В эту часть входят работы по подготовке инструментов выгрузки и проверки данных. Технологическую реализацию миграции можно разделить на 6 этапов.
Подготовка шаблона и методов загрузки данных
Шаблон должен включать точные описания:
- полей данных, подлежащих выгрузке
- правил выгрузки таблицы конечной СУБД на основе загруженных данных
- полей таблиц конечной системы
Определение источников информации
Определение тех систем, из которых информацию нужно выгрузить, а также определение источников, которые потенциально могут понадобиться при миграции на Postgres Pro. В ходе выполнения работ источники информации будут вносится в уже составленный список. Но все же лучше заранее максимально тщательно и внимательно их продумать.
Выгрузка исходных данных
По времени этот процесс наиболее длительный — все зависит от объема БД. В плане важно заранее определить объемы тестовых загрузков, чтобы потом не получить гигабайты некачественных данных и ошибки.
Data mapping (сопоставление данных)
Процедура проверки информации — ее сверки с той, что уже загружена. В ходе миграции баз данных Postgres Pro эта процедура может отнять до 50% времени от всей работы. В процессе выполнения data mapping проводится сверка полей и таблиц. На этих подэтапах выполняют действия для нормализации данных.
Трансформация данных
Взяв за основу согласованные реестры мэппинга полей, эксперты должны разработать скрипты (правила) трансформации данных. После этого поэтапно проводится:
На этих этапах проводится обязательное тестирование целостности данных и их итоговая проверка после переезда на Postgres Pro. Результаты тестов позволят обнаружить ошибки и оценить качество данных, которые были загружены в целевую СУБД.
- Выгрузка данных из исходной СУБД.
- Их трансформация.
- Загрузка данных в целевую СУБД.
На этих этапах проводится обязательное тестирование целостности данных и их итоговая проверка после переезда на Postgres Pro. Результаты тестов позволят обнаружить ошибки и оценить качество данных, которые были загружены в целевую СУБД.
Проверка данных
Вообще, проверка данных в процессе миграции баз данных Postgres Pro должна выполняться и после тестов, и в процессе нормализации, и после итоговой миграций.
Инструменты для миграции Postgres Pro
В рамках миграции данных из MS SQL в Postgres Pro чаще всего используется pgloader (http://pgloader.io/). С помощью этого инструмента можно перенести информацию из MS SQL в Postgres Pro путем преобразования структуры таблиц.
Чтобы использовать инструмент, нужно установить его на оба сервера — и с MS, и с PostgresSQL. После этого необходимо настроить файл конфигурации. Вот пример его настройки:
load from mssql://user:password@host/database
into Postgres Pro://user:password@host/database
with include drop, create tables, no truncate,
set work_mem to '16MB',
set maintenance_work_mem to '512 MB',
before load do
$$create schema if not exists legacy;$$,
ignore errors;
Конфигурационный файл указывает на выгрузку данных из MS SQL и их последующую загрузку в Postgres Pro с сохранением настроек схем и таблиц.
Кроме рассматриваемого инструмента существуют альтернативы по типу SQLines SQL Converter и SSMA (SQL Server Migration Assistant). Они имеют свои нюансы и разные методы обработки данных, поэтому перед тем, как выбрать конкретный инструмент, нужно тщательно проанализировать требования к миграции, а еще лучше — протестировать различные решения.
К сожалению, все озвученные инструменты хорошо обеспечивают только перенос данных. С точки зрения переноса хранимый процедур, функций и триггеров эти приложения не могут обеспечить отличного качества. В зависимости от ситуации, перенесенные объекты могут потребовать значительной ручной коррекции даже с точки зрения обеспечения той же функциональности, не говоря уже о производительности.
Чтобы использовать инструмент, нужно установить его на оба сервера — и с MS, и с PostgresSQL. После этого необходимо настроить файл конфигурации. Вот пример его настройки:
load from mssql://user:password@host/database
into Postgres Pro://user:password@host/database
with include drop, create tables, no truncate,
set work_mem to '16MB',
set maintenance_work_mem to '512 MB',
before load do
$$create schema if not exists legacy;$$,
ignore errors;
Конфигурационный файл указывает на выгрузку данных из MS SQL и их последующую загрузку в Postgres Pro с сохранением настроек схем и таблиц.
Кроме рассматриваемого инструмента существуют альтернативы по типу SQLines SQL Converter и SSMA (SQL Server Migration Assistant). Они имеют свои нюансы и разные методы обработки данных, поэтому перед тем, как выбрать конкретный инструмент, нужно тщательно проанализировать требования к миграции, а еще лучше — протестировать различные решения.
К сожалению, все озвученные инструменты хорошо обеспечивают только перенос данных. С точки зрения переноса хранимый процедур, функций и триггеров эти приложения не могут обеспечить отличного качества. В зависимости от ситуации, перенесенные объекты могут потребовать значительной ручной коррекции даже с точки зрения обеспечения той же функциональности, не говоря уже о производительности.
EMS Data Pump for Postgres Pro
Этот инструмент подходит как для миграции данных из MS SQL в Postgres Pro, так и для миграции с MySQL на Postgres Pro или перемещения БД с прочих СУБД. EMS Data Pump способен конвертировать и импортировать информацию из таблиц всех современных ADO-совместимых источников — MS Access, MySQL, MS SQL и прочих СУБД поставщиком OLE DB.
Особенности и возможности EMS Data Pump for Postgres Pro:
Независимо от СУБД и конкретного инструмента для миграции, перед началом процедуры обязательно создается полный бэкап БД. Чтобы в случае сбоя или возникновения можно было оперативно восстановить утерянные данные.
Если пренебрегать подготовкой, аккуратностью и безопасностью в процессе переезда на Postgres Pro, результатом будут не только ошибки, но и потеря данных. А в случае с любым бизнесом, утрата информации может привести к серьезным убыткам.
Особенности и возможности EMS Data Pump for Postgres Pro:
- Может импортировать информацию в Postgres Pro из множества хранилищ данных. Начиная от простых текстовых файлов и заканчивая комплексными решениями по типу IBM DB2, SQL Server, Oracle и т. д.
- Позволяет подключиться к удаленному серверу по HTTP или SSH, имеет мультиязычный интерфейс, который можно настроить максимально «под себя» (в том числе и в плане внешнего вида).
- Интерфейс инструмента реализован в виде удобного мастера, который пошагово проводит специалиста по всему пути миграции — от импорта до экспорта.
- В процессе работы с инструментом можно создать строку подключения к ADO-источнику, выбрать для переноса конкретные индексы, таблицы, поля, задать ограничения для конвертирования и вообще — выполнить максимально тонкую настройку процесса миграции.
- В комплекте с ПО идет утилита командной строки, которая вместе с предварительными настройками позволяет автоматизировать процессе переноса.
Независимо от СУБД и конкретного инструмента для миграции, перед началом процедуры обязательно создается полный бэкап БД. Чтобы в случае сбоя или возникновения можно было оперативно восстановить утерянные данные.
Если пренебрегать подготовкой, аккуратностью и безопасностью в процессе переезда на Postgres Pro, результатом будут не только ошибки, но и потеря данных. А в случае с любым бизнесом, утрата информации может привести к серьезным убыткам.
Автор статьи
- Андрей ИнюшинДиректор по управлению проектами ITentikaЭксперт по разработке миграций (импортозамещению) решений на основе реляционных баз и хранилищ данных
Другие новости