Как стать автором
Обновить

Комментарии 14

Имел опыт миграции Oracle->PostgreSQL системы приёма наличных платежей через терминалы. Данные не требовались, но в самой базе был богатый уровень программных процедур. Честно говоря, так и не нашёл тогда автоматического инструмента и пришлось неделю по-процедурно писать код.

Есть пара других проектов, но там ещё и данные за много лет, а если прибавить сюда опять же множество процедур, то становится не по себе от объёмов.

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

Всё не вынесешь.

Да и подчас эти старания скорее обусловлены неумением в SQL, нежели заботой о возможных миграциях.

Либо старанием разнести хранение данных и бизнес логику в разные слои. Не вижу плюсов в необходимости нанимать отдельных разработчиков бл в бд, если все это можно сделать в разы быстрее на бэкэнде.

Конечно здесь лучше определить целесообразность, что именно лучше в конкретном случае. Могут уйти месяцы на пеписывание кода хранимок. Но это все делается, в неторопливой творческой обстановке, без необходимости вмешательства в исходную систему, и ее остановке. Главное в итоге чтобы к часу Х когда происходит сама миграция системы DDL целевой PostgreSQL была готова уже развернута. И в итоге нам нужно только быстро и консистентно перенести данные. Миграция в большинстве происходит с простоем, он как раз и наиболее критичен. И чем быстрее перенесем данные - тем лучше. Хорошо если управляемся в техокно 1-3 часа. Может быть разрешенный простой 10-20 часов, если например вектора изменений накапливаются уровнем выше на Кафке. Затем они перенаправляются на новый источник. Но например когда данные переносят 3(!) недели - это может оказаться недопустимым. Вот на это мы и хотели здесь обратить внимание.

Спасибо за ваш комментарий. Дело не только в заботе о миграциях но и вообще в эксплуатации и анализе. Хранимые функции и процедуры в целом оптимизировать тяжелее десятка прямых SQL запросов где бизнес логика снаружи. Внешне простой текст запроса вроде call prc(1034, '2024-01-01 00:00.00') где внутри много вложенной логики может вылиться в трассировочный файл в несколько гигабайт. Выделить проблемный фрагмент кода сразу не так просто. (Трассировка возможна и в PostgreSQL. Но это выглядит иначе чем в Оракле. Tkprof нет. Хотя в форках Postgres такие реализации уже встречаются.)

Я далек от Postgres и Oracle, не принимайте строго, но вот здесь с вами поспорю немного. Упрощенно на своем уровне скажу. Хранимые процедуры, это когда для того, что бы велосипед ехал с новым колесом, надо не колесо заменить, а полностью рулевую систему всю, включая вставку втулки в раму, чтоб, старые подшипники и прочее нормально встали. Когда логика вынесена, можно сменить переднюю вилку и колесо будет работать. Если сумбурно, извините.

Не вполне понял вас, давайте опишу ситуацию:

  1. Вам необходимо обновить запись в таблице А, запомнив значение а1 и а2.

  2. Вам необходимо обновить запись в таблице А, запомнив значение а1 и а2.

  3. Подсчитать сумму записей в таблице Б, запомнив значение б1 и обновив все записи выставив а1.

  4. А если б1 == 0, то откат.

  5. Подсчитать сумму записей в В, запомнив в1 и удалив все записи а2.

  6. А если в1 == 0, то откат.

  7. Вставить запись в таблицу Г, дополняя значениями а1, а2, б1, в1.

  8. Затем создать запись в логе аудита.

И всё это в одну транзакцию, или пан или пропал. Разумеется механизмы есть, но то приложение не вовремя вылетело, то таймаут пришёл, то ещё что-то. А пока транзакция не завершена, база ожидает и записи блокированы. А клиент, сами видите, не до того ему. И в такие моменты база очень быстро доходит до дедлока и вся система встаёт колом.

А вам ещё эту транзакцию восстанавливать, а данные уже устарели.

И вообще, хочется уволиться, вместо того, чтобы написать одну процедуру, которая сама делает, сама проверяет сама коммитит или откатывает. Тогда даже если клиент (базы) отвалился, то не имеет значения, главное, что дёрнул за рубильник, а там база сама всё сделает.

Это чисто навскидку. Реально, там ещё больше плюсов порою бывает. И мы даже про производительность не вспоминали.

Ну и насчёт странных решений. Как вам такое:

Веб-мордочка получает от базы JSON, который является макро языком интерфейса и по нему, веб-мордочка строит интерфейс веб приложения. Кнопочки, менюшки. Все эти данные из JSON, с идентификаторами оттуда же. А когда клиент тыкнул в кнопку, то веб-мордочка запрашивает у базы тык по этому идентификатору и получает новый JSON, который отображает. Т.е. фактически бекендом была база.

Я в базе не писал, наша часть была, создать веб-мордочку. Когда создали, департамент корбанкинга такой довольный был: наконец-то можно делать что хочу и без этих ваших HTML, Docker-ов и прочих.

Я имел ввиду, что при миграции с одной субд, на другую придется переписать логику, те самые хранимые процедеры, т.к. синтаксис разный, переписывать придется. А правка кода взаимодействующего с СУБД проще. Логика то остается в приложении. Переписывается только подключение/взаимодействие с СУБД. Сегодня mssql, завтра oracle, послезавтра postgres.

Всего неделя. А вот если у вас миллион-другой строк хранимых процедур...

Смотря что это за процедуры, какую специфику Оракл они используют. Каким образом они были сгенерированы или написаны. В целом это больше вопрос к архитекторам и разработчикам системы без связки с которыми и без понимания специфики работы компонентов, тестирования, действуя только силами DBA - миграция действительно дело часто безнадежное... Даже переписав процедуры синтаксически эквивалентно - не факт что это будет работать.

В результате этих работ с архитекторами должна быть готова в PostgreSQL рабочая схема БД. С какой то вероятностью у них она уже может быть готова. Даже в Оракловом RCU (repository creation utility) для хранения метаданных продукта в списке - довольно большой набор СУБД от MySQL до Oracle, как я помню был и PostgreSQL. Раньше обычно по умолчании выбирали только Оракл, хотя есть возможности и выбрать другую СУБД. Пресоздав таким образом структуру под другую БД и корректно мигрировав данные вы можете охватить целый пласт продуктов. В общем, все может быть и не настолько плохо как может показаться изначально. И вопрос нужно внимательно изучить.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий