Comments 73
все так.
а был вроде какой-то китайский оракл совместимый якобы с оригиналом?
Корейский! Tibero
Проблема с Tibero в том, что он ЮЖНОкорейский. В рамках противостояния санкциям не поможет, а значит и не нужон.
Попробуйте мыслить чуть шире. Тренд по свопу oracle на postgresql начался задолго до санкций в отношении РФ и не связан напрямую с РФ вообще никак. И причин этой хотелки очень много. Прямые расходы на лицензии это лишь одна из причин. На самом деле, используя oracle вы, скорее всего, даже не знаете нарушаете ли вы что-то или нет, потому что даже в самом oracle не каждый sales-инженер разберется в лицензионной модели.
Не стоит сводить причины замены коммерческого ПО на OSS лишь к санкциям или политике.
Да это реальный случай - некий архитектор в некой организации хотел, чтобы мы из Oracle рассылали поздравления с ДР и другие сообщения сотрудникам. На что я сказал, что Oracle может многое, и не только рассылать почту, но еще и пахать поля при установке его на трактор, но делать это категорически не рекомендовано. В общем почту с поздравлениями на основе данных Oracle стал рассылать специализированный софт.
а потом оказывается что, "местечковая фича" - это внезапно - убер фича, ради которой эту субд когда-то и покупали.
Если в БД предусмотрены job-ы (dbms_scheduler), которые совершают какие-то регулярные действия по обработке данных, то и послать (html-)письмецо результатах выполнения не выходя из базы кажется вполне уместным.
Если не отходить от ANSI-стандарта, не использовать CBO, партиционирование, не строить приложение исходя из архитектуры базы как версионника, да и вообще "местечковыми фичами не пользоваться", то зачем тогда покупать (читайте "платить деньги за") Oracle?
нередко оракл покупают в т.ч. для более успешного прохождения аудита (когда отдельные очки дают просто за сам факт использования конкретного ПО)
ну как бэ, Oracle все еще лучший OLTP DB в мире, хотя бы по причине того что его концепция undo log для версионности - уникальная убер-фича, которую все еще никто не повторил
пусть отрабатывает cron, например, а не шедулер ДБ, а рассылкой почты, внезапно, занимается почтовик
Ну здрасьте. Что за ущемления? Мы живем в эпоху равноправия и самоидентификации. Ну если чувствует почтовик, что рассылка почты не его, а шедулер бд хочет раскрыться в альтернативных областях - пусть раскрываются))
В таких случаях можно сделать рассылку почты в отдельном приложении, которое сами отправляемые письма считывает из таблицы в БД. Обычно хождение СУБД на внешние серваки не приветствуют безопасники, поэтому вынос непосредственно отправки в отдельное приложение обоснован.
Вот и получается, что желание засунуть бизнес логику в СУБД приводит к вендорлоку. Да и вообще излишняя оптимизация СУБД.
любая хорошая оптимизация - это оптимизация низкоуровневая - под субд - а значит и вендор лок. Ибо если вы не используете уникальные фичи субд - значит вы используете ее мощь только на 20%
С другой стороны, если запихнуть в СУБД не вполне стандартные функции (например, вычисление расстояния Хэмминга для сравнения векторов друг с другом прямо в БД), то с одной стороны мы вроде бы ещё используем СУБД по прямому назначению, а с другой стороны при миграции всё равно придётся это переписывать.
Но ведь, засунув бизнес-логику в сервер приложений, вы имеете те же риски. Если он у вас не полностью опенсорсный, конечно. И вдобавок будет большой трафик по сети.
Я работаю оракл разработчиком 10 лет.
Мои наблюдения очень печальны. 99% оракл разработчиков умеют пользоваться хорошо если 10 - 15% того, что умеет (и имеет на борту) оракл. Не просто абстрактно "умеет", а именно умеет то, что данному конкретному разработчику нужно. Поэтому в большинстве случаев, когда у рукамиводящих сотрудников возникает вопрос "а не дофига ли мы платим, может, стоит платить поменьше?", мне всегда хочется спросить - "а может, вам проще начать пользоваться тем, за что уже заплатили?"
В общем, если у вас возникло желание переехать с оракла на постгрес или что-то еще, потому что высокие расходы, будьте готовы к тому, что вы переедете, а расходы останутся высокими.
Так почти со всем инструментарием) Людям интерфейс то не хочется под себя настроить, что уж говорить о чем то более сложном....
Ну дык кому сейчас интересно учить детали каких-то legacy технологий
Оно может и не легаси. Просто в наше время людям стало понятно что всех знаний в голову не запихнешь и они начали учить то, что нужно в данный момент. А @StrangerInTheKyпросто нравится, с позиции увеличения ЧСВ, "вы все ... а я дартаньян".
Честно говоря, давно не слышал, чтобы кто-то начинал новые продукты с использованием Оракла. Поддержка, миграция в основном.
Однажды в проекте по разделению двух схем в Oracle мы столкнулись с тем, что пакеты одной схемы вызывают пакеты из другой схемы, которые в свою очередь снова вызывают пакеты из первой, и так по кругу. И всё это делалось через уже упомянутые синонимы. Мы построили дерево зависимостей и оцепенели от ужаса… Его высота составила 42 уровня!
От таких архитекторов никакая миграция не спасёт, увы
Резюме:
1) широкое использование специфических фич платного продукта несёт огромные риски (любой платный в поддержке продукт имеет ненулевую вероятность быть замененным бесплатным) - и за замену этих фич придётся заплатить еще раз;
2) выносите все алгоритмы, что сложнее join-ов, в питон )))
Алгоритмы запихивают в СУБД чтобы не гонять данные с СУБД туда и обратно. Гонять большие данные - дорогая операция.
Сеть нынче дешёвая - хоть 100, хоть 400гбит бери.
Если посмотреть на всякие пайплайны обработки больших данных (хадуп, спарк и иже с ними) - там перекачка данных и прочий их MapReduce это нормальное явление. Это позволяет обработать практически любой объем данных.
А если у вас данные, которые может прожевать один инстанс СУБД - то и передать их просто. При этом в обработке вы не будете ограничены убогим функционалом PL/PG/whatever SQL.
пайплант в бигдате и предполагает как раз обработку данных там где они хранятся ELT подход называется
Безусловно, при разных обстоятельствах можно руководствоваться соображениями оптимизации, либо соображения расширения ресурсов. Да и обработка порой требуется разная (где-то арифметику выполнить, а где-то сходить в разные api).
Но, тем не менее, когда вы выбираете обработку в прикладной системе, то должны учитывать, что помимо запроса СУБД еще будут затраты на кодирование данных в сетевой протокол и обратно, передачу по сети, работу драйвера прикладного языка. Также у вас не будет под рукой кешей, которые уже сформированы в СУБД и могут быть использованы в PL/PG/whatever SQL.
Также я не являюсь ярым сторонником того или иного подхода и в своих проектах опираюсь на следующие критерии:
Частота выполнения операции.
Затрагиваемый объем данных
Наличие в БД программного кода (от ваших коллег, возможно предыдущих)
Сложность реализации (в обе стороны работает)
Необходимость перекачки данных в две стороны (из СУБД и после обратно)
Использование специфичных фич программного продукта ведет к увеличению производительности оного. Для этого эти фичи и разрабатываются, за них вендор и берет деньги. Нет смысла покупать Exadata для простого хранения данных и single instance бд.
Если нужна просто реляционная бд как хранилище каких-то данных - то любая бд подойдет, даже такая которая в Primary Key не умеет. Ненуачо, неужели нельзя будет на питоне организовать поддержку целостности данных? Зато и смигрировать "такое" можно будет хоть в Notepad.
Не стоит забывать, что большие деньги платятся клиентами за Oracle (Platinum) Support, который может порешать любую твою проблему. Большие клиенты платят большие деньги за (само)уверенность, что есть кто-то, кто быстро и эффективно займется твоей проблемой, которую можно эскалировать на любые сколь угодно высокие уровни, сняв ответственность с себя. Я легко достукивался до менеджеров национального уровня, правильно объяснив важность возникшей проблемы своему менеджменту, который звонил по нужным номерам в Оракле и большое оракловское начальство предпочитало отзвониться само, чтобы понять масштаб проблемы, срочность решения и количество/специализацию народа, которое нужно быстро кооптировать. В итоге наш местный оракл знал мой личный телефон и всегда перезванивал первым при возникновении нового SR1 24x7 от нашей организации. Оценивал критичность ситуации и переадресовывал сразу на нужных инженеров, без недельных блужданий по бангалорскому суппорту, когда приходится одно и то же рассказывать каждый день новому инженеру.
Поэтому большим банкам проще потратить миллионы на Оракл, чем терпеть репутационные убытки, которые могут быть много выше затраченных средств на лицензии и поддержку.
Хотя идея перевода на более дешевые лицензии/технологии никуда не делась. Но у нас решили не мигрировать на PostgreSQL существующие проекты, а начинать на нём новые проекты для не особо критичных приложений / данных.
Так для PostreSQL тоже есть конторы, которые делают коммерческие сборки + позволяют менеджерам прикрыть пятую точки за гораздо более скромную денюжку.
Вы путаете размах крыльев у обычной коммерческой конторы, пусть и не со штатом, состоящим из двух красноглазиков, и и Ораклом, который может, грубо говоря, за ночь переписать весь codebase. У меня в карьере было два случая когда Оракл присылал мне бинарник, специально скомпилированный под нас и решающий именно нашу проблему. Причем, это было в разные года, в разных странах - то есть это не для одного клиента такие эксклюзивные услуги. В одном случае эта была очень старая версия Solaris и этот бинарник устанавливался навечно, в другом случае — это был виндовский exe-шник, который мы пользовали до выхода официального патчсета..
Очень не уверен, что такой уровень сервиса достижим мелкой конторой (а по сравнению с Ораклом все мелкие). Поэтому большим дядям проще иметь большие дела с другими большими конторами.
грубо говоря, за ночь переписать весь codebase
Не совсем понял, что вы имеете под codebase, но если верить этому, то изменения там не так просто делаются. И уж точно не быстро. Но да, версии, собранные под клиента, это для них нормальное явление.
да, это известная "особенность" 1С. Конфигурация поставщика хранится одним BLOB-ом и это периодически стреляет в разных сценариях миграции и репликации. Особенно критично для больших enterprise-решений, где как раз и возникают задачи, где это может выстрелить.
Подозреваю - не смущает.
Когда я работал с 1С, у меня регулярно возникало ощущение, что термин "нормализация" они даже не слышали. )))
а тут появляется волшебное слово "legacy": во времена, когда это придумывалось, конфигурация весила на порядок меньше. Ну и дальше: 1) это не самая частая операция, можно было подождать; 2) какие-то патчи вроде выпустили, но я уже перестал за этим внимательно следить
причем подобное странное отношение у них было ещё в староглинянные времена 7.7 когда SQL-БД была только одна (MSSQL) и даже в таком варианте одинаковые запросы могли отдавать разные ответы в зависимости — файловая база или sql)
там legacу у них в голове какогото архитектора который платформу проектирует судя по всему и его еще не уволили с тех пор
Так написали же, что пилят в первую очередь под MS SQL. Форк потребовался для того, "чтоб как в MS SQL" – postgresql должен работать как "блокировочник", а не как (изначально) "версионник". Хотя тот же MS SQL (если не ошибаюсь с версии 2008) вполне может работать и в режиме версионирования записей – нужно всего лишь изменить пару ключей в реестре и перезагрузить сервер. А в 1С не смогли решить задачу "блокирования записи" в версионной СУБД.
Связка 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.
Это же, как я вижу, только про данные...
Почитайте 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.
Лично у меня пока впечатление такое, что все случаи для которых автор допускает миграцию - это те, когда изначально требования к функционалу СУБД настолько общие, что непонятно зачем вообще изначально покупался Oracle и можно сразу было ставить хоть Postgre хоть что угодно, но по каким-то одному начальству ведомым причинам (варианты типа у меня виндовс от Microsoft, офис от Microsoft и пасьянс от Microsoft и мне все нравится - пусть и база у нас тоже будет от Microsoft, чтобы как в лучших домах все было) выбран был именно коммерческий вариант. То есть изначально самые беспроблемные варианты.
Это мне напоминает работу некоторых "ремонтников" советских времен, которые знали как только поменять лампы и шнур питания в телевизоре - ты отдавал им ящик в ремонт, ты сидел без телевизора пока он там лежал 3 недели, а потом они тебе его возвращали со словами типа "не смогли" и не гарантия еще что в полном комплекте. Нормальная контора должна браться за любые варианты, даже с полным выкорчевыванием хранимых процедур и переписыванием половины исходников. Разница может быть только в цене. А иначе не стоит, если по хорошему, даже этим и заниматься.
Ух сколько крови попила эта фуйня с оптимизацией запросов когда условия меняют местами или заменяют на джойн. Никакие хинты не помогают.
Вот вроде уже по тупому всевозможные варианты протестировал, выбрал оптимальный, отладил. Заливаешь на прод, и хуяк... Оказывается СУБД обновилась - патчсеты мелкие!!! установили, а косты почти у всех запросов изменились!
Ненавижу...
Уверен на 95%, что Ваша ненависть скорее от незнания предмета, чем от ошибок оптимизатора Oracle:
1) В грамотно спроектированной и написанной БД (где разработчик понимает, как 3-я нормальная форма влияет на CBO) разработчику должно быть плевать (по большому счету) на конкретный cost конкретного запроса - и не плевать на реально узкие места или проблемы в производительности.
2) Если узкое место выявлено, на cost все равно плевать - ибо это во многом производная от cardinality, и если у вас на каком-то шаге в плане запроса неверная оценка в cardinality - надо разбираться, почему. Наложили ли вы все constraint, особенноо not null? Не используете ли в качестве заменителя null какое-нибудь 01.01.2999? Что со статистикой? Рассматривали ли добавление гистограмм?
3) Хинты - это своего рода костыли, которые тяжело поддерживать, и их обильное применение означает попытку лечить симптомы и заметать реальные проблемы под ковер. В хорошем коде хинты используются в исключительных случаях, а если тут и там разбросаны use_nl/use_hash (и мы не говорим про версии oracle ниже 10) - что-то в этой бд явно не так.
Вообще, судя по моим наблюдениям, разрабатывать БД (под Oracle, за остальные СУБД говорить не буду) должен как минимум специалист уровня Senior, если вы не хотите спустя какое-то время заниматься рефакторингом бд. Впрочем, даже такой подход ничего не гарантирует, поскольку, похоже, для oracle-senior нынче достаточно иметь опыт работы с секционированием, знать несколько хинтов, модель блокирования, ну и всякого прочего по мелочи. А потом оказывается, что на полях таблиц нет ограничений, а поле boolean-вида эмулируют как number(1). И это что касается именно Oracle-разработчиков... чем заканчивается то, когда бд под Oracle занимаются FullStack-и, даже говорить не хочу. Это, внезапно, не просто "знать, что есть таблицы-индексы и как они работают", а много больше...
Кстати, для PostgreSQL есть расширение orafce, которое добавляет некоторые фишки оракла, в т.ч. добавляет эмуляцию некоторых специфичных оракловых пакетов.
Реальность устроена несколько иначе. Допустим сегодня вы запускаете новый проект/продукт на postgresql и может так случится, что жизненный цикл проекта/продукта будет более 10 лет. И через 10 лет придёт такой же человек как Вы и будет рассказывать - ну почему 10 лет назад выбрали postgresql, ведь уже тогда (в 2022) был cockroachdb (или что сейчас модно), который cloud-native и всё такое
Вам придется жить с postgresql и стеснятся рассказывать об этом где-либо, потому что девопсы на моноколесе засмеют.
А дальше случается следующее - в компании развиваются компетенции по определенной БД и в связи с этим ее начинают использовать и в новых проектах. Даже сегодня люди начинают проекты на PHP, хотя казалось бы - ну сколько уже можно насиловать труп
При среднем сроке работы в одной конторе в 2-3 года это будут уже не наши проблемы :)
на самом деле, зря минусуют ваш пост. смена места работы раз в 2-3 года это полезно для всех:
1. для специалиста - это возможность быть в тонусе, смотреть шире, использовать свой старый опыт на новом месте и впитывать новый опыт
2. для организаций - возможность получать опыт тех, кто придет и поделится своим опытом, объяснит как можно делать лучше
ну и кстати, на моем текущем месте работы компания старается использовать актуальные технологии в том числе и ради того, чтобы быть конкурентной на рынке труда, а то сейчас попробуй найти условного frontend-разработчика, который согласится писать на jquery без использования более современных фреймворков.
т.е. работодатели вынуждены быть в тренде чтобы потом не искать на рынке труда пенсионеров, пишущих на коболе
я пенсионер, готов писать на коболе!) шучу. по существу согласен, с одним но. программисты в России, как правило, относительно молодые ребята. с возрастом же видят себя уже где-нибудь в других областях, отличных от кодерства. ок. но не думаю, что так получается у каждого или хочется всем. что делать, когда тебе далеко за 50 и ты программист с 30 летним стажем? снова гоняться за новым фрэймворком, который очередная надстройка? да и не успеет он, "молодые" соображают быстрее. кстати, программисты на коболе очень хорошо получают - кода осталось много, а спецы заняты.
можно заниматься разработкой ядра linux. еще в начале года он был написан на c89 (https://www.phoronix.com/news/Linux-Kernel-C89-To-C11 ) (не следил в итоге перешли или нет). фреймворков там нет, либ нет (всё своё носят с собой)
Можно сделать все, даже невозможное. И мы беремся за такие проекты, от которых отказываются другие команды в силу сложности. Но в этом посте хотелось ответить на вопрос "А стоит ли?" перед тем, как засучивать рукава. Собственно, мы это исследование и провели, а заказчик уже решает стоит ли игра свеч. В этом конкретном кейсе большинство миграций оказались просто не выгодными.
Фрукт? - Фрукт!
«Надо переехать с Oracle на PostgreSQL. Ты только не волнуйся!»