Комментарии 14
Обычно на Oraclе много кода бизнес-логики выполнено на PL/SQL в хранимых процедурах, я так понимаю вы перенесли только табличные данные?
Все верно.
Вероятно там было минимум кода, поэтому все так удачно.
На самом деле проблема тут не в переезде, а дальнейшей поддержки PostgreSQL, т.к. по Oracle очень много специалистов разного уровня и есть из чего выбрать, а по PostgreSQL специалистов очень мало и они дорогие, особенно те, кто знает внутрянку PostgreSQL.
Не совсем согласен в том что специалистов по postgresql мало...тут скорее вопрос в квалификации таких специалистов. И как раз такие малые проекты позволяют узнавать нюансы и постепенно увеличивать сложность для обучения, повышая тем самым квалификацию. Уже многие компании экспериментируют с миграцией Oracle и mssql на другие продукты opensorce. И эта тенденция как мне кажется будет только нарастать. А вот на что мигрировать, этот вопрос остаётся открытым. И зависит от специфики проекта.
Видел оракловскую базу размером в 350TB (с приростом в 20-30TB/месяц), в которой было 0 логики и 0 строк PL/SQL кода. Упрощенное описание базы - просто огромное хранилище данных: объекты в BLOBах + описания объектов. Нельзя же считать бизнес-логикой автоматическое ежедневное создание date range партиций самим Ораклом? Ну да, 2-нодовый RAC с тремя Standby базами в разных датацентрах, ZFS-накопители, использующиеся для архивных read-only партиций и т.п.
Интересно услышать хоть какую-нибудь оценку - как изменилась скорость работы приложения после миграции данных, изменился ли объем БД после миграции, изменились ли требования к hardware.
Так как это была база малого объема скорость работы приложения практически не изменилась. Если бы предполагалась высокая нагрузка, использовались бы такие инструменты как pgbouncer и patroni. Часть нагрузки можно было бы снизить, отправив запросы чтения на slave. В любом случае, мы будем развиваться в данном направлении и при миграции крупных баз обязательно напишем.
С Oracle на Pg не мигрировал. С Firebird мигрировал. Мигрировали с Fb 2.5 на Pg 10. По самому переносу данных и повторении структур - ничего особенного. Написали руками код миграции на node. Из особенностей только булевы поля добавились. А вот все триггеры, процедуры пришлось переписывать с нуля. И по ходу эксплуатации иногда ловить ошибки, что в Pg в триггерах нужно возвращать new, а в Fb не нужно и местами при ручном переносе это не замечалось.
На Pg был ощутимый рост скорости запросов при тех же индексах. Некоторые запросы ускорились в десятки раз (как помню, Firebird не очень любил not in () условия). Также на pg для аналитических запросов (отчеты, где кучи join-ов, аггрегация, подселекты) настроили master-slave репликацию, что позволило еще сильнее разгрузить оперативную базу.
Мы в данный момент мигрируем с MS-SQL(T-Sql) на Pg12. И откровенно признаюсь, это просто адище в прямом смысле. Сам проект легаси, в котором накопилось бизнес логики за всё время существования (138 страдж процедур и 9 функций). И из-за этого каждый раз как в "первый раз": синтаксис отличается, очень важных языковых конструкций и команд(типа Merge) попросту нет. Запрос в Pg в отличии от T-Sql не может иметь переменных, и создание переменных типа "Table" не завезли (приходится заниматься колдунством ? с массивами собственных типов) . Даже есть ньюансы в работе одной и той же ОРМ с СУБД от мягкомягких и pg. Так что, всём желаю крепко держать "бубен" с своих руках?, он нам ещё пригодиться.
команд(типа Merge)
merge вроде бы будет в 15-ой версии, пока есть вот такое:
https://www.depesz.com/2015/05/10/waiting-for-9-5-add-support-for-insert-on-conflict-do-nothingupdate/
Да в бета версии его добавили, но переход был начат на 12й версии, а сейчас ни у кого не будет времени на новые "переходы". И к сожалению Insert on conflict не смог помочь в данной ситуации. Он работает только с уникальной связкой полей, а чтобы с имитировать ms-sql'ный merge пришлось городить огромную cteшку с полем-признаком insert or update.
Он работает только с уникальной связкой полей
гхм, всегда думал, что таблицы без уникального индентификатора в sql — дурной тон
Я здесь говорю не про primary key, а про команду, которая должна из рандомной коллекции колонок понять где делать insert, где update, а где delete. В unique запихнуть разные колонки не получится ведь они могут быть как и null так и not null, из за чего жёсткое ограничение инструкции On conflict в postgreSql не работает.
«Сами мы не местные», или Как мы провели миграцию с Oracle на PostgreSQL