«Если ли жизнь» после Oracle – импортозамещение баз данных

Введение

В настоящий момент в российских компаниях остро стоит задача импортозамещения СУБД – перехода с зарубежных систем управления базами данных (в основном это Oracle Database и MS SQL Server) на отечественные СУБД.

На этот счет можно услышать разные мнения: начиная от того, что миграция с СУБД Oracle Database на другую невозможна и требует полного редизайна приложений, так и до того что в бизнес-приложениях, СУБД одного вендора можно легко заменить на другую.

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

В данной статье хотелось бы поделиться опытом компании «ЗащитаИнфоТранс» накопленным в проектах по миграции баз данных. Особо хотелось бы сделать акцент на этапах проекта по миграции и переосмыслении архитектуры приложения при миграции - это очень важные моменты, которые нужно заранее проработать перед началом проекта миграции СУБД.

Выбор целевой СУБД при миграции

Хотелось бы отметить, что в дальнейшем, в качестве целевой СУБД при миграции будет рассматриваться только СУБД Postgres Pro.

Postgres Pro - СУБД российского происхождения, построенная на основе опенсорсной PostgreSQL. Разработана компанией Postgres Professional. СУБД выпускается в нескольких редакциях:

• Postgres Pro Standard
• Postgres Pro Enterprise
• Postgres Pro Enterprise Certified
• Postgres Pro Certified

СУБД входит в реестр российского ПО, а сертифицированные версии имеют сертификаты ФСТЭК.

СУБД Postgres Pro Enterprise позиционируется компанией-разработчиком как СУБД с широкими функциональными возможностями, высокой производительностью и масштабируемостью.

Особенностью СУБД Postgres Pro в отличие от других продуктов, представленных на российском рынке, является наличие встроенных технологий упрощающих миграцию с СУБД Oracle: поддержка пакетов, поддержка сжатия таблиц и индексов, автономных транзакций, дополнительных встроенных системных пакетов – аналогов системных пакетов из Oracle, утилита автоматической конвертации кода хранимых процедур из Oracle в синтаксис Postgres Pro и т.д.

По нашему опыту, СУБД Postgres Pro является наилучшим выбором при миграции, когда речь идет о крупных корпоративных системах построенных на основе СУБД Oracle Database.

Рис. 1 Этапы проекта по миграции

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

Рассмотрим более подробно этапы проекта по миграции.

Этап №1 – выбор приложения при миграции

Первым, очевидным этапом, является выбор приложения для миграции.

В любой организации, особенно крупной, эксплуатируется не одна, а множество баз данных. В крупной организации речь может идти о сотнях и даже тысячах БД. Как правило, небольшая часть из них обслуживает так называемые mission-critical приложения – системы, от которых напрямую зависит бизнес-компании. Такие БД как правило имеют большой объем и работают под большой нагрузкой.

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

1. Рекомендуется для первого проекта по миграции СУБД выбирать именно БД для приложений второго типа. Это позволяет получить массу преимуществ:

• отработать технологии миграции;
• приобрести опыт эксплуатации новой СУБД;
• на такой проект не потребуется привлечение большого количества ресурсов.

После выполнения миграции первой БД, далее следует приступать к более сложным приложениям и более нагруженным БД.

Этап №2 – миграция метаданных

На данном этапе происходит миграция метаданных: определения объектов БД (таблиц, индексов, ограничений целостности и т.д.) мигрируют из Oracle в СУБД Postgres Pro.

Этот этап хорошо автоматизирован - на рынке имеется много утилит для решения этой задачи.

Очень хорошо показала себя open-source утилита с говорящим названием ora2pg. Утилита ora2pg подключается к исходной СУБД Oracle и считывает метаданные из словаря СУБД (Oracle Dictionary), на выходе утилита формирует SQL-скрипты создание таблиц, индексов, ограничений целостности и т.д. в синтаксисе Postgres Pro (он отличается от синтаксиса создания объектов в СУБД Oracle).

Выполнив полученные SQL-скрипты в СУБД Postgres Pro, мы получим БД идентичную по структуре исходной БД в Oracle, но пока без данных.

Рис. 2 Принцип работы утилиты ora2pg

Этап №3 – миграция данных

На данном этапе производится миграции самих данных из СУБД Oracle в Postgres Pro. Поскольку файлы данных этих двух СУБД имеют совершенно разные двоичные форматы, прямое их копирование невозможно.

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

Если объем БД не превышает 1-2 ТБ и допустимый downtime составляет 2 суток (выходные дни), то для переноса данных можно использовать штатные возможности вышеупомянутой утилиты ora2pg.

В ora2pg есть два способа миграции данных: экспорт-импорт через выгружаемые текстовые файлы и прямое копирование данных из СУБД Oracle в Postrges Pro через сетевые соединения.

В первом способе cначала происходит выгрузка информации (экспорт) из СУБД Oracle в текстовые файлы на диск (фактически представляют собой SQL-скрипты с командой пакетной вставки в СУБД Postgres Pro). Затем происходит импорт текстовых файлов в СУБД Postgres Pro (фактически выполнение SQL-скрипта в СУБД PG Pro). Для миграции данных c помощью экспорта-импорта требуется наличие дополнительного дискового пространства для хранения промежуточных текстовых файлов. Также возникают дополнительные накладные временные расходы на запись и чтение файлов дампа.

Вышеперечисленных недостатков лишен второй способ миграции данных утилиты ora2pg: прямая “переливка” данных из Oracle в PG Pro через сеть. При запуске в режиме миграции данных, утилита ora2pg устанавливает сетевое соединение с исходной БД Oracle и с целевой БД Postgres Pro, затем читает данные из Oracle и сразу же записывает их в Postgres Pro.

Если объем исходной БД Oracle превышает 2ТБ или допустимое время простоя приложения для переключения на новую БД измеряется в часах, то следует применять другие технологии.

Для этих целей, как правило, применяются технологии логической репликации. В этом случае миграция данных происходит в два этапа: на первом этапе происходит начальное копирование данных из Oracle в Postgres Pro, при этом приложение продолжает работать и вносить изменения в данные в СУБД Oracle; на втором этапе - изменения, которые произошли в БД Oracle за время пока происходило начальное копирование, реплицируются в СУБД PostgreSQL.

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

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

Этап №4 – миграция кода приложения

Как правило, это самый сложный и трудоемкий этап в проектах по миграции.

Здесь многое зависит от архитектуры приложения. Если БД представляет собой большую монолитную базу данных с логикой реализованной на стороне БД в виде пакетов хранимых процедур PL/SQL, то возможны два варианта.

Первый вариант заключается в выносе бизнес-логики на уровень серверов приложений, например, на основе языка программирования Java.

Этот способ обеспечит масштабирование системы при увеличении нагрузки, однако потребуется полностью переписать логику приложения с Oracle PL/SQL на Java. Данный вариант самый трудозатратный по реализации, особенно если код состоит из сотен тысяч и миллионов строк кода на PL/SQL.

Второй вариант предполагает неизменность архитектуры приложения, то есть после миграции, тоже остается монолитная БД, но уже на основе Postgres Pro. В этом случае логика приложения также остается в БД - конвертируется из Oracle PL/SQL в язык хранимых процедур Postgres Pro PL/pgSQL. Компания Postgres Professional предоставляет автоматический конвертор кода из PL/SQL в PL/pgSQL. Однако, все равно потребуется верификация и ручная корректировка кода с дальнейшим тестированием, поскольку полностью автоматическая конвертация кода невозможна, из-за отличия в обработке строковых значений, правил обработки транзакций и исключений в хранимых процедурах PostgreSQL и т.д.

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

Следует отметить, что если размер БД превышает 20-30 ТБ, то следует расcмотреть вопрос разделения такой БД не несколько относительно небольших по размеру БД.

Рис. 3 Монолитная БД с бизнес-логикой на стороне сервера БД

Дело в том, что СУБД Oracle разрабатывалась и десятилетиями оптимизировалась для обеспечения эффективной работы больших монолитных БД. Для работы таких БД используются большие многопроцессорные серверы класса Hi-End (4 и более ЦПУ). СУБД Oracle хорошо оптимизирована для работы на таких больших серверах, и имеет в своем составе много технологий для поддержки большого числа процессоров и больших объемов оперативной памяти, например: Oracle Automatic Storage Management, Oracle Database In-memory, Oracle Result Cache, Oracle PL/SQL Native Compilation и т.д.

Если говорить о СУБД PostgreSQL, то эта СУБД исторически развивалась для небольших open-source проектов и не содержит в себе небольшое количество технологий для поддержки больших и нагруженных баз данных. Наш опыт показывает, что она не очень подходит для больших монолитных БД объемом более 20ТБ и работающих под высокой нагрузкой.

Справедливости ради стоит сказать, что если БД небольшая по размеру и не содержит в себе большого объема бизнес-логики, то СУБД PostgreSQL почти наверняка будет работать с сопоставимой производительностью как в СУБД Oracle.

Если же БД используется только как механизм хранения (Persistent Store), без бизнес-логики внутри БД, то PostgreSQL будет идеальным выбором, поскольку представляет легкую и компактную систему управления базами данных не отягощенную лишним функционалом.

Для разделения БД используется два основных способа: по прикладному признаку, когда БД разбивается на части в соответствии с прикладным модулем к которому относятся эти данные (классический пример - микросервисная архитектура) и шардинг. Шардинг — это деление больших таблиц на отдельные небольшие таблицы по ключу шардинга (sharding key), при этом эти небольшие таблицы находятся в отдельных независимых БД (шардах).

Рис. 4 Разделение БД по прикладному признаку

Приложение при этом работает с такой СУБД как с единой логической БД.

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

Также в ходе миграция кода следует обратить внимание на перечень технологий, которые использует приложениее в СУБД Oracle, поскольку реализация этих же технологий в СУБД PostgreSQL может иметь особенности, которые необходимо учитывать. Например: если в СУБД Oracle используется технология сжатия Oracle Compression, то в СУБД Postgres Pro есть аналогичная технология сжатия Compressed File System и здесь проблем при миграции не возникает. Если же, например, в СУБД Oracle используется автоматическое создание секцией по списку значений (Oracle Autolist Partitiong), то в СУБД Postgres Pro такая технология отсутствует и потребуется реализовать создание секций на уровне приложения.

Рис. 5 Разделение БД на шарды (shard)

Некоторые технологии вообще отсутствует в Postgres Pro и необходимо принять решение об их замене. Например, в СУБД Postgres Pro отсутствует технология кэширования данных в памяти в колоночном формате Oracle Database In-Memory.

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

Этап №5 – тестирование

После миграции БД и приложения на использование Postgres Pro необходимо провести всестороннее и тщательно тестирование.

Этап тестирования делится на два больших подэтапа: функциональное тестирование и нагрузочное тестирование.

В ходе функционального тестирования проверяется (тестируется) функциональность приложения после миграции: выполняется тесты на правильность работы приложения в среде Postgres Pro. Рекомендуется проводить сравнение результатов функциональных тестов в СУБД PostgreSQL с результатами их выполнения в исходной СУБД Oracle. Функциональное тестирование позволяет убедиться, что приложение в СУБД Postgres Pro работает корректно, и его функционал полностью соответствует исходной БД Oracle.

В ходе нагрузочного тестирования происходит запуск нагрузочных тестов в СУБД Postgres Pro, а затем производится сравнение полученных метрик производительности с исходной СУБД Oracle.

На этапе тестирования также строится и проверяется архитектура доступности БД для защиты от потерь данных: устанавливается и настраивается резервный сервер БД для защиты от катастроф, разрабатываются и настраиваются процедуры резервного копирования и восстановления БД. Необходимо отметить, что СУБД Postgres Pro имеет все необходимые для этого технологии: потоковая репликация (аналог технологии Oracle Dataguard), утилиту резервного копирования pg_probackup (аналог Oracle Recovery Manager) и т.д.

Этап №6 – переход в промышленную эксплуатацию

Перед переходом в промышленную эксплуатацию следует убедиться про проработаны и решены задачи мониторинга СУБД.

Для решения этой задачи на рынке есть как коммерческие так и бесплатные open-source продукты. Компанией Postges Pro в составе своей СУБД поставляется графическая консоль администрирования Postgres Pro Enterprise Manager. По своему функционалу и даже по внешнему виду от очень похож на Oracle Enterprise Manager, продукт который используют для мониторинга работоспособности и производительности СУБД Oracle.

Итак, в назначенные день и час происходит останов СУБД Oracle и переключение пользователей на работу с СУБД Postgres Pro.

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

Этап №7 – сопровождение

На данном этапе СУБД Postgres Pro входит в основную стадию своего жизненного цикла: проводится ежедневный мониторинг производительности, выполняются штатные процедуры резервного копирования и периодическая установка пакетов обновлений (для СУБД Postges Pro они выпускаются каждый квартал).

Заключение

Отвечая на вопрос поставленный в заголовке статьи, можно с уверенностью сказать, что миграция с Oracle вполне возможна. Да, конечно, СУБД – это важная часть инфраструктуры, и замена СУБД является сложной инженерной задачей.

Тем не менее, при четком выполнении всех этапов проекта по миграции, с учетом переосмысления архитектуры приложений (переход от крупных монолитных систем к микросервисной архитектуре или шардингу БД), проект по миграции с СУБД Oracle будет успешным!

Тем более, что производитель СУБД и сообщество поставляют много инструментов для автоматизации миграции и уменьшения затрат на работы при ее проведении.