Если вы стоите перед выбором между PostgreSQL и Oracle DB, то эта статья для вас. Разберем где PostgreSQL побеждает Oracle. Будет код и примеры — всё, что нужно для практического сравнения.
P.S: эта статья не про то, какой PSQL хороший в отличии от Oracle, а про то, в чем PSQL по мнению автора лучше.
PostgreSQL как подарок судьбы
Начнём с самого очевидного: PostgreSQL — бесплатный и Open Source. Это очень приятный бонус. Вы получаете всю мощь системы без необходимости покупать лицензии, платить за дополнительные модули или беспокоиться о процессорных ограничениях.
Oracle DB работает иначе. Вы платите за каждое ядро, за кластеризацию, за функции вроде Oracle Spatial или GoldenGate. Иногда суммы доходят до сотен тысяч долларов в год.
Помимо этого, за счет Open Source у PSQL намного лучше развивается сообщество.
Индексация
PostgreSQL предлагает потрясающую гибкость в индексации. Помимо стандартного B‑tree, можно использовать:
GIN — для работы с JSONB или массивами.
GiST — для пространственных данных и полнотекстового поиска.
BRIN — если у вас огромные таблицы с миллиардами записей.
Пример GIN‑индексации в PostgreSQL:
CREATE INDEX idx_orders_data ON orders USING GIN (data);Теперь можно искать вложенные элементы JSON с достаточно высокой скоростью.
Расширяемость
Расширяемость PostgreSQL — это не просто удобная фича, а одна из основных причин, почему эту СУБД выбирают для сложных и нестандартных задач. Oracle тоже поддерживает расширения и дополнительные функции, но с некоторыми отличиями:
Например, существует PostGIS — мощное расширение для работы с геоданными. Оно имеет множество инструментов для работы с пространственными объектами, такими как точки, линии и полигоны. Пример кода:
CREATE EXTENSION postgis;
CREATE TABLE locations (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
geom GEOMETRY(Point, 4326)
);
-- Добавляем точку
INSERT INTO locations (name, geom)
VALUES ('Гора Фудзи', ST_SetSRID(ST_MakePoint(138.7274, 35.3606), 4326));
-- Найдём ближайший объект к заданным координатам
SELECT name
FROM locations
ORDER BY ST_Distance(geom, ST_SetSRID(ST_MakePoint(138.73, 35.36), 4326))
LIMIT 1;Oracle предлагает схожий функционал через модуль Oracle Spatial. Пример работы с пространственными данными:
CREATE TABLE locations (
id NUMBER PRIMARY KEY,
name VARCHAR2(100),
geom SDO_GEOMETRY
);
CREATE INDEX locations_geom_idx ON locations (geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
-- Вставка точки
INSERT INTO locations (id, name, geom)
VALUES (
1,
'Гора Фудзи',
SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(138.7274, 35.3606, NULL), NULL, NULL)
);
-- Поиск ближайшего объекта
SELECT name
FROM locations
WHERE SDO_NN(geom, SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(138.73, 35.36, NULL), NULL, NULL), 'sdo_num_res=1') = 'TRUE';PostGIS: бесплатно, простое подключение через CREATE EXTENSION. Большой набор функций.
Oracle Spatial: требует лицензии, синтаксис сложнее, а производительность может проседать на больших данных из‑за высоких накладных расходов.
Помимо этого PostgreSQL имеет Foreign Data Wrappers для подключения к другим базам данных (включая Oracle), файловым системам и REST API. Это стандартная функциональность, которая легко настраивается.
CREATE EXTENSION oracle_fdw;
CREATE SERVER foreign_oracle_db
FOREIGN DATA WRAPPER oracle_fdw
OPTIONS (dbserver '192.168.1.10/oracledb');
-- Импорт таблиц из Oracle
IMPORT FOREIGN SCHEMA public
FROM SERVER foreign_oracle_db
INTO local_schema;
-- Работаем с удалёнными данными как с локальными
SELECT * FROM local_schema.some_table;А вот в Oracle интеграции с PostgreSQL или другими источниками данных используется Oracle Database Gateway и этот инструмент не включён в базовую поставку, требует отдельной лицензии и дополнительной настройки.
А теперь допустим, что нужно реализовать функцию, которая принимает JSON‑данные, извлекает из них определённое поле и возвращает его в виде строки.
В PostgreSQL это можно сделать очень просто с помощью встроенного типа JSONB и функций для работы с JSON.
CREATE FUNCTION extract_json_field(data JSONB, key TEXT) RETURNS TEXT
AS $$
BEGIN
RETURN data->>key;
END;
$$ LANGUAGE plpgsql;
-- Пример вызова
SELECT extract_json_field('{"name": "Kolya", "age": 30}'::JSONB, 'name');
-- Результат: KolyaВ Oracle работа с JSON поддерживается через PL/SQL и требует более сложного синтаксиса. К тому же необходимо предварительно убедиться, что JSON правильно проанализирован.
-- Создаём функцию для извлечения поля из JSON
CREATE OR REPLACE FUNCTION extract_json_field(
data IN CLOB,
key IN VARCHAR2
) RETURN VARCHAR2 IS
json_obj JSON_OBJECT_T;
BEGIN
-- Преобразуем CLOB в JSON-объект
json_obj := JSON_OBJECT_T.parse(data);
-- Возвращаем значение по ключу
RETURN json_obj.get_string(key);
EXCEPTION
WHEN OTHERS THEN
RETURN NULL; -- В случае ошибки возвращаем NULL
END;
/
-- Пример вызова
DECLARE
result VARCHAR2(100);
BEGIN
result := extract_json_field('{"name": "Kolya", "age": 30}', 'name');
DBMS_OUTPUT.PUT_LINE(result); -- Результат: Kolya
END;
/Проблема в том, что этот объект нельзя будет использовать с большинством стандартных функций, и вам придётся писать свои собственные методы для каждой операции.
Масштабируемость и репликация
PostgreSQL имеет свободу выбора: стриминговая репликация, логическая репликация, шардинг с помощью Citus. Всё это бесплатно.
# Включаем репликацию в конфигурации
wal_level = replica
max_wal_senders = 10Oracle, конечно, тоже умеет масштабироваться, но за это придётся платить: GoldenGate, RAC — это всё про деньги.
Итог
PostgreSQL выигрывает у Oracle DB по следующим пунктам:
Стоимость: бесплатный, без лицензий.
Типы данных: JSONB, массивы, уникальные индексы.
Индексация: гибкость, скорость, оптимизация.
Расширяемость: плагины и модули, такие как PostGIS.
Масштабируемость: удобные и бесплатные инструменты.
Простота интеграции: с языками вроде Python, Go и Java.
Oracle DB остаётся сильным игроком для крупных корпораций с большими бюджетами и жёсткими SLA, это часто оправдано благодаря поддержке и интеграции с другими инструментами. Но PostgreSQL предлагает почти тот же уровень функциональности (а где‑то и превосходит) без огромных затрат.
А какое решение лучше на ваш взгляд? Если остались вопросы — пишите в комментариях.
И приходите на бесплатный вебинар «Python для миграции данных: Oracle <-> PostgreSQL». А на странице курса можно посмотреть записи предыдущих материалов.
Комментарии (66)
mc2
18.11.2024 01:14А где выигрыш то? В тексте говорится что Оракул умеет тоже самое.
Плюс заявление что база бесплатная, мягко говоря, не верное, потому что за "бесплатно" нужно будет иметь людей, которые будут работать над решением проблем, в случае которых у Оракула это входит в стоимость поддержки.
igorts
18.11.2024 01:14Наличие поддержки у Oracle, это в первую очередь доступ к базе знаний и заплаткам, при это цена поддержки 22% от стоимости лицензии в год.
И наличие этой поддержки не означает, что будут решать вашу проблему, а всего лишь право оформить баг и ждать, что его когда нибудь пофиксят…
А с учетом постоянно снижающейся популярности Oracle, скоро найти грамотного админа станет весьма проблематично и дорого.
Я раньше был фанатом Oracle, но в последние годы максимально стараюсь его избегать!
FancyStacy
18.11.2024 01:14С фиксами для слона та же история, можно годами ждать, что кто-то возьмётся за ваш кейс, либо просто нанять армию разработчика и пилить свои патчи самостоятельно. Хз что ещё после этого выйдет дешевле.
c0r3dump
18.11.2024 01:14И наличие этой поддержки не означает, что будут решать вашу проблему, а всего лишь право оформить баг и ждать, что его когда нибудь пофиксят…
Что также можно сделать у постгре за бесплатно. Интересно бы сравнить скорость исправления схожих проблем, но у меня нет данных.
funca
18.11.2024 01:14Ну да, если у вас есть бесплатные программисты и бизнес ни куда не торопится, чтобы заниматься поддержкой собственного форка.
qweururu
18.11.2024 01:14Нет, очевидно даже близко того же самого там нет. Даже этот элементарный пример: x->>y vs x.get_string(y). Туда же касты.
qweururu
18.11.2024 01:14Кстати, пример с жсоном в статье манипулятивный. В пг там не нужна отдельная функция, можно прямо в запросе всё сделать(select '{ ... }'::json->>'key'). Это также проявление разных подходов(когда об удобстве, как одной из основных фич, думают и когда просто выкатывают хоть как-нибудь работающую поделку).
c0r3dump
18.11.2024 01:14А вы пробовали эту поддержку получить-то? Илм как будто с этой поддержкой прям dba не нужен? Да и люди за знание оракла тоже часто хотят больше денег так как знают, что это дорого-богато.
zuek
18.11.2024 01:14Непосредственно по ораклу не обращался, но по SAP@Oracle довелось как-то - решение было предоставлено в течении дня, и даже отсутствие "действующей поддержки" не остановило интегратора от помощи (продукт на момент обращения носил архивный статус, и поддержку никто не оплачивал уже несколько лет). В принципе, и от ПостгресПро я получал помощь, не будучи их клиентом - пусть просто в формате "вопрос-ответ", но очень помогли.
FancyStacy
18.11.2024 01:14Звучит неубедительно, это скорее какая манера самовнушение человека, у которого нет денег на лицензию.
qweururu
18.11.2024 01:14Ну подобные тезисы слишком слабы. Купившему лицензию признать свой выбор несостоятельным ещё сложнее, ведь тогда ему нужно будет сказать что-то навроде "я лох, отдал деньги за мусор" - это более позорно, нежели "нет денег". Поэтому персонажи с лицензией ещё более ангажированы, чем те кому карман не позволяет сделать выбор полноценный.
FancyStacy
18.11.2024 01:14Мне кажется, ваша лексика выдаёт в вас человека, в принципе не сталкивающегося с задачами, где нужна СУБД Oracle. Разумеется, какому-то провинциальному интернет магазину достаточно и бесплатной мариядб с вашими услугами администрирования, чтоб его владелец не чувствовал себя лохом. Как говорится "дёшево и сердито"
qweururu
18.11.2024 01:14В очередной раз ни единого возражения. И да, лексика выдаёт - это прям сильно. Но то ладно. Главное здесь в другом.
Здесь в комментариях 90% - это судя по всему дба или подобные. Как и прочие админы/эникейщики и ниже, они не особо имеют выбор, поэтому все обсуждения сводятся к статистическому подходу - поменял какой-либо компонент на аналог => исправилась ошибка/стало побыстрее => значит лучше. Какое-то понимание и поиск причин отсутствует. Обсуждать что-то в таком разрезе смысла не имеет. Поэтому просто расскажу про рсубд, для информации.
В целом, рсубд и подобные вещи не особо нужны.
auto fd = open("data", O_RDWR); auto data = (ftruncate(fd, 10Tb), mmap(nullptr, 10Tb, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0));Всё, у меня есть самая мощная и быстрая бд в мире. Среди прочего у меня здесь нормальный интерфейс к этой бд, а не sql. Проблема здесь в том, что для такой бд нужен нормальный язык, а большинство языков не умеют работать с памятью. Многие из них вообще понятия не имеют, что существует какая-то память, а этой памятью там рулит рантайм(зачастую с гц, но не обязательно). Вот рсубд даёт возможность подобным языкам хранить относительно много данных и рулить ими с более-менее приемлемой(для пхп/жавы) скоростью.
Главным свойством в подобном сценарии использования является простота/удобство/фичи(готовые, чтобы дёрнуть api и бд сама бы всё сделала). Какой-то производительности здесь и так не будет. Выше я приводил пример из статьи с ->>, правда тут почти все комментаторы дба, а они в подобных вещах не шарят.
Что имеем в пг: операторы, нормальные касты, перегрузку, транзакции хоть недельной длительности(в том числе для ддл и почти всего прочего), фичи навроде "exclude using gist (id with =, (tsrange(start, finish)) with &&)", подзапросы в любом(или почти) месте и прочее. Автокасты правда не завезли, в mysql вроде были - это минус пг.
Что имеем в оракл: быстрое(по меркам рсубд) исполнение элементарных запросов вида "select a from b where c". И может быть бекапы/репликация более быстрые/простые(тут не знаю). Остальное сделано на отвали, чтобы номинально оно было и можно было бы заявить поддержку фичи. Даже терминал нормальный не осилился(вместо него sqlplus).
Тут есть один момент, о котором можно было бы поспорить: выполнение кучи простых запросов может иметь смысл и делать использование бд удобнее, в контексте типичного паттерна "select id ..."(поиск тысяч id) с последующим "foreach id { update ... where id = :id }". Это действительно проще и удобнее если бд подобное переваривает. Но об этом никто не сказал, предпочитая рассказывать про нагрузки и скорость(которые просто игрушечные для mmap-бд из файлика выше).
mvv-rus
18.11.2024 01:14По-моему, это не самовнушение, а способ, спровоцировав возобновление старой "священной войны", привлечь внимание к статье в корпоративном блоге, целью которой является продажа очередных курсов.
Право на такую манипуляцию автор и стоящая за ним организация имеют: они честно заплатили за это влаельцам Хабра. Ну, а вестись ли на эту манипуляцию - личное дело каждого.
PS И таких статей, которые пытаются возобновить древние священные войны, я в корпоративных блогах на Хабре вижу немало. Что ж, владельцы блогов заплатили за свое право их публиковать, так что осуждать их не за что.FancyStacy
18.11.2024 01:14Сейчас появилась мода отказываться от оракла в пользу всякого разного хлама, чтоб хлебнуть лиха и вновь вернуться к стабильному и надежному решению. Взять к примеру Uber, они спрыгнул на постгре, с полгода побились головой об стену и поняли что транзакционная модель оракла куда производительнее и надёжнее, а падение прибыли из-за сбоев и деградации производительности не перекрываются выиграшем по костам на лицензиях оракла.
Отсюда и такие статьи адептов слонов.
mvv-rus
18.11.2024 01:14Отсюда и такие статьи адептов слонов.
Мне вы ответили напрасно: я в "священных войнах" не участвую из принципа.
nikitozzz05
18.11.2024 01:14В Oracle можно работать с json и через SQL. Например так:
select json_value('{"name": "Kolya", "age": 30}', '$.name') xxx from dual
newintellimouse
18.11.2024 01:14Спасибо, мне это надо.
Скажите пожалуйста, а насколько это тяжёлый запрос?
sshikov
18.11.2024 01:14А что в нем тяжелого? Это просто функция, выполняемая на каждой строке результата. Ну будет потреблять сколько-то процессора. Как любая функция.
FancyStacy
18.11.2024 01:14Есть же разные функции, какие-то выполняются моментально, а какие-то могут оказывать существенное влияние на утилизацию ресурсов. Так же, как бывают хорошие и не очень планы выполнения запроса. В прочем, функционал работы с джесонами довольно свежий, не удивлюсь, если его работа ещё не оптимальна. Надо полагать, у вас есть опыт работы с этой функцией, поделитесь впечатлениями, пожалуйста
sshikov
18.11.2024 01:14В вопросе речь о совершенно конкретной хорошо определенной функции над json. Которая по сути внутри представляет из себя JsonPath. На план запроса она никак влиять не может. Цена исполнения - C * число строк. Множитель C наверное не константа, это в примере json константой задан, а в реальности он скорее всего будет значением колонки таблицы (т.е. может быть разной структуры и размера). Ну т.е. тут речь скорее всего о том, какова производительность JsonPath на разных JSON и выражениях (которое тут в примере $.name).
redfox0
18.11.2024 01:14The JSON data type was introduced in the Oracle 20c preview release to provide native JSON support and improve the performance of JSON processing. It has become generally available in Oracle 21c.
Sabirman
18.11.2024 01:14По моему опыту, PostgreSQL сейчас не дотягивает даже до Oracle8i конца 90х:
1.Вечные проблемы с вакумом - на больших таблицах проход автовакума происходит один раз в несколько дней. Всё это время копятся копии изменившихся записей. Это не позволяет просто так использовать всевозможные агрегаты, очереди и т.д. - что кардинально изменяет подход к работе с этой СУБД и сильно её усложняет
2.Отсутвие физической сортировки данных, с одной стороны, на порядок повышает количество рандомных чтений с диска, а с другой - на порядок снижает эффективность кэша (ради одной записи кэшируется целый блок). В итоге PostgreSQL при своей работе требует в 100 раз больше оперативной памяти, чем Oracle.
3.Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
а) PostgreSQL регулярно выбирает неверный план исполнения в результате ваш запрос периодически беспричинно сбоит - имеем кучу бессонных ночей
б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
4 Из-за слабых возможностей СУБД предлагается использовать секционирование и шардирование. Это, в свою очередь ломает всю теорию реляционных баз данных, что опять-таки приводит к резкому снижению надежности системы и резкому повышению сложности программирования под неё.
5 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
rPman
18.11.2024 01:14б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
Вы можете подробнее рассказать про такие случаи?
Sabirman
18.11.2024 01:14Не хотелось бы углубляться в эту довольно грязную тему. Ну вот, например:
-- равносильно field = $1::uuid, но теперь pg не знает, что здесь константа
field = split_part($1::uuid::text || '_' || field2, '_', 1)::uuid and ...
rPman
18.11.2024 01:14Использование uuid объектов как то ломает оптимизацию?
Можно пояснить, а зачем такую сугубо внутреннюю вещь как идентификатор объекта вообще использовать, тем более вытаскивать ее на верхний уровень в виде текста? что вообще означает получениеuuid результата вычисления? что тут можно ожидать кроме случайного текста?
Sabirman
18.11.2024 01:14>> что тут можно ожидать кроме случайного текста
Тут обратите внимание, что функция split_part нумерует части строки с единицы, а не с нуля. Т.е. в результате этой функции получаем тот же самый $1::uuid.
Здесь мы запретили PostgreSQL использовать индекс, начинающийся с поля field, т.к. он не может вычислить правую часть выражения до того, как получит значение поля field2.
galaxy
18.11.2024 01:14-- равносильно field = $1::uuid, но теперь pg не знает, что здесь константа
А Oracle 8i знает?
Почему вы хотите от планировщика по сути функциональности оптимизирующего компилятора?
funca
18.11.2024 01:14Google решили массу таких проблем в своём AlloyDB, подняв перфоманс на отдельных тестах в 100 раз.
Проблема в том, что Postgres в опенсорс, готовый из коробки к применению в энтерпрайзах не выгоден его разработчикам. Они и куча вендоров по всему миру кормятся с поддержки, продавая кастомные сборки с исправлением ошибок.
redfox0
18.11.2024 01:14Отсутствие возможности валидировать XML по XSD-схеме;
Отсутствие возможности группировать PL/pgSQL-код по пакетам.
CrushBy
18.11.2024 01:14Хм, мы используем PostgreSQL на проектах, в которых бывает по одной-две тысячи одновременно работающих пользователей. Базы данных несколько терабайт. В таблицах сотни миллионов и миллиарды записей. И там не простое CRUD приложение, а сложные транзакции со сложными запросами, которые одновременно меняют сотни таблиц и тысячи полей. Так что накопился определенный опыт. И все это работает на одиночных серверах с 48 ядрами без какой либо репликации. Да, конечно же с промышленными SSD на СХД.
Возможно "мы как-то не так держим" PostgreSQL, но большинство описанных Вами проблем звучат странно.
Вечные проблемы с вакумом - на больших таблицах проход автовакума происходит один раз в несколько дней. Всё это время копятся копии изменившихся записей.
А в чем проблема настроить автовакуум выполняться чаще ? То есть в общем-то он будет гарантированно срабатывать, как накопился определенный процент изменений. То есть, например, больше 20% - будет запускаться.
Отсутвие физической сортировки данных, с одной стороны, на порядок повышает количество рандомных чтений с диска,
Да, рандомных чтений с диска больше. Но SSD в общем-то пофиг рандомные или последовательные. В shared_buffers да, загружается немного больше, чем если были бы последовательные. Но у такой модели реализации MVCC есть и свои большие преимущества по сравнению с Oracle'овской. Про 100 раз больше памяти из-за этого - это смешно. Даже комментировать не буду.
а) PostgreSQL регулярно выбирает неверный план исполнения в результате ваш запрос периодически беспричинно сбоит - имеем кучу бессонных ночей
Ну отключите nested loop таким запросам. Да, пойдет в hash join и будет чуть дольше, но зависать не будет. И опять же, проблема надуманна. У нас вообще запросы автоматически генерируются платформой - и то повисание бывает очень редко. А если вручную пишутся, то просто читаешь EXPLAIN и смотришь, где PostgreSQL ошибся, и добавляешь индексы/меняешь запрос. Это не так часто надо делать, если запросы не junior писал.
б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
Это не правда. PostgreSQL запросы компилирует в разы быстрее, чем Oracle, так как у него компилятор проще. Но и ошибается чаще. И выполнение у него быстрее, если план правильный (так как там нет перепланирования и прочих штук).
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
Чаще всего надо не хаки использовать, а просто правильно писать запрос. Да, Oracle кривой запрос лучше выполнит, но правильно написанный запрос PostgreSQL тоже в 99% случаев выполнит достаточно оптимально.
4 Из-за слабых возможностей СУБД предлагается использовать секционирование и шардирование. Это, в свою очередь ломает всю теорию реляционных баз данных,
Да, мультимастер репликации там нет из коробки. Но в 99% задач мультимастер и не нужен (да, признаю, что для онлайн обработки транзакций в банке на миллион пользователей PostgreSQL плохо подходит). Например, нам еще нигде не приходилось делать мультимастер (только асинхронные реплики для резерва).
Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle.
Ну исходя из своего опыта - мы прекрасно используем PostgreSQL, и его возможностей хватает, чтобы делать ERP-системы для относительно немаленьких бизнесов с тысячами пользователей, работающих в системе, и все это на одиночных серверах. И не платить ничего при этом ни Oracle, ни Microsoft. Все прекрасно работает в связке Debian / ванильный PostgreSQL.
Да, тут важно учесть, что мы изначально все делали под PostgreSQL. Однако, если взять то, что изначально делалось под Oracle, а потом просто перенести под PostgreSQL, то могут быть проблемы.
ViacheslavNk
18.11.2024 01:14ERP-системы для относительно немаленьких бизнесов с тысячами пользователей, работающих в системе, и все это на одиночных серверах. И не платить ничего при этом ни Oracle, ни Microsoft. Все прекрасно работает в связке Debian / ванильный PostgreSQL.И это нормально, на этом уровне PostgreSQL уже может конкурировать с Ораклом, Оракл плотно держит “лютый экнерпрайз”, всякие телекомы, банки и т.д.
CrushBy
18.11.2024 01:14И это нормально, на этом уровне PostgreSQL уже может конкурировать с Ораклом, Оракл плотно держит “лютый экнерпрайз”, всякие телекомы, банки и т.д.
Вот это странная классификация. У любого лютого энтерпрайза тоже разные процессы есть. И во многих из них возможностей PostgreSQL будет выше крыши. А в количественном выражении таких процессов больше, чем тех, где требуется мультимастер репликация и т.д. И там вполне можно отказаться от Oracle.
Да, понятно, что обработке транзакций в банках без Oracle тяжело. Но там есть еще сотни процессов, где можно спокойно уйти с оракла.
ViacheslavNk
18.11.2024 01:14Вот это странная классификация. У любого лютого энтерпрайза тоже разные процессы есть. И во многих из них возможностей PostgreSQL будет выше крыши. А в количественном выражении таких процессов больше, чем тех, где требуется мультимастер репликация и т.д. И там вполне можно отказаться от Oracle.И да и нет, есть условный крупный банк со своей биллинговой системой с миллионами транзакций построенной на Оракле, есть у них какая то менее серьезная/критичная/нагруженная система, даже не знаю для какой то внутренней аналитики, скрининговой системы, можно ее построить на Посгри, конечно можно, но это потребует в штате человека который знает этот Постгри.
CrushBy
18.11.2024 01:14можно ее построить на Посгри, конечно можно, но это потребует в штате человека который знает этот Постгри.
Там не нужна какая-то супер-пупер квалификация. В большинстве случаев достаточно просто установить, сделать базовые настройки и все будет работать из коробки.
В любом случае, это будет гораздо выгоднее просто за счет лицензий и поддержки оракла.
FancyStacy
18.11.2024 01:14Ну обычно так и делается, но для этого используется не постгря, а даталейк и биай, так как хранение в с3 куда дешевле любой базы даже бесплатной
FancyStacy
18.11.2024 01:14Ну если цель именно никому не платить, то можно смириться с чем угодно и радоваться.
А почему нет репликации? Хозяин такой жмот, что даже стендбай базы не хочет держать на готове, или у вас настолько небогатый опыт, что база ни разу не падала и не приходилось её часами оживлять из бекапа? Ну, если бизнес с тысячами пользователей может себе позволить подождать, тогда все понятно. Жалко мне ваших клиентов.
CrushBy
18.11.2024 01:14Ну если цель именно никому не платить, то можно смириться с чем угодно и радоваться.
Нет, это не цель, а приятный бонус.
А почему нет репликации? Хозяин такой жмот, что даже стендбай базы не хочет держать на готове, или у вас настолько небогатый опыт, что база ни разу не падала и не приходилось её часами оживлять из бекапа?
Некоторые делают асинхронные реплики, некоторые нет. Мы просто никогда не отвечаем за инфраструктуру, а это делают клиенты. И это ответственность их администраторов баз данных. Некоторые настраивают реплику, некоторые нет. Благо сама настройка из коробки ванильного PostgreSQL занимает минут 5 (сам много раз делал).
Что касается падения PostgreSQL, то Вы удивитесь, но ни разу не падал PostgreSQL. Просто ни один крупный клиент не экономит на СХД с RAID'ом. И SSD, как правило, не умирает "внезапно". Там начинает деградировать запись и это обычно видно заранее. Просто СХД сигнализирует, что есть какая-то проблема с конкретным SSD. Админ переключает на другой (обычно держат резерв) и все продолжает работать нормально.
С чего вообще должна порушиться база ? За десять лет и сотни клиентов ни разу не было. PostgreSQL - супер надежный, если с дисками все ок. Но если ручки кривые у администратора (например, если выключить fsync), то конечно будет рушиться постоянно.
QValder
18.11.2024 01:145 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
А из опыта этот вывод как-то подтверждается? У нас есть опыт миграции нагруженных оракловых серверов на постгрес и ни разу миграция не потребовала наращивания железа.
galaxy
18.11.2024 01:14Да никак он не подтверждается. Там все пять пунктов — такой наброс, что у меня глаз дергается.
Кто-то еще плюсует это дело, типа согласны ("ага, ага, дело мужик пишет, вот вчера прям постгрес богомерзкий без терабайта памяти запускаться отказался").
sshikov
18.11.2024 01:14Я бы по четвертому пункту добавил, что формально в постгресе размер таблицы - 32 терабайта, а число таблиц в базе что-то типа миллиона. А де факто у нас в компании рекомендация не делать базу больше 10 терабайт, иначе будут проблемы с бэкапом. В итоге при миграции с оракла на постгрес получается шардированная база из 16 узлов, в то время как в оракле это была одна база, и проблем с бэкапом не было.
Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
Ну вообще хинты-то есть, это вы зря. pg_hint_plan вроде звать это расширение, у нас его по умолчанию везде ставят. Детальнее сравнить не возьмусь. А насчет оптимизатора - согласен. При массовой миграции массово же напоролись на то, что запросы, которые оракл прекрасно оптимизировал, стали работать фигово, потому что оптимизатор например не умеет делать push predicate в подзапрос (впрочем, такая же примерно проблема у наших не особо новых версий MS SQL была).
CrushBy
18.11.2024 01:14Есть по крайней мере одна вещь, где PostgreSQL точно выигрывает у Oracle. Это в скорости компиляции запросов. Мы используем у себя в lsFusion внутренний язык, который затем компилируется в SQL. Но пишут на нем люди, которые не всегда хорошо понимают, как это все будет выполняться (низкий порог вхождения).
Иногда получается так, что компилируются запросы в 2 миллиона символов. Так вот, PostgreSQL умудряется скомпилировать такие запросы, например, за 500 мс, а выполнить за 200 мс. В последнее время, я даже увеличил в некоторых местах лимит на такие запросы до 8 миллионов символов, и они тоже выполняются за более менее адекватное время. В итоге, местами мы даже перестали оптимизировать такой код - зачем, если и так работает, а запрос выполняется редко.
Oracle же на запросе в 2 миллиона символов только компиляцию делал больше 10 секунд, а иногда и вообще уходил в минуты. Что и не удивительно. В PostgreSQL очень простой планировщик. Да, он бывает ошибается. Да, сваливается в Nested Loop. Но зато он очень быстрый в компиляции и выполнении, что бывает более выгодно (хоть и имеет свои минусы).
Помню, как бывало на олимпиадах по информатике, когда кто-то садился и очень быстро писал очень быстрый перебор, и он проходил все тесты (авторы не думали, что он пройдет). А кто-то долго писал правильный алгоритм, но в итоге проигрывал по времени.
AlexeyK77
18.11.2024 01:14Такие поверхностные статьи не писали даже в 90х, на заре становления РСУБД. Печально,
В статье нет самого главного - упоминания области применения БД, объемов данных, характера нагрузки, требованиям к отказоустойчивости, безопасности и т.п. В банках и телекомах постгреса в ядре как-то не видать.Именно за это все ораклу и платят деньги, а движки для вебсайтов конечно же на оракле никто не делает.
DmitryOgn
18.11.2024 01:14Точка зрения из тех самых 90-х. Сейчас Оракл в банках как исторический рудимент, не для нового проекта.
AlexeyK77
18.11.2024 01:14вам бы матчасть изучить. не знаю как сейчас в РФ, но оракл в крупном бизнесе везде и альтернативой ему является только мсскл, может быть еще где-то есть дб2 (про дб2 правда давно ничего не слышал).
ViacheslavNk
18.11.2024 01:14PostgreSQL как подарок судьбыНачнём с самого очевидного: PostgreSQL — бесплатный и Open Source. Это очень приятный бонус. Вы получаете всю мощь системы без необходимости покупать лицензии, платить за дополнительные модули или беспокоиться о процессорных ограничениях.Ну это же не серьезный аргумент, даже не имеет смысла его упоминать при техническом сравнении, бизнес для которого покупка лицензии Оракла дорогая, скорее всего не имеет тех объемов данных и тех нагрузок для которых ему в принципе нужен Оракл.
Mapar
18.11.2024 01:14Полностью согласен. Open Source в итоге приводит к двум вариантам:
внутри компании появляется "как бы вендор" который отвечает за сборку
выбирается вендор типа Postgres Pro
Оба варианта имеют свои плюсы и минусы ... но оба не бесплатные ( в первом случае ЗП и риски в случае ошибки или не вовремя закрытой уязвимости, во втором такая же модель оплаты как с Oracle)
Mapar
18.11.2024 01:14В целом текст не своевременный. Я понимаю, что если не попадать под регулирование, Oracle "лучшая бесплатная СУБД" в России (как в 90х), но в целом серьезный бизнес все же хочет ТП, тот же Oracle не возможно использовать без патчей. Так что тут выбор в пользу Postgre SQL очевиден (опять же в пользу скорее вендорских решений, типа Postgre Pro), и все остальное пустое.
Если технически, на мой взгляд, 7 основных вопросов к PostgreSQL относительно Oracle если сравнивать:
1. Богомерзкий MVCC (vacuum, bloat, отсутствие версионирования в индексах)
2. Партиционирование (отсутствие глобальных индексов и все что за собой тянет, нет автосоздания партиций, плюс тормоза на большом количестве партиций)
3. Зависимости (dependicies). Тут можно спорить нужны хранимки или нет, но если используете те, то тут Oracle c механизмом зависимостей побеждает
4. Мониторинг - тут все просто, Oracle дает гораздо больше телеметрии (AWR, ASH, SQL Monitor) по сравнению с PostgreSQL, вплоть до контроля плана выполнения в реальном времени, да такое есть в Postgres Pro (но мы то тут про ванилу, а Postgres Pro не торопится такие фишки отдавать в Open Source).
5. Кэш запросов, оутлайны и хинты. В Oracle это есть и не возникает ситуация, когда на 50 Тб базе вдруг после очередного сбора статистики поехали планы.
6. Exadata - тут все просто, сопоставимого решения для Postgres SQL нет, оно можно вспомнить про Greenplum/Citus, но Exadata умеет в обе нагрузки OLTP и OLAP, а с PostgreSQL обе задачи не закрывает, тут надо бить решение на части.
7. Golden Gate - ничего сопоставимого нет от Open Source, Debezium - жалкое подобие и 10% от функционала и скорости.
QValder
18.11.2024 01:14"Богомерзкий MVCC" нельзя считать абсолютным злом - зависит от способа использования. Конечно bloat это плохо, зато без проблем выполняются долгие запросы. В Оракле на нагруженной базе долгие запросы приводят к snapshot too old, а большие апдейты вообще противопоказаны, поскольку могут закончиться переполнением undo tablespace и длительным откатом с блокировкой таблицы.
К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.ViacheslavNk
18.11.2024 01:14К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.Да в итоге тот же Оракл и получится, когда потребуются петабайты, кластера, репликация, и пр, все эти расширения так же нужно будет поддерживать, править баги и т.д, что потребует денег не меньше чем покупка лицезии на Оракл.
Mapar
18.11.2024 01:14Про "не mvcc" хранилища давно слежу, и EDP пыталось, по zheap новостей уже лет 5 нет. Реально там скорее всего все упирается, в то что индексы не версионируются.
В Oracle undo управляемое зло, в PostgreSQL - MVCC не управляем, стандартная беда на фоне долгой транзакции регулярно меняется одна строка (например, остаток на счету кассы) и привет... в индексе на одну строку 100500 записей и столько же записаей в heap и оно быстро не лечится. В оракле у вас со snapshot to old слетит сам долгий запрос, в PostgreSQL раком встанет вся система.
mvv-rus
18.11.2024 01:14К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.
Вообще-то, у PostgreSQL изначально не было MVVC-хранилища - и я помню время, когда некто Бартунов (наверняка, многим тут известный) выбрал Interbase в качестве СУБД для сайта: пусть и идеологически чуждый - ибо (на тот момент) не Free и даже не Open Source, а всего лишь бесплатный - но зато поддерживавший ту самую многоверсионность, котрая сайту была нужна по условиям эксплуатации (заливка новой информации из БД фронт-офисной программы параллельно с работой сайта).
Но это было, ну, очень давно.
sshikov
18.11.2024 01:14Golden Gate - ничего сопоставимого нет от Open Source, Debezium - жалкое подобие и 10% от функционала и скорости.
StreamGate. SIDEC. Не уверен, что и то и другое можно даром, но в целом они уже близки к GG оба. Не opensource ни разу. Но ведь и OGG тоже же не.
DarthVictor
18.11.2024 01:14У Postgres для большинства людей следующие реальные достоинства в сравнении с Oracle.
Postgres доступен для жителей РФ и РБ нормально в условиях санкций и для жителей других стран внутри за вменяемую стоимость AWS / Azure / GCP.
Postgres дешевле в обслуживании как managed так и self-hosted.
Postgres чаще встречается в вакансиях, как следствие разработчиков знакомых с Postgres найти проще.
Postgres нормально работает с разряженными данными из-за поддержки BJSON, что позволяет не иметь по 30-50 лишних и на 95-99% пустых колонок.
Достоинства оптимизатора Oracle для сложных запросов или скорость парсинга у оптимизатора Postgres, про которые пишут выше, - ненужные абсолютному большинству проектов детали. Если вы на них наткнулись, то скорее всего ваш проект ху...во написан. Например вы решили использовать OLTP РСУБД для OLAP запросов. Не важно, будет ли Oracle или Postgres быстрее в 2 раза там, где нормальная колоночная СУБД будет быстрее в 30 раз. Истории про запросы на несколько часов или селект-запросы на несколько мегабайт, весело читать на Хабре, но не видеть в своей кодовой базе.
В целом, я плохо понимаю, кому из пользователей Хабра в в 2024 году может понадобится Oracle на новом проекте. Если вы работаете на компанию из РФ или РБ, то это сомнительно с точки зрения complience. Для работающих на иностранные компании польза тоже непонятна - выходца из БССР позовут скорее всего в бигтех или стартап, где Oracle тоже вряд ли будет. То что админы Oracle ещё 20 лет будут зарабатывать, поддерживая легаси проекты, вас волновать не должно (если вы сами не имеете хотя бы 3+ опыта с Oracle), это закрытый рынок с должностями под конкретных людей.
ViacheslavNk
18.11.2024 01:14В целом, я плохо понимаю, кому из пользователей Хабра в в 2024 году может понадобится Oracle на новом проекте.Зависит от проекта, если бэкенд веб магазина то да, если ядро телекома, то посгресс просто может не потянуть.
Если вы работаете на компанию из РФ или РБ, то это сомнительно с точки зрения
complience.А если через год, два, пять лет, начнется новая оттепель, перестройка, перезагрузка? И я правильно понят, что основной ваш аргумент, что сейчас Оракл хуже Посгри именно из-за политики, я не против такого аргумента, но просто нужно признать что технически Посгри еще сильно отстаёт от Оракла.
QValder
18.11.2024 01:14Мы вот телеком и да, постгрес вполне тянет (в отличие от мускуля кстати). И невозможно себе представить что могло бы нас заставить вернуться на Оракл, независимо от политики.
Да, в целом Оракл получше, но с учетом его стоимости и отсутствия принципиальных преимуществ его использование оправдано только для обработки очень высокомаржинальных (с большой выручкой на байт) данных.Sabirman
18.11.2024 01:14Можете рассказать, во что вы уперлись с MySQL. А то вот Uber, например, наоборот предпочла MySQL: https://habr.com/ru/companies/slurm/articles/322624/
QValder
18.11.2024 01:14Мускуль проигрывал постгресу по производительности на всех основных типах запросов кроме массовых (не атомарных) апдейтов. Раздражала его способность выжирать память свыше значений в настройках innodb, что требовало периодических перезапусков.
Но решающее значение имел факт систематических крашей баз данных, содержащих партиционированные таблицы при достижении неких критических нагрузок: объяснения этому так и не нашлось и на этом доверие к этому изделию было окончательно утрачено.CrushBy
18.11.2024 01:14Раздражала его способность выжирать память свыше значений в настройках innodb, что требовало периодических перезапусков
PostgreSQL тоже этим страдает, кстати. Мы для этого в автоматическом режиме время от времени закрываем/открываем соединения, чтобы процессы перезапустились и память очистилась.
Но надежность PostgreSQL действительно выше всяких похвал.
DarthVictor
18.11.2024 01:14Во-первых, что такое "ядро телекома", и зачем ему именно реляционная СУБД? Как это "ядро" будет шардироваться? А то есть подозрения, что там основные данные будут в какой-нибудь Kafka сохраняться и дальше по разным системам растаскиваться.
А если через год, два, пять лет, начнется новая оттепель, перестройка, перезагрузка?
То Oracle в следующий раз выберут в лучшем случае лет через 20. Потому что все разработчики на локальном рынке уже переучились на другие СУБД и другие архитектуры.
просто нужно признать что технически Посгри еще сильно отстаёт от Оракла
Безусловно. Но это не значит, что кто-то возьмёт Oracle вместе Postgres. Возьмут Kafka и поставят его перед несколькими инстансами Postgres/MariaDB и ClickHouse. СУБД - это не вещь в себе. Это часть инфраструктуры. Сбер тот же ещё в 2018 активно съезжал с Oracle на Postgres. Нафига ему съезжать обратно?
ViacheslavNk
18.11.2024 01:14Но это не значит, что кто-то возьмёт Oracle вместе Postgres. Возьмут Kafka и поставят его перед несколькими инстансами Postgres/MariaDB и ClickHouse.Ну в итоге то решение не дешевле (если не дороже Оракла) если мы говорим про большие объёмы данных, требования к надежности, отказоустойчивости, и т.д.
Сбер тот же ещё в 2018 активно съезжал с Oracle на Postgres. Нафига ему съезжать обратно?Сбер компания богатая может позволить себе платить за условный Platform V Pangolin и я к слову не вижу в этом ни чего плохого, разрушат монополию Оракла, я не против, но сама суть останется той же, хочется чего то сопоставимого с Ораклом, придётся платить плюс минус как за Оракл, не Ораклу, так вендору Посгри, не вендору, так содержать свой отдел разработки и поддержки.
anaxita
Кажется в разделе индексации не хватает информации, чем проигрывает Oracle