Чем postgresql лучше oracle

PostgreSQL vs Oracle

Сразу оговорюсь — я не имею ничего против размещения части бизнес логики в хранимых функциях, если это предусмотрено в архитектуре системы и оправдано по ряду практических соображений, которые выходят за рамки этой статьи.

C Oracle у меня старые и тесные взаимоотношения. Видел много отличных архитектур и кода, и много ужасных «залеп». Oracle предоставляет разработчику неисчерпаемую бездну возможностей, и практически всегда находится нужная именно сейчас «фишка».
В целом, Oracle — удивительный инструмент, и я не устаю удивляться тому, как всё это богатство может работать в принципе и работать стабильно.

Около двух лет назад я перешёл из Enterprise мира в свободное плавание, где махина Oracle с её $47k за ядро — вне досягаемости.
Одним из первых freelance проектов был небольшой биллинг для суб-оператора спутниковой связи. Встал вопрос выбора РСУБД. MySQL сразу отпал по причине недоразвитости процедурного языка, выбор пал на PostgreSQL.

По мере работы над этим и следующими проектами я составлял список субъективных плюсов и минусов PostgreSQL по сравнению с Oracle с точки зрения разработчика БД. Его и представляю вашему вниманию:

PostgreSQL vs Oracle

PRO:

• Псевдо тип serial — объединяет лучшие черты auto_increment из MySQL и sequence из Oracle.
• Можно писать функции на чистом SQL. Например функция, состоящая из одного update c returning, возвращающая идентификатор только что добавленного значения. Позволяет избавится от явного объявления переменных, в которые выбираются данные и которые затем возвращаются в return.
• Замечательный with в котором можно в качестве запроса использовать не только select, но и insert, update, delete returning и который можно делать рекурсивным (заменяет оракловский connect by). Кроме того заменяет собой оракловский мультитабличный insert all.
• Generate_series вместо извращений типа select level from dual connect by level < n
• Очень мощный механизм контроля целостности данных aka CONSTRAINTS — например EXCLUDE позволяет делать хитрые проверки ДРУГИХ строк при вставке новой (иначе пришлось бы писать триггер), REFERENCES (foreign key) c действиями при удалении или изменении записей, на которые ссылается таблица. Например constraint constname references tablename on delete cascade удалит связанные записи при удалении родительской.
• Замечательная, но потенциально опасная (как триггеры) система правил (RULES) позволяющая подменять текст запроса отправляемый серверу. Через неё, например, реализованы VIEW.
• Удобный раздел WHERE в определении индекса, позволяет уменьшить размер индекса не прибегая к созданию функциональных индексов и нечитабельных условий типа where decode(status,1,1,null)=1
• LIMIT с OFFSET, позволяющие избежать геморроя с rownum, сортировкой и подзапросами.
• Приятная документация, лишённая сухости и монструозности (но и дотошности) оракловской.

CONS:

Неприятные синтаксические анахронизмы, вроде необходимости ескейпить тело ХФ, например так:

 function test() returns void as $$ begin end; $$ language plpgsql; 

Заключение

Хорошим дополнением этому списку было бы сравнение с точки зрения DBA, но тут, как говорится, я не вполне копенгаген. Было бы очень интересно в будущем увидеть такое сравнение на Хабре.

Выводы? PostgreSQL есть куда расти, но уже сейчас при разработке проектов не сверхбольших масштабов он выглядит очень достойно рядом с чего уж таить — эталоном рынка РСУБД.

Особенности при миграции из Oracle в PostgreSQL (Life Hacks)

Хотя Oracle позволяет пользователям отключать и включать ограничения сколь угодно часто, это обычно не рекомендуется для любой СУБД, поскольку при неправильном выполнении это может привести к повреждению данных. В PostgreSQL ограничения вместо этого создаются как отложенные, и для их отсрочки можно использовать команду SET CONSTRAINTS. Параметр отложенного выполнения указывает время по умолчанию для активации ограничения. Если ограничение в Oracle нельзя отложить, его нужно будет отбросить и воссоздать как откладываемое, хотя иногда можно изменить ограничение, не отбрасывая его.

2 — Delete

При удалении данных в PostgreSQL для указания таблицы необходимо использовать синтаксис FROM, в Oracle же не требуется.

3 — Удаление объектов базы данных

В PostgreSQL разрешение на удаление объектов ограничено только владельцем таблицы базы данных или суперпользователем. Это не предоставляемая привилегия, хотя членство в роли, которая владеет объектом, может быть предоставлено. Если возможность удаления объектов базы данных в Oracle также предоставлено как членство в роли, то тогда необходимо будет переписать или перенастроить объект.

4 — Dual Table

Поскольку предложение FROM является обязательным в Oracle для каждого оператора SELECT, FROM DUAL используется для операторов SELECT, где имя таблицы не требуется. PostgreSQL не требует предложения FROM, поэтому FROM DUAL не требуется и обычно его можно опустить. Если в PostgreSQL требуется dual table, ее можно сгенерировать как представление.

5 — Пустые строки и NULL

В Oracle пустые строки имеют значения NULL, но они не считаются NULL в PostgreSQL. В Oracle можно проверить, пуста ли строка или нет, с помощью оператора IS NULL, но в PostgreSQL он вернет FALSE для пустой строки (и TRUE для NULL).

6 — Federation to Foreign Data Wrappers

Функция Oracle Federation позволяет пользователям обрабатывать таблицы из других баз данных, как локальные данные. Оболочки сторонних данных PostgreSQL более универсальны и позволяют подключаться к более широкому диапазону данных.

7 — GRANT

Команда GRANT действует аналогично в Oracle и PostgreSQL. Есть два основных варианта — они могут использоваться для предоставления привилегий для объекта базы данных и для предоставления членства роли.

При этом, не все привилегии Oracle доступны в PostgreSQL. Например, предоставление привилегии триггера для таблицы позволяет пользователям создавать триггеры, но в отличие от Oracle только владелец таблицы может удалять триггеры.

8 — Иерархические запросы

PostgreSQL не поддерживает START WITH. . .CONNECT BY, который Oracle использует для иерархических запросов. Вместо этого PostgreSQL использует WITH RECURSIVE.

9 — Joins with (+)

В Oracle есть специальный оператор (+) для выполнения левого и правого outer joins. В PostgreSQL эта функция отсутствует, поэтому необходимо указывать команду JOIN.

10 — Проверка NOT NULL

Для определения какие столбцы в таблице Oracle НЕ являются NULL, необходимо использовать команду CHECK ( IS NOT NULL). В PostgreSQL же вместо этого имеется столбец «attnotnull» в pg_attribute, в котором хранится информация о столбцах таблицы, в том числе – о столбце с Constraint NOT NULL.

11 — Преобразование PL / SQL в PL / pgSQL

Процедурный язык PostgreSQL PL/pgSQL во многих отношениях похож на Oracle PL/SQL. Оба являются императивными языками с блочной структурой и похожими форматами для присваиваний, циклов и условных выражений.

12 — Remote objects

Для доступа к remote objects можно использовать оболочку внешних данных (Oracle_fdw) для доступа к любой другой базе данных. Столбцы ROWID, CTID и IdentityPostgreSQL не имеет точного эквивалента псевдостолбцу ROWID в Oracle, который предоставляет адрес строки в таблице. CTID в PostgreSQL аналогичен, за исключением того, что его значение изменяется каждый раз при выполнении VACUUM. Вместо этого используются столбцы идентификаторов, значения которых создаются автоматически при создании строки и никогда не изменяется. Значение можно указать, чтобы оно создавалось ВСЕГДА или ПО УМОЛЧАНИЮ. GENERATED BY DEFAULT позволяет пользователю вставить или обновить значение, а не использовать значение, сгенерированное системой.

13 — Sequences

Sequences имеют другой синтаксис в Oracle и PostgreSQL, и их необходимо обновлять вручную или с помощью скрипт.

14 — SUBSTR

Функция SUBSTR по-разному работает в Oracle и PostgreSQL. В Oracle оператор SELECT SUBSTR (‘ABC’, — 1) FROM DUAL; возвращает «C», а эквивалентный SELECT SUBSTR (‘ABC’, — 1); в PostgreSQL вернет ABC.

15 — MERGE INTO

В PostgreSQL отсутствует оператор MERGE INTO, в отличие от Oracle.

16 — Синонимы

PostgreSQL не поддерживает синонимы. Вместо CREATE SYNONYM Oracle для доступа к удаленным объектам в PostgreSQL можно использовать SET search_path для включения удаленного определения.

17 — SYSDATE

Функция Oracle SYSDATE возвращает дату и время (в часовом поясе сервера). PostgreSQL не имеет соответствующей функции, но существует ряд методов для получения даты и времени для различных целей: statement_timestamp () дает текущую дату и время с начала текущего оператора; now () и transaction_timestamp () дают дату и время с начала текущей транзакции, а clock_timestamp () дает текущую дату и время с момента выполнения функции.

18 — TO_DATE

Функция to_date () как в Oracle, так и в PostgreSQL возвращает тип данных даты. Однако тип данных даты PostgreSQL предоставляет дату (год, месяц, день), а значение типа данных даты Oracle предоставляет дату и время (год, месяц, день, час, минута, секунда). Чтобы избежать этой несовместимости, используйте to_timestamp () PostgreSQL. Решением этой несовместимости является преобразование TO_DATE () в TO_TIMESTAMP ().

19 — Транзакции

Oracle всегда использует транзакции, но в PostgreSQL их нужно активировать. В Oracle выполнение любого оператора запускает транзакцию и заканчивается оператором COMMIT. В PostgreSQL транзакция начинается с оператора BEGIN, а также заканчивается оператором COMMIT. Уровни изоляции транзакций одинаковы в PostgreSQL и Oracle, и Read Committed является уровнем изоляции по умолчанию для обоих.

20 — Обработка ошибок транзакции

PostgreSQL создан для облегчения управления транзакциями и обработки ошибок с полной поддержкой ACID и уровнями изоляции. Он также способен обрабатывать ошибки времени выполнения и предоставляет надежные коды ошибок и сообщения для PL/pgSQL или кода приложения. Однако они обрабатываются иначе, чем Oracle, поэтому изменения все же необходимо внести. Вот несколько советов по оптимизации обработки ошибок в PostgreSQL:

• Контроль транзакций внутри PL / pgSQL не разрешен: вы не можете зафиксировать или откатить транзакцию внутри хранимой процедуры.
• Когда во время транзакции возникает исключительная ситуация во время выполнения, транзакция должна быть отменена, перед выполнением другой операции, потому что транзакция прерывается, когда обнаруживает ошибку. Журнал приложения покажет следующее сообщение об ошибке:
• Используйте блок BEGIN… EXCEPTION… END для обработки исключений, чтобы код улавливал любые возникающие ошибки. Это автоматически устанавливает точку сохранения перед блоком и откатывается к ней при возникновении исключения. Имейте в виду, что, поскольку блоки исключений создают точку сохранения, они дороги, поэтому добавляйте их осторожно.
• Сопоставьте коды ошибок и типы исключений из Oracle в PostgreSQL. Хотя некоторые коды ошибок одинаковы в обоих случаях, другие различаются. Язык программирования также влияет на это — например, специфичные для Oracle исключения JDBC должны быть заменены либо общими исключениями между базами данных, либо специфичными для PostgreSQL.
• Обеспечение правильной обработки транзакций и ошибок в базе данных PostgreSQL является важной частью процесса миграции и обычно требует тщательного анализа базы данных и кода приложения.

Импортозамещение: миграция из Oracle в PostgreSQL

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

Поскольку тема импортозамещения сейчас актуальна, и у бизнеса есть такой запрос, мы в SimbirSoft готовы делиться нашей экспертизой и практическим опытом. Сегодня затронем тему миграции из Oracle в PostgreSQL.

Для кого актуально?

Oracle – качественный инструмент, но дорогостоящий в лицензировании и поддержке. Не каждая компания может себе его позволить.

На фоне новостей об уходе из России тема миграции из Oracle на системы управления базами данных с открытым исходным кодом, прежде всего PostgreSQL, становится все более актуальной. Только за последний месяц количество поисковых запросов в wordstat.yandex по теме Postgres превысило 66 тысяч. Хотя переход на эту СУБД в России начался уже давно. За последние несколько лет многие отечественные компании стали использовать PostgreSQL.

Почему Postgres подойдет для миграции из Oracle?

Postgres отличается высокой надежностью и хорошей производительностью. Сейчас это одна из самых продвинутых баз данных с открытым исходным кодом в мире. Среди известных мировых компаний, которые ей пользуются: Apple, Etsy, Red Hat, Skype, Spotify, Yahoo. В целом PostgreSQL подходит от небольших сайтов до крупных корпоративных баз данных.

Благодаря своим достоинствам PostgreSQL – отличная замена нишам, которые ранее занимал Oracle. Поскольку обе базы используют транзакционный лог для защиты информации, построены на версионных движках, поддерживают бекапы и репликацию.

Postgres подходит для сложных операций с большими объемами постоянно обновляющихся данных. Система не подведет в чрезвычайных ситуациях.

Что потребуется для миграции на Postgres?

Сроки, объем задач, состав команды и общая стоимость проекта зависят от множества факторов. Как правило, крупные IT-компании подключают к каждому проекту аналитика, который готовит варианты индивидуального решения.

О кейсах по импортозамещению также рассказываем в нашем телеграм-канале – будем рады, если наш опыт окажется вам полезен!

16 показов
4.5K открытий
11 комментариев
Написать комментарий.

В случае, если на Oracle у вас хранились не только данные, но и десятки тысяч строк кода хранимых процедуры для обработки этих данных, то переход будет долгим и мучительным. Особенно, если использовались такие фичи СУБД, как AQ-очереди, автономные транзакции, flashback-запросы, партиционирование, кэширование.

Развернуть ветку

Придётся пострадать. Но это того стоит. Зависеть от западных компаний в текущем мире опасно

Развернуть ветку

Будем зависеть от наших или всё же каждая компания напишет наконец-таки свою СУБД под свои цели?

Развернуть ветку

Очень странная статья — поднято три вопроса и ни одного ответа на них.
Предлагаю коротенькие варианты ответов, чтобы следующие заходящие получили от потраченного времени хоть какую-то пользу.
1. Для кого актуально (вероятно импортозамещение Оракла Постгрёй).
Видимо для тех, у кого уже имеются проекты на Oracle и они планировали запускать новые проекты тоже на нем, однако пришли к выводу, что риски поддержки текущих и новых проектов слишком высоки и следует активизировать поиск альтернативных вариантов.
2. Почему Postgres подойдет для миграции из Oracle.
Ну конечно же вовсе не по тем причинам, что указаны в статье. Основными причинами могут стать (при поиске альтернатив, в составе полного перечня требований):
* Наличие в России опыта и доступность специалистов с соответствующим опытом по миграции различных проектов из Oracle в Postgres.
* Возможность заключить с российским поставщиком контракт на поддержку класса Enterprise.
* Наличие развитого (в т.ч. доступного бесплатно) инструментария по трансляции БД включая код (исполняемые процедуры) из Oracle в Postgres QL
* Наличие как бесплатных материалов для самообучения, так и сертифицированных курсов по разработке и поддержке проектов с использованием Postgres.
3. Что потребуется для миграции на Postgres?
Ну конечно же не общие сентенции указанные в статье. Потребуется (как мне кажется из первоочередных):
1. Собственно решение об отказе от Oracle, в каком объеме и с какими сроками (к примеру, все новые сервисы запускаются на реплике данных под управлением другой БД, а сервисы использующие Oracle заменяются по остаточному принципу, становясь легаси).
2. Анализ текущего технологического стека, формирование перспективного технологического стека и архитектуры (предприятия, платформы, сервиса, приложения).
3. Разработка, согласование и запуск мероприятий по переходу от легаси стека/архитектуры к целевым стеку и архитектуре.

Вот на 3-м пункте могут понадобиться услуги ИТ-консалтеров, но судя по тому туману, что налил автор статьи, к его компании я не рекомендовал бы обращаться.

Развернуть ветку

Александр, благодарим за ценные дополнения. Автор не посчитал необходимым говорить о преимуществах перехода на PostgreSQL, поскольку эта информация и так есть в широком доступе, а те компании, которые задумались о миграции, знают, зачем им это нужно. Цель материала — напомнить об альтернативах. Мы работаем с самыми разными запросами на импортозамещение и решили делиться опытом.

Развернуть ветку

А разве postgres разрабатывают в РФ?

Oracle vs PostgreSQL. Почему выбор Oracle может быть разумным решением

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

Цель статьи зародить зерно сомнения в душе читателя, который пытается сделать выбор между реляционными БД которые работают в режиме версионника. Почему именно режиме версионника? Здесь выбор не большой, а в блокировщиках есть достойные соперники и выбор еще сложнее.( Чего только стоит бесплатная версия DB2 для небольших БД).

Я не являюсь экспертом БД Oracle хотя и проработал с этой БД много лет и не только с ней. Все что я умею — использовать ее преимущества и добиться оптимального быстродействия. Я тем более не являюсь экспертом PostgreSQL (я не разу не использовал его в продакшене).

Читая статьи об успешной миграции — я понимаю что этим компаниям и не нужен был Oracle или БД была выбрана изначально не верно. Они использовали только малую долю возможностей этой БД. Только поэтому они могли принять решение об миграции, и его осуществить. Просто если использовать всю мощь этой БД — у вас никогда не возникнет желания мигрировать ибо это сродни написать ваше приложение почти с нуля.

Давайте, наконец, поговорим о тех преимуществах для быстродействия, которые дает Oracle и на основании этой информации Вы найдете ответ для себя сами.

1. Partition(8i). Partition — дает возможность роста объема данных практически без влияния на общее быстродействие. Приятный и немаловажный бонус — партицирование индексов. У PostgreSQL партиции появятся только в 10 версии. До этого наследование (INHERITS) — грязный хак. Да и возможности партицирования в Oracle возрастают с каждой версией.
2. Merge(8i). Да да, тот самый Merge который есть уже в MSSQL много лет(2008) и которого не будет даже в PostgreSQL 11. Он дает прирост в быстродействии в десятки раз по сравнению с одиночными операциями. Да я знаю что PostgreSQL поддерживает подзапросы и можно все реализовать через Insert select и хитрый update. Но это далеко не тоже самое.
3. RESULT_CACHE (Select) (11g). У Oracle эта технология появилась относительно недавно. Если использовать эту технологию с умом — дает выигрыш в некоторых вещах в десятки и сотни раз. Главное научиться “умно” ее использовать.
4. Опция INMEMORY (12с) Нет аналога у PostgreSQL. Реальный прирост на некоторых запросах сотни раз.
5. Оптимизатор + тюнинг запросов. Начиная с 11g превратился чуть ли не в клик next->next в EM. PostgreSQL с этим посложнее да и отсутствие в целом аналога EM достаточно некомфортно.

• Компиляция. В байкод происходит во время сохранения (в PostgreSQL во время первого вызова в сессии + план запроса во время первого исполнения). Начиная с 10g в Oracle возможна компиляция в нативный код.
• Нативный Integer — значительно ускоряет работу с числами. В PostgreSQL можно использовать другие более подходящие языки(трансляторы). В оракла это тоже можно решить с помощью Java и С.
• Переключение “контекста” PL/SQL. Oracle очень заботится об оптимизации этого показателя, улучшая его от версии к версии. Для уменьшения задержек Переключение “контекста” придумати BULK COLLECT and FORALL и не только.

Я почти уверен что при одинаковом железе и использовании всех возможностей PostgreSQL и Oracle можно получить лучшее быстродействие, при меньших усилиях на ORACLE.

P.S. Ни в коем случае не рассматривайте эту статью как пиар БД Oracle.

Я хорошо понимаю, что обязательно есть вещи которые в PostgreSQL сделаны лучше. Но в целом Oracle в этом сегменте БД №1.

Я специально не затрагивал вещи связанные с администрированием. Просто представьте что вы можете перенести дата файл с диска на диск или восстановить «битый блок» в состоянии Online. И можете осуществить переход на новые сервера без остановки работы БД. И это не новые фичи. У Oracle там все намного лучше, да и я не являюсь админом БД.

Раньше, где то до 10 версии, админ был нужен практически всегда. Сейчас потребность в админе сильно упала, правда и квалификация админа сейчас нужна повыше. Возможно, в версии эдак 15, понятие “admin” БД уйдет в прошлое 🙂

Да и Pl/SQL продуманнее других, хотя конечно это и не C# :). Правда, это сугубо индивидуально.

Ну и я не затрагивал вещи, которые слабо помогают в быстродействии.

P.S.S. И да, я навряд ли я вспомнил все возможности. Только те которые были на “поверхности” Так что дописывайте в комментах. Я включу в upd.