Комментарии 15
Дайте почитать это разработчикам ПО СОФИ-Агентство из ИАТ ВТ. Они уже третий год обещают перевести свой продукт с Oracle на Postgres, и сроки все еще туманны.
А я всегда был уверен, если все делать не через одно место и руками растущими из правильного места - задача вполне решаемая, даже в условиях ограниченности ресурсов .
Похоже ораклом в плане производительности никто не занимался, если в pg стало лучше после переезда и оптимизаций)
занимались, но pg гораздо больше developer-friendly. в оракле была и куча хинтов, и гвоздями прибитые планы для критичных запросов, и регулярная помощь dba (которых на всех не хватало). а на pg еще сильно помогли инструменты managed pg из облака - заходили, смотрели стату по запросам, и резали топ проблем. так победили :)
чинили баги незаметно для пользователей
Ха-ха. Вам показалось :)
мы открывали краник с роутингом на несколько минут - набирали ошибок / стату по запросам - краник закрывали :) ошибки до юзеров не долетали, тк все они только в логах оседали (роутинг NOOP_REPEAT). а на тайминги смотрели на графики, если вдруг улетало сильно вверх, сразу краник закрывали и шли лечить performance
Подход с GG и пробными запросами понятен - это очень разумный подход, но я всё равно не смогу поверить, что все баги чинились незаметно. Мне при обсуждениях переезда с СУБД на другую на лету всегда вспоминается очень старый ролик EDS "Airplane".
Спасибо за подробную статью.
немножко ошибок всплыло после окончательного переключения (роутинг ENABLED), но как я написал, в течение пары часов хотфиксами все поправилось. ошибок было очень мало, тк они почти все были про запись (где-то тестов не хватило), а не про чтение, ошибки чтения безопасно ловились остальными режимами роутинга. в качестве пруфов хотел прицепить скрин из чата в день переезда, но чатик за давностью умер :)
Это хорошо, когда хранимых процедур-пакетов мало, а когда там тонны кода, переход oracle-pg уже не такой простой
Сколько же в яндексе было проектов по перезду с Оракла на PG. Наверное, самый старый (или нет?) - от 2016 года - https://habr.com/ru/articles/321756/
Интересно, можно ли было бы сделать какой-то универсальный набор тулинга / шагов, чтобы все проекты внутри компании использовали их, а не начинали свой ресерч с шагов типа "подойдет ли нам Oracle GoldenGate".
скажу больше, проект по переезду мы стартанули одновременно в 3 командах и как раз хотели единым путём пойти сперва. и устраивали встречу с Владимиром, перенять опыт. но у почты переезд занял 3+ года, но и масштабы другие. в итоге вскоре каждая команда пошла своим путем :) весь вопрос как раз в стартовых условиях и ограничениях. сколько данных? как лежат? можно по частям? возможен даунтайм? сколько человекорук? есть сроки?... и у всех команд все отличалось. из универсальных шагов наверно только выкинуть все лишнее, чтоб не мешало, да обложиться тестами
Не рожна не понял, но очень интересно. Вообще было бы правильно на уровне Минцифры реализовать какие-то универсальные тулзы, раз уж такая важная задача по 250-му указу.
неверится что все сказки про яндекс , или это только в жнтом году у них все так плохо стало?
Отличная статья, спасибо!
Как мы переехали с Oracle на PostgreSQL в нагруженном сервисе без даунтайма