С этого сообщения в мессенджере началось мое масштабное расследование вопроса, который давно не дает спать многим айтишникам — можно ли вот так взять и переехать с 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 в конкретном кейсе. Все находки по технической стороне миграции — в следующем посте.
Комментарии (70)
LuggerFormas
29.08.2022 14:58+25Именно так. Поменьше отходить от стандарта, местечковыми фичами не пользоваться, использовать БД (о ужас!) как БД, а не божественный класс, который там еще где-то в углу и почту шлет (руки бы оторвал).
MiIs
29.08.2022 15:16+7Да это реальный случай - некий архитектор в некой организации хотел, чтобы мы из Oracle рассылали поздравления с ДР и другие сообщения сотрудникам. На что я сказал, что Oracle может многое, и не только рассылать почту, но еще и пахать поля при установке его на трактор, но делать это категорически не рекомендовано. В общем почту с поздравлениями на основе данных Oracle стал рассылать специализированный софт.
H737
29.08.2022 21:28А почему рассылки не рекомендованы?
Разве Oracle не шлет уведомления по электронке, в каких-то технических случаях?
Ivan22
29.08.2022 16:17+18а потом оказывается что, "местечковая фича" - это внезапно - убер фича, ради которой эту субд когда-то и покупали.
akk0rd87
29.08.2022 18:09+12Если в БД предусмотрены job-ы (dbms_scheduler), которые совершают какие-то регулярные действия по обработке данных, то и послать (html-)письмецо результатах выполнения не выходя из базы кажется вполне уместным.
Если не отходить от ANSI-стандарта, не использовать CBO, партиционирование, не строить приложение исходя из архитектуры базы как версионника, да и вообще "местечковыми фичами не пользоваться", то зачем тогда покупать (читайте "платить деньги за") Oracle?
LuggerFormas
30.08.2022 13:11Уважаемый Аккорд, Вы неправы, хоть и полностью оправдываете свой ник. Не надо "дембельских аккордов", пусть отрабатывает cron, например, а не шедулер ДБ, а рассылкой почты, внезапно, занимается почтовик. Кажется уместным, но подкладывает просто адских свиней всем , кто придет позже. Плюс ненужный вендорлок. Зачем? Или по освоении молотка всё кажется гвоздями?
Вы все же немного путаете действительно "местечковые" фичи с тем, что сейчас есть у всех и везде забесплатно. Покупать сейчас Оракл, как видно даже здесь по комментариям, не имеет ценности окромя той самой платной поддержки, когда у самого лапки.
Не воспринимайте сказанное мной категорично. Но случаи, когда "вот прям нужно иначе весь проект по бороде" или "купили эту СУБД только ради этой фичи" - исчезающе малы. Надо - пользуемся. Но чаще не надо, и об этом стоит помнить.
rrrad
30.08.2022 21:17нередко оракл покупают в т.ч. для более успешного прохождения аудита (когда отдельные очки дают просто за сам факт использования конкретного ПО)
Ivan22
31.08.2022 01:10+1ну как бэ, Oracle все еще лучший OLTP DB в мире, хотя бы по причине того что его концепция undo log для версионности - уникальная убер-фича, которую все еще никто не повторил
rrrad
30.08.2022 21:12+1В таких случаях можно сделать рассылку почты в отдельном приложении, которое сами отправляемые письма считывает из таблицы в БД. Обычно хождение СУБД на внешние серваки не приветствуют безопасники, поэтому вынос непосредственно отправки в отдельное приложение обоснован.
v1000
29.08.2022 15:09+4Вот и получается, что желание засунуть бизнес логику в СУБД приводит к вендорлоку. Да и вообще излишняя оптимизация СУБД.
Ivan22
29.08.2022 16:14+19любая хорошая оптимизация - это оптимизация низкоуровневая - под субд - а значит и вендор лок. Ибо если вы не используете уникальные фичи субд - значит вы используете ее мощь только на 20%
LexB
30.08.2022 17:53Согласен. Видел реализации репортов когда данные выгружались в бины и потом обрабатывались в циклах вместо одного простого запроса. Архитектура ведь, изоляция, разграничение прав.
Rive
29.08.2022 16:34+2С другой стороны, если запихнуть в СУБД не вполне стандартные функции (например, вычисление расстояния Хэмминга для сравнения векторов друг с другом прямо в БД), то с одной стороны мы вроде бы ещё используем СУБД по прямому назначению, а с другой стороны при миграции всё равно придётся это переписывать.
Didimus
31.08.2022 13:53Но ведь, засунув бизнес-логику в сервер приложений, вы имеете те же риски. Если он у вас не полностью опенсорсный, конечно. И вдобавок будет большой трафик по сети.
StrangerInTheKy
29.08.2022 16:20+7Я работаю оракл разработчиком 10 лет.
Мои наблюдения очень печальны. 99% оракл разработчиков умеют пользоваться хорошо если 10 - 15% того, что умеет (и имеет на борту) оракл. Не просто абстрактно "умеет", а именно умеет то, что данному конкретному разработчику нужно. Поэтому в большинстве случаев, когда у рукамиводящих сотрудников возникает вопрос "а не дофига ли мы платим, может, стоит платить поменьше?", мне всегда хочется спросить - "а может, вам проще начать пользоваться тем, за что уже заплатили?"
В общем, если у вас возникло желание переехать с оракла на постгрес или что-то еще, потому что высокие расходы, будьте готовы к тому, что вы переедете, а расходы останутся высокими.Schwert
29.08.2022 19:54+3Так почти со всем инструментарием) Людям интерфейс то не хочется под себя настроить, что уж говорить о чем то более сложном....
Stas911
30.08.2022 05:58Ну дык кому сейчас интересно учить детали каких-то legacy технологий
LexB
30.08.2022 17:59+1Оно может и не легаси. Просто в наше время людям стало понятно что всех знаний в голову не запихнешь и они начали учить то, что нужно в данный момент. А @StrangerInTheKyпросто нравится, с позиции увеличения ЧСВ, "вы все ... а я дартаньян".
Stas911
30.08.2022 18:13Честно говоря, давно не слышал, чтобы кто-то начинал новые продукты с использованием Оракла. Поддержка, миграция в основном.
DMGarikk
30.08.2022 18:18+1мне кажется это во многом из-за стоимости лицензий, и маразматической особенностью лицензирования — насколько я помню там нельзя делать перерыв в покупке сервисного обслуживания
Stas911
30.08.2022 18:32+3Да, тоже про это слышал. Одни из наших клиентов отказались от поддержки оркала в банковской системе, когда она через годик легла с ошибкой вида "ORA-звоните-в-саппорт", им все припомнили в двойном размере.
NickNal
29.08.2022 16:21+6Однажды в проекте по разделению двух схем в Oracle мы столкнулись с тем, что пакеты одной схемы вызывают пакеты из другой схемы, которые в свою очередь снова вызывают пакеты из первой, и так по кругу. И всё это делалось через уже упомянутые синонимы. Мы построили дерево зависимостей и оцепенели от ужаса… Его высота составила 42 уровня!
От таких архитекторов никакая миграция не спасёт, увы
Melkij
29.08.2022 16:21+8А самая боль — многие из этих переезжающих не хотят postgresql. Вообще не хотят. Они хотят получить именно оракл (или откуда там переезжают). И на любые несоответствия поведения от своего любимого вендора заявляют «да фигня какая-то этот ваш postgres, вот в оракле сделано правильно» (даже если это «правильно» объективно противоречит спецификации sql, как в примере с null)
Ivan22
29.08.2022 17:09+12так это логично. Ибо ставлю деньги - переезжают они не из-за того что оракл стал плохо работать, а из-за того что денег жалко, или санкции. А так то с инженерной т.з их все устраивало.
LexB
30.08.2022 18:02Конечно нет! Переезжают именно из-за того что пустая строка - null противоречит спецификации SQL! :) (сарказм)
Stas911
30.08.2022 22:00Ну с инженерной тз Оракл весьма же стабильный и надежный продукт в целом (за столько-то лет)
avshkol
29.08.2022 16:59+1Резюме:
1) широкое использование специфических фич платного продукта несёт огромные риски (любой платный в поддержке продукт имеет ненулевую вероятность быть замененным бесплатным) - и за замену этих фич придётся заплатить еще раз;
2) выносите все алгоритмы, что сложнее join-ов, в питон )))
PaulIsh
29.08.2022 17:16+17Алгоритмы запихивают в СУБД чтобы не гонять данные с СУБД туда и обратно. Гонять большие данные - дорогая операция.
blind_oracle
30.08.2022 10:41-1Сеть нынче дешёвая - хоть 100, хоть 400гбит бери.
Если посмотреть на всякие пайплайны обработки больших данных (хадуп, спарк и иже с ними) - там перекачка данных и прочий их MapReduce это нормальное явление. Это позволяет обработать практически любой объем данных.
А если у вас данные, которые может прожевать один инстанс СУБД - то и передать их просто. При этом в обработке вы не будете ограничены убогим функционалом PL/PG/whatever SQL.
Ivan22
30.08.2022 11:24+1пайплант в бигдате и предполагает как раз обработку данных там где они хранятся ELT подход называется
blind_oracle
30.08.2022 11:46Не ELT, а ETL. И расшифровывается он Extract-Transform-Load, что как раз означает выгрузку-обработку-загрузку обратно.
supervisor
30.08.2022 14:30+1ELT тоже есть :)
blind_oracle
30.08.2022 14:49Есть, но суть примерно та же - источники данных отдельно, обработка отдельно.
Ivan22
31.08.2022 01:13+1поэтому уже лет 10 как ETL подход уступает место ELT - как раз чтобы данные обрабатывать там где они лежат, и это уже стандарт
PaulIsh
30.08.2022 12:25+1Безусловно, при разных обстоятельствах можно руководствоваться соображениями оптимизации, либо соображения расширения ресурсов. Да и обработка порой требуется разная (где-то арифметику выполнить, а где-то сходить в разные api).
Но, тем не менее, когда вы выбираете обработку в прикладной системе, то должны учитывать, что помимо запроса СУБД еще будут затраты на кодирование данных в сетевой протокол и обратно, передачу по сети, работу драйвера прикладного языка. Также у вас не будет под рукой кешей, которые уже сформированы в СУБД и могут быть использованы в PL/PG/whatever SQL.
Также я не являюсь ярым сторонником того или иного подхода и в своих проектах опираюсь на следующие критерии:
Частота выполнения операции.
Затрагиваемый объем данных
Наличие в БД программного кода (от ваших коллег, возможно предыдущих)
Сложность реализации (в обе стороны работает)
Необходимость перекачки данных в две стороны (из СУБД и после обратно)
FlyingDutchman
29.08.2022 17:23+9Использование специфичных фич программного продукта ведет к увеличению производительности оного. Для этого эти фичи и разрабатываются, за них вендор и берет деньги. Нет смысла покупать Exadata для простого хранения данных и single instance бд.
Если нужна просто реляционная бд как хранилище каких-то данных - то любая бд подойдет, даже такая которая в Primary Key не умеет. Ненуачо, неужели нельзя будет на питоне организовать поддержку целостности данных? Зато и смигрировать "такое" можно будет хоть в Notepad.
FlyingDutchman
29.08.2022 17:10+14Не стоит забывать, что большие деньги платятся клиентами за Oracle (Platinum) Support, который может порешать любую твою проблему. Большие клиенты платят большие деньги за (само)уверенность, что есть кто-то, кто быстро и эффективно займется твоей проблемой, которую можно эскалировать на любые сколь угодно высокие уровни, сняв ответственность с себя. Я легко достукивался до менеджеров национального уровня, правильно объяснив важность возникшей проблемы своему менеджменту, который звонил по нужным номерам в Оракле и большое оракловское начальство предпочитало отзвониться само, чтобы понять масштаб проблемы, срочность решения и количество/специализацию народа, которое нужно быстро кооптировать. В итоге наш местный оракл знал мой личный телефон и всегда перезванивал первым при возникновении нового SR1 24x7 от нашей организации. Оценивал критичность ситуации и переадресовывал сразу на нужных инженеров, без недельных блужданий по бангалорскому суппорту, когда приходится одно и то же рассказывать каждый день новому инженеру.
Поэтому большим банкам проще потратить миллионы на Оракл, чем терпеть репутационные убытки, которые могут быть много выше затраченных средств на лицензии и поддержку.
Хотя идея перевода на более дешевые лицензии/технологии никуда не делась. Но у нас решили не мигрировать на PostgreSQL существующие проекты, а начинать на нём новые проекты для не особо критичных приложений / данных.
maxzh83
29.08.2022 17:28+1Так для PostreSQL тоже есть конторы, которые делают коммерческие сборки + позволяют менеджерам прикрыть пятую точки за гораздо более скромную денюжку.
FlyingDutchman
29.08.2022 17:38+10Вы путаете размах крыльев у обычной коммерческой конторы, пусть и не со штатом, состоящим из двух красноглазиков, и и Ораклом, который может, грубо говоря, за ночь переписать весь codebase. У меня в карьере было два случая когда Оракл присылал мне бинарник, специально скомпилированный под нас и решающий именно нашу проблему. Причем, это было в разные года, в разных странах - то есть это не для одного клиента такие эксклюзивные услуги. В одном случае эта была очень старая версия Solaris и этот бинарник устанавливался навечно, в другом случае — это был виндовский exe-шник, который мы пользовали до выхода официального патчсета..
Очень не уверен, что такой уровень сервиса достижим мелкой конторой (а по сравнению с Ораклом все мелкие). Поэтому большим дядям проще иметь большие дела с другими большими конторами.
maxzh83
29.08.2022 18:22+1грубо говоря, за ночь переписать весь codebase
Не совсем понял, что вы имеете под codebase, но если верить этому, то изменения там не так просто делаются. И уж точно не быстро. Но да, версии, собранные под клиента, это для них нормальное явление.
StupidMouse
30.08.2022 10:21имеется ввиду ваш codebase, ну серверную часть. они ведь решают вашу проблему?
Inine
30.08.2022 13:32Да прямо. Какой серьезный бизнес пустит ораклокодеров в свой реп, который наверняка еще за семью согласованиями с безопасниками.
ViacheslavNk
30.08.2022 13:48Скорее всего имеется ввиду приватный фикс для определенной версии/релиза Oracle.
staticmain
29.08.2022 17:12+2Сам переезд данных — это нажать четыре кнопки. Но не может же всё быть так просто! Первая кнопка не сработала, потому что 1С хранит в MS SQL в одном поле в одной ячейке 1 гигабайт данных — свою конфигурацию.
Простите, что?
frrrost
29.08.2022 17:28+2да, это известная "особенность" 1С. Конфигурация поставщика хранится одним BLOB-ом и это периодически стреляет в разных сценариях миграции и репликации. Особенно критично для больших enterprise-решений, где как раз и возникают задачи, где это может выстрелить.
staticmain
29.08.2022 17:54+1А их ничего не смущает в таком образе жизни? Ну например что такой "ответ" база может отдавать много времени. Варианты "name": char, "value" : char они вообще не рассматривают?
SergeyUstinov
29.08.2022 18:34+6Подозреваю - не смущает.
Когда я работал с 1С, у меня регулярно возникало ощущение, что термин "нормализация" они даже не слышали. )))
frrrost
29.08.2022 18:35+1а тут появляется волшебное слово "legacy": во времена, когда это придумывалось, конфигурация весила на порядок меньше. Ну и дальше: 1) это не самая частая операция, можно было подождать; 2) какие-то патчи вроде выпустили, но я уже перестал за этим внимательно следить
DMGarikk
29.08.2022 18:57+21C давно была замечена за тем что практически не использует возможности БД для своей работы, во многом для того чтобы обеспечить типа 'прозрачную поддержку всех этих mssql/oracle/db2/postgres и «файловый вариант', буквально сведя всю работу с БД к типовым селектам и апдейтам… а учитвая что они в первую очередь пилят mssql потом файловую… то на остальные у них или терпения не хватает или желания
причем подобное странное отношение у них было ещё в староглинянные времена 7.7 когда SQL-БД была только одна (MSSQL) и даже в таком варианте одинаковые запросы могли отдавать разные ответы в зависимости — файловая база или sql)
там legacу у них в голове какогото архитектора который платформу проектирует судя по всему и его еще не уволили с тех порMelkij
29.08.2022 20:54+2Да вот если бы они хотя бы свели всю работу к простому и глупому CRUD. Так нет же, творят какую-то лютую дичь так, что для гордого заявления «поддерживаем работу на postgresql» им требуется отдельный форк (!) postgresql
Tippy-Tip
30.08.2022 01:58Так написали же, что пилят в первую очередь под MS SQL. Форк потребовался для того, "чтоб как в MS SQL" – postgresql должен работать как "блокировочник", а не как (изначально) "версионник". Хотя тот же MS SQL (если не ошибаюсь с версии 2008) вполне может работать и в режиме версионирования записей – нужно всего лишь изменить пару ключей в реестре и перезагрузить сервер. А в 1С не смогли решить задачу "блокирования записи" в версионной СУБД.
Johan_Palych
29.08.2022 17:30Связка oracle instant client(под Windows и Linux) + oracle fdw через PgAdmin c Ora2Pg.
PostgreSQL provides foreign data wrappers (FDW) as a mechanism for accessing various external data sources. This article explains how to access Oracle databases using oracle_fdw, a foreign data wrapper for Oracle databases.
Mike_Mihalych
29.08.2022 20:31Это же, как я вижу, только про данные...
Johan_Palych
30.08.2022 15:31Почитайте Postgresso 39 и Postgresso 33
In this article we wrap up our discussion of oracle_fdw, the foreign data wrapper that allows PostgreSQL to access Oracle databases. We expand on pushdown and update transactions, and discuss data type conversion and how the wrapper handles differences in data types and constraints between the foreign table and the remote one.
MrKirushko
29.08.2022 21:29+2Лично у меня пока впечатление такое, что все случаи для которых автор допускает миграцию - это те, когда изначально требования к функционалу СУБД настолько общие, что непонятно зачем вообще изначально покупался Oracle и можно сразу было ставить хоть Postgre хоть что угодно, но по каким-то одному начальству ведомым причинам (варианты типа у меня виндовс от Microsoft, офис от Microsoft и пасьянс от Microsoft и мне все нравится - пусть и база у нас тоже будет от Microsoft, чтобы как в лучших домах все было) выбран был именно коммерческий вариант. То есть изначально самые беспроблемные варианты.
Это мне напоминает работу некоторых "ремонтников" советских времен, которые знали как только поменять лампы и шнур питания в телевизоре - ты отдавал им ящик в ремонт, ты сидел без телевизора пока он там лежал 3 недели, а потом они тебе его возвращали со словами типа "не смогли" и не гарантия еще что в полном комплекте. Нормальная контора должна браться за любые варианты, даже с полным выкорчевыванием хранимых процедур и переписыванием половины исходников. Разница может быть только в цене. А иначе не стоит, если по хорошему, даже этим и заниматься.
staticmain
29.08.2022 23:11+2даже с полным выкорчевыванием хранимых процедур
Я год работал разработчиком под Oracle, сейчас часто приходится работать с MySQL. Так вот хранимые процедуры в Oracle - это такой ад, что их зачастую в принципе нельзя портировать. У нас был Report, в котором нужно было поменять (слегка) функционал одной кнопки (поменять фильтр). Там вызывалось 25+ вложенных процедур, иногда по два раза одна и та же, но с разными параметрами. Всё это обмазано Oracle-only переменными и встроенными функциями. И это один из "встроенных" репортов. Такое в принципе нельзя портировать, для этого нужно написать второй Oracle с тем же набором встроенных функций, ORA_* переменных и синтаксическими возможностями. Не говоря уже о том, что сам язык запросов тоже отличается и один и тот же запрос в Oracle/MySQL/PostgresSQL выдаст абсолютно разные результаты. И это я еще не коснулся быстродействия, когда в Oracle в части версий всё еще настолько плохой оптимизатор запросов, что Select ... from ... where A.b = B.b and B.c = C.c и пр. будет в разы медленнее чем Left Join.
toxicdream
30.08.2022 09:43Ух сколько крови попила эта фуйня с оптимизацией запросов когда условия меняют местами или заменяют на джойн. Никакие хинты не помогают.
Вот вроде уже по тупому всевозможные варианты протестировал, выбрал оптимальный, отладил. Заливаешь на прод, и хуяк... Оказывается СУБД обновилась - патчсеты мелкие!!! установили, а косты почти у всех запросов изменились!
Ненавижу...
rrrad
31.08.2022 12:47+1Кстати, для PostgreSQL есть расширение orafce, которое добавляет некоторые фишки оракла, в т.ч. добавляет эмуляцию некоторых специфичных оракловых пакетов.
in_heb
29.08.2022 23:19+4Реальность устроена несколько иначе. Допустим сегодня вы запускаете новый проект/продукт на postgresql и может так случится, что жизненный цикл проекта/продукта будет более 10 лет. И через 10 лет придёт такой же человек как Вы и будет рассказывать - ну почему 10 лет назад выбрали postgresql, ведь уже тогда (в 2022) был cockroachdb (или что сейчас модно), который cloud-native и всё такое
Вам придется жить с postgresql и стеснятся рассказывать об этом где-либо, потому что девопсы на моноколесе засмеют.
А дальше случается следующее - в компании развиваются компетенции по определенной БД и в связи с этим ее начинают использовать и в новых проектах. Даже сегодня люди начинают проекты на PHP, хотя казалось бы - ну сколько уже можно насиловать труп
Stas911
30.08.2022 06:07При среднем сроке работы в одной конторе в 2-3 года это будут уже не наши проблемы :)
in_heb
30.08.2022 09:52+1на самом деле, зря минусуют ваш пост. смена места работы раз в 2-3 года это полезно для всех:
1. для специалиста - это возможность быть в тонусе, смотреть шире, использовать свой старый опыт на новом месте и впитывать новый опыт
2. для организаций - возможность получать опыт тех, кто придет и поделится своим опытом, объяснит как можно делать лучше
ну и кстати, на моем текущем месте работы компания старается использовать актуальные технологии в том числе и ради того, чтобы быть конкурентной на рынке труда, а то сейчас попробуй найти условного frontend-разработчика, который согласится писать на jquery без использования более современных фреймворков.т.е. работодатели вынуждены быть в тренде чтобы потом не искать на рынке труда пенсионеров, пишущих на коболе
dezhavuu
31.08.2022 18:48я пенсионер, готов писать на коболе!) шучу. по существу согласен, с одним но. программисты в России, как правило, относительно молодые ребята. с возрастом же видят себя уже где-нибудь в других областях, отличных от кодерства. ок. но не думаю, что так получается у каждого или хочется всем. что делать, когда тебе далеко за 50 и ты программист с 30 летним стажем? снова гоняться за новым фрэймворком, который очередная надстройка? да и не успеет он, "молодые" соображают быстрее. кстати, программисты на коболе очень хорошо получают - кода осталось много, а спецы заняты.
in_heb
31.08.2022 19:33можно заниматься разработкой ядра linux. еще в начале года он был написан на c89 (https://www.phoronix.com/news/Linux-Kernel-C89-To-C11 ) (не следил в итоге перешли или нет). фреймворков там нет, либ нет (всё своё носят с собой)
JetHabr Автор
30.08.2022 11:02+1Можно сделать все, даже невозможное. И мы беремся за такие проекты, от которых отказываются другие команды в силу сложности. Но в этом посте хотелось ответить на вопрос "А стоит ли?" перед тем, как засучивать рукава. Собственно, мы это исследование и провели, а заказчик уже решает стоит ли игра свеч. В этом конкретном кейсе большинство миграций оказались просто не выгодными.
hellamps
все так.
а был вроде какой-то китайский оракл совместимый якобы с оригиналом?
ivoronin
Корейский! Tibero
Shadowbearer
Проблема с Tibero в том, что он ЮЖНОкорейский. В рамках противостояния санкциям не поможет, а значит и не нужон.
in_heb
Попробуйте мыслить чуть шире. Тренд по свопу oracle на postgresql начался задолго до санкций в отношении РФ и не связан напрямую с РФ вообще никак. И причин этой хотелки очень много. Прямые расходы на лицензии это лишь одна из причин. На самом деле, используя oracle вы, скорее всего, даже не знаете нарушаете ли вы что-то или нет, потому что даже в самом oracle не каждый sales-инженер разберется в лицензионной модели.
Не стоит сводить причины замены коммерческого ПО на OSS лишь к санкциям или политике.