С этого сообщения в мессенджере началось мое масштабное расследование вопроса, который давно не дает спать многим айтишникам — можно ли вот так взять и переехать с Oracle на «свободную» СУБД PostgreSQL?
Этот вопрос сначала бередил умы только тех, кто был в курсе стоимости закупок лицензий. В крупных компаниях бюджет на это мог составлять несколько десятков миллионов долларов. А потом каждый год поддержка вендора «съедала» ещё 22% от стоимости лицензий. Теперь та финансовая боль сменилась другой, и у компаний поменялся запрос: а можно ли заменить? И главное, можно ли организовать это в разумные сроки и по адекватной стоимости?
Скажу сразу, что в этом посте не будет технических аспектов миграции с СУБД Oracle на PostgreSQL. Как это делать и как обходить сложности — разберем в следующий раз. Тут же больше поговорим о целесообразности и возможности миграции. С этим мы разбирались в ходе одного проекта, а заодно развенчали строй существующих иллюзий.
Иллюзия 1. Сейчас быстро сделаем стенд и всё поймем
Есть мнение: «Чтобы узнать, как система «живет» на PostgreSQL, нужно просто попробовать». Наш заказчик с огромной ИТ-инфраструктурой решил выяснить, насколько возможна замена Oracle и MS SQL на свободную СУБД, посчитать затраты на переход и выгоду от этого. У него насчитывалось около 1500 баз данных. Стендирование такого количества систем само по себе — огромный труд и большие затраты. Поэтому мы изобрели собственную поэтапную методологию отбора БД для миграции.
Сначала актуализировали список БД, которые имеет смысл мигрировать. Из стартового списка из 1500 БД мы убрали системы на Standard Edition — стоимость софта и его поддержки небольшая, а миграция оказалась бы дороже возможной выгоды. На выходе из этого фильтра осталось 800 БД. Потом мы посмотрели системы и отсеяли те из них, которые шли «под списание» и вывод из эксплуатации. Осталось 400 БД. Затем убрали системы, принципиально не поддерживающие PostgreSQL. На этом этапе отвалилось большое число коробочных продуктов сторонних производителей. В итоге у нас осталось 90 потенциальных кандидатов «на переезд».
И вот тут мы пошли вглубь: получили доступы к БД-кандидатам и начали их всестороннее исследование. Анализировали содержимое базы данных, хранимый код и внешние процедуры. Исследовали приходящие извне запросы, интеграции со смежными системами и работающие с БД модули. При этом использовали как сторонние утилиты (ora2pg, Ispirer), так и набор собственных скриптов, парсеров и запросов. В относительно крупной базе легко могло быть 2000-5000 уникальных клиентов и 40-50 разных модулей, у части которых, как водится, давно потеряны «исходники»☺ Когда мы показывали владельцам системы и разработчикам список подключений, их глаза округлялись от удивления.
Уже с результатами анализа БД по интеграциям с другими ИС, размерам хранимого кода и числу модулей мы шли к разработчикам заказчика. Показывали им свои открытия и обозначали сложности, которые могли возникнуть в миграции, и каких изменений это потребует. Если они говорили: «Ок, в принципе мы можем адаптировать эту ИС под PostgreSQL за два месяца», то такая система шла в шорт-лист миграции. Или коллеги сразу признавались, что идея невероятная, так как они много лет создают систему под Oracle, и уйдут годы на ее переделку под другую СУБД. С внешними командами разработки было то же самое, только на выходе мы еще получали от них ориентировочную стоимость переделки ИС под PostgreSQL.
У владельцев систем выясняли, есть ли готовая методика функционального и нагрузочного тестирования, оценивали его трудоемкость и необходимые ресурсы.
В итоге, собрав воедино результаты собственных исследований и оценок разработчиков, мы определили возможность, трудоемкость и целесообразность миграции.
Этот занудный этап занял четыре месяца. Быстро, с наскока, такие вещи не делаются.
Иллюзия 2. Подумаешь, все БД плюс-минус одинаковы
Ну да, в каждой из них таблицы, индексы. А еще функции, view, последовательности. Немного отличаются типы и синтаксис. Различия не так важны, если писать новое приложение и выбирать под него СУБД. Когда же речь идет о миграции существующего, то нюансы превращаются в пропасти.
Некоторые проблемы совместимости лежат на поверхности. Например, различия в типах данных, другой синтаксис работы с последовательностями. В PostgreSQL нет функции sysdate и понятия ROWID, эта СУБД не знает, что такое ROWNUM, отсутствуют синонимы. Кстати, о синонимах. Вместо них Рostgres предлагает использовать представления (view). Но в Oracle синоним бывает не только на таблицу, но и на процедуру, функцию, последовательность, пользовательский тип и т. д. И в крупной оракловой системе это используется широко. В общем, список отличий — на 100 страниц мелким шрифтом.
Есть проблемы, которые неочевидны без знания обеих СУБД. Например, в PostgreSQL пустая строка — это пустая строка, а null — это null. В Oracle же пустая строка сама превращается в null, и при работе одинаковых запросов в Oracle и в PostgreSQL возможны веселые спецэффекты. И самое неприятное, что при этом даже не будет выдана ошибка: запросы работают, но возвращают чертовщину.
Или взять работу с транзакциями. Oracle автоматически начинает транзакцию на любое действие, PostgreSQL на это нужно специальное указание. Представьте, что Oracle делает select for update, например, при разборе очереди платежей. Он знает, что эти данные он заблокировал, и никто другой с ними работать не сможет. PostgreSQL же как поставил блокировку, так сразу и снял: приходи и делай, что хочешь. И тут уже как повезет. Никаких сообщений об ошибках по-прежнему не будет, а данные могут быть искажены двойной обработкой.
Я привел несколько примеров. В реальности различия в СУБД нагромождаются друг на друга и сильно усложняют адаптацию приложения. И «масштаб бедствия» хочется узнать при обследовании информационной системы и всей её обвязки, а не когда уже собран стенд из пары БД, десятка серверов приложений и «прикручен» LDAP.
Иллюзия 3. Есть куча инструментов, которые возьмут миграцию на себя
Средств миграции немало. Какие-то даже обещают чуть ли не автоматическую миграцию на Postgres. Но к их возможностям много претензий.
Одна из самых известных утилит для миграции с Oracle на PostgreSQL — это ora2pg. Она думает, что БД состоит из таблиц, индексов, представлений и хранимого кода. Утилита честно посчитает количество этих сущностей и выдаст оценку сложности миграции. Для простых систем эта оценка окажется похожа на правду.
Но в реальном мире база Oracle — это не только данные и хранимый код. Это и обращение к специфичным DBA_-, ALL_-представлениям, а часто к V$ и даже к X$-VIEW. Это вызов множества специфичных для Oracle DBMS_-пакетов, работа с XML и OLAP, общение с внешними сервисами через UTL_HTTP и рассылка почты через UTL_MAIL. Это внешние библиотеки и работа с очередями. В Oracle бывают зашифрованные (wrapped) пакеты. И много чего еще.
Всего этого ora2pg «не замечает». Утилита посчитает количество строк хранимого кода PL/SQL и предложит автоматически конвертировать его в PG/SQL. Звучит неплохо, да? Здесь вспоминается один кейс.
Однажды в проекте по разделению двух схем в Oracle мы столкнулись с тем, что пакеты одной схемы вызывают пакеты из другой схемы, которые в свою очередь снова вызывают пакеты из первой, и так по кругу. И всё это делалось через уже упомянутые синонимы. Мы построили дерево зависимостей и оцепенели от ужаса… Его высота составила 42 уровня! На распутывание этого клубка у нас ушла уйма времени. Как вы думаете, ora2pg сделает это автоматически сама?
Опять же, утилита смотрит только «внутрь» БД и не в состоянии определить, сколько специфичных штук вызывается извне. Так что надеяться на инструменты миграции можно только в случае с простыми БД. Но, как правило, для них Oracle изначально не нужен.
Иллюзия 4. Организация миграции — ничто по сравнению с технической стороной
Скорее наоборот. Представьте, что АБС в час Х мигрирует на PostgreSQL. Подготовка к миграции БД обычно захватывает огромные пласты ИТ-инфраструктуры. И она — подготовка — никогда не бывает излишней.
История из другого проекта, но она здесь кстати. Как-то в крупном банке нам нужно было консолидировать несколько десятков БД Oracle различных систем на новых кластерах СУБД. Системы были исторические, и у каждой из них накопилось множество запутанных взаимосвязей. И речь не только о подключении приложения к БД. Были связи с разными системами, реализованные через DB-линки или вообще через прямые обращения к базе откуда-то снаружи, которые, конечно же, не были задокументированы.
Чтобы найти и перенастроить первые, пришлось повозиться с конфигурациями каждого исходного сервера БД. А вот обнаружить вторые можно только разбирая все обращения к БД. Для этого мы использовали собственный парсер логов, выявляли каждый уникальный хост и модуль. В итоге обнаружилось около 2 000 уникальных клиентов базы и порядка 35 различных модулей. А чтобы получилось перенастроить всё это за два часа окна миграции, нам понадобилось два месяца подготовки.
Иллюзия 5. Главное, пережить саму миграцию
Это так, если мигрирует простая система. В случае переезда сложной ИС никто не открывает шампанское. Почему? При миграции сложной системы не всегда можно собрать полноценное тестовое окружение со всеми интеграциями, поэтому тестируется только основной функционал, а остальное идет в технический долг. Проработка второстепенного функционала остается на потом.
И здесь наступает не менее тяжелое время. Сначала система приводится в работоспособное состояние, а потом до полугода или больше длится стабилизация, когда восстанавливается 100% функционала и производительности. Например, мигрировали систему, отвечающую за оформление бонусных карт. После переноса ее завели, карты выпускаются, но аналитические отчеты работают не в полном объеме.
Как иллюстрация сложностей постмиграционного периода вспоминается кейс из жизни одной нефтяной компании. В этом примере начало было многообещающим — компания перевозила 1С с MicrosoftSQL на PostgreSQL. 1С поддерживает PostgreSQL «из коробки», трудностей не предвиделось, поэтому на проект компания заложила пару недель.
При миграции не нужно было пользоваться дополнительными инструментами, 1С умеет делать это сам. У платформы есть специализированная процедура: 1С выгружает данные в формат PostgreSQL. Сам переезд данных — это нажать четыре кнопки. Но не может же всё быть так просто! Первая кнопка не сработала, потому что 1С хранит в MS SQL в одном поле в одной ячейке 1 гигабайт данных — свою конфигурацию. А вот PostgreSQL так не умеет. Ладно, нашли патч, с помощью которого 1С разбирает эту гигантскую строку на несколько и потом пересобирает их в PostgreSQL. После этого миграция запустилась и состоялась. Ура? Нет. Отчет, который ранее создавался два часа, теперь формировался в три раза дольше. И тут началась история приключений, потому что глубинных средств диагностики ни в 1С, ни в PostgreSQL нет, и понять, что стало причиной задержки отчетов, невозможно. Команде пришлось включить расширенное логирование на PostgreSQL и смотреть, какой SQL при разных запросах пользователя сколько длится. Стоит ли говорить, что финальная отладка заняла намного больше времени, и простая миграция вылилась в несколько месяцев поисков причин «медленных» отчетов и их устранение.
Финальные выводы проекта поразили и заказчика, и меня тоже. К переезду на PostgreSQL были готовы 14 ИС — перевести их было относительно недорого и целесообразно. Эти системы имели под собой «свои» серверы, и их миграция на Open Source помогла бы сэкономить пару миллионов долларов. И это из 1500 на старте! Последняя иллюзия — лёгким движением Oracle превращается в PostgreSQL, надо только постараться — оказалась разрушена. Да, технически на PostgreSQL можно перевести всё что угодно, но встает вопрос цены. Например, в нашем проекте трудозатраты на адаптацию кода одной из ИС разработчик оценил в 28 000 человеко-дней!
Пока крупным ИС остается работать на СУБД Oracle, а компаниям — организовать его сопровождение любым способом.
В то же время этот результат мы получили в ландшафте конкретного крупного предприятия с кучей legacy. Не исключено, что в кейсе с более молодым ИТ-хозяйством выводы были бы совсем иные.
Итак, если подвести итог, то из СУБД Oracle на PostgreSQL годны к переезду базы данных, которые:
хранят небольшое количество кода;
используют относительно небольшое число специальных возможностей СУБД;
мало интегрированы со смежными системами.
Для остальных баз корректнее будет говорить о переделке/замене приложения, нежели чем о простой миграции данных.
В целом — ничего невозможного, просто проект не получится целиком скинуть на инфраструктурную команду и DBA.
А у вас какие подходы к решению этой задачи?
P.S. Здесь мы рассмотрели целесообразность миграции с Oracle на PostgreSQL в конкретном кейсе. Все находки по технической стороне миграции — в следующем посте.