Комментарии 88
Кажется в разделе индексации не хватает информации, чем проигрывает Oracle
В статье смещены акценты, в комментариях поддались на эту провокацию, и обсуждают фичи, возможности, глюки того или иного решения, когда как для бизнеса важно только одно - цена, а точнее итоговый баланс затрат и доходов.
Если затраты на поддержание работоспособности бизнеса не превышают доходов, то решение оправдано. Если потери, от простоя из-за глюков, тормозов или еще каких особенностей, выше доходов за этот срок, значит это решение не подходит.
Все остальное - не важная мишура! Удобство разработки, производительность на единицу железа (с учетом его стоимости само собой) - это все не важные вещи.
Есть компании (чаще всего крупные или гос-компании) для которых документ о поддержке, со страховыми суммами, важнее чем сама стоимость, в конечном счете, любая стоимость затрат просто ляжет небольшим плюсом к стоимости товара/услуги.
Есть компании, которым удобнее и выгоднее держать свой штат разработчиков и решать задачи своими силами, не только потому что это уменьшает бюрократическую нагрузку упрощает процесс, но и еще то что деньги, вложенные в своих разработчиков, остаются в компании как ценный актив, когда как деньги, вкладываемые в арендную или страховую плату, уходят в туман без остатка.
А где выигрыш то? В тексте говорится что Оракул умеет тоже самое.
Плюс заявление что база бесплатная, мягко говоря, не верное, потому что за "бесплатно" нужно будет иметь людей, которые будут работать над решением проблем, в случае которых у Оракула это входит в стоимость поддержки.
Наличие поддержки у Oracle, это в первую очередь доступ к базе знаний и заплаткам, при это цена поддержки 22% от стоимости лицензии в год.
И наличие этой поддержки не означает, что будут решать вашу проблему, а всего лишь право оформить баг и ждать, что его когда нибудь пофиксят…
А с учетом постоянно снижающейся популярности Oracle, скоро найти грамотного админа станет весьма проблематично и дорого.
Я раньше был фанатом Oracle, но в последние годы максимально стараюсь его избегать!
С фиксами для слона та же история, можно годами ждать, что кто-то возьмётся за ваш кейс, либо просто нанять армию разработчика и пилить свои патчи самостоятельно. Хз что ещё после этого выйдет дешевле.
И наличие этой поддержки не означает, что будут решать вашу проблему, а всего лишь право оформить баг и ждать, что его когда нибудь пофиксят…
Что также можно сделать у постгре за бесплатно. Интересно бы сравнить скорость исправления схожих проблем, но у меня нет данных.
Нет, очевидно даже близко того же самого там нет. Даже этот элементарный пример: x->>y vs x.get_string(y). Туда же касты.
Кстати, пример с жсоном в статье манипулятивный. В пг там не нужна отдельная функция, можно прямо в запросе всё сделать(select '{ ... }'::json->>'key'). Это также проявление разных подходов(когда об удобстве, как одной из основных фич, думают и когда просто выкатывают хоть как-нибудь работающую поделку).
А вы пробовали эту поддержку получить-то? Илм как будто с этой поддержкой прям dba не нужен? Да и люди за знание оракла тоже часто хотят больше денег так как знают, что это дорого-богато.
Непосредственно по ораклу не обращался, но по SAP@Oracle довелось как-то - решение было предоставлено в течении дня, и даже отсутствие "действующей поддержки" не остановило интегратора от помощи (продукт на момент обращения носил архивный статус, и поддержку никто не оплачивал уже несколько лет). В принципе, и от ПостгресПро я получал помощь, не будучи их клиентом - пусть просто в формате "вопрос-ответ", но очень помогли.
Звучит неубедительно, это скорее какая манера самовнушение человека, у которого нет денег на лицензию.
Ну подобные тезисы слишком слабы. Купившему лицензию признать свой выбор несостоятельным ещё сложнее, ведь тогда ему нужно будет сказать что-то навроде "я лох, отдал деньги за мусор" - это более позорно, нежели "нет денег". Поэтому персонажи с лицензией ещё более ангажированы, чем те кому карман не позволяет сделать выбор полноценный.
Мне кажется, ваша лексика выдаёт в вас человека, в принципе не сталкивающегося с задачами, где нужна СУБД Oracle. Разумеется, какому-то провинциальному интернет магазину достаточно и бесплатной мариядб с вашими услугами администрирования, чтоб его владелец не чувствовал себя лохом. Как говорится "дёшево и сердито"
В очередной раз ни единого возражения. И да, лексика выдаёт - это прям сильно. Но то ладно. Главное здесь в другом.
Здесь в комментариях 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-бд из файлика выше).
По-моему, это не самовнушение, а способ, спровоцировав возобновление старой "священной войны", привлечь внимание к статье в корпоративном блоге, целью которой является продажа очередных курсов.
Право на такую манипуляцию автор и стоящая за ним организация имеют: они честно заплатили за это влаельцам Хабра. Ну, а вестись ли на эту манипуляцию - личное дело каждого.
PS И таких статей, которые пытаются возобновить древние священные войны, я в корпоративных блогах на Хабре вижу немало. Что ж, владельцы блогов заплатили за свое право их публиковать, так что осуждать их не за что.
Сейчас появилась мода отказываться от оракла в пользу всякого разного хлама, чтоб хлебнуть лиха и вновь вернуться к стабильному и надежному решению. Взять к примеру Uber, они спрыгнул на постгре, с полгода побились головой об стену и поняли что транзакционная модель оракла куда производительнее и надёжнее, а падение прибыли из-за сбоев и деградации производительности не перекрываются выиграшем по костам на лицензиях оракла.
Отсюда и такие статьи адептов слонов.
Отсюда и такие статьи адептов слонов.
Мне вы ответили напрасно: я в "священных войнах" не участвую из принципа.
А что понимается под «транзакционная модель оракла куда надёжнее»? Это когда оракл вообще не соответствует стандарту SQL в плане транзакций, т.к. допускает аномалии сериализации на уровне Serializable?
В Oracle можно работать с json и через SQL. Например так:
select json_value('{"name": "Kolya", "age": 30}', '$.name') xxx from dual
Спасибо, мне это надо.
Скажите пожалуйста, а насколько это тяжёлый запрос?
А что в нем тяжелого? Это просто функция, выполняемая на каждой строке результата. Ну будет потреблять сколько-то процессора. Как любая функция.
Есть же разные функции, какие-то выполняются моментально, а какие-то могут оказывать существенное влияние на утилизацию ресурсов. Так же, как бывают хорошие и не очень планы выполнения запроса. В прочем, функционал работы с джесонами довольно свежий, не удивлюсь, если его работа ещё не оптимальна. Надо полагать, у вас есть опыт работы с этой функцией, поделитесь впечатлениями, пожалуйста
В вопросе речь о совершенно конкретной хорошо определенной функции над json. Которая по сути внутри представляет из себя JsonPath. На план запроса она никак влиять не может. Цена исполнения - C * число строк. Множитель C наверное не константа, это в примере json константой задан, а в реальности он скорее всего будет значением колонки таблицы (т.е. может быть разной структуры и размера). Ну т.е. тут речь скорее всего о том, какова производительность JsonPath на разных JSON и выражениях (которое тут в примере $.name).
The 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.
По моему опыту, PostgreSQL сейчас не дотягивает даже до Oracle8i конца 90х:
1.Вечные проблемы с вакумом - на больших таблицах проход автовакума происходит один раз в несколько дней. Всё это время копятся копии изменившихся записей. Это не позволяет просто так использовать всевозможные агрегаты, очереди и т.д. - что кардинально изменяет подход к работе с этой СУБД и сильно её усложняет
2.Отсутвие физической сортировки данных, с одной стороны, на порядок повышает количество рандомных чтений с диска, а с другой - на порядок снижает эффективность кэша (ради одной записи кэшируется целый блок). В итоге PostgreSQL при своей работе требует в 100 раз больше оперативной памяти, чем Oracle.
3.Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
а) PostgreSQL регулярно выбирает неверный план исполнения в результате ваш запрос периодически беспричинно сбоит - имеем кучу бессонных ночей
б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
4 Из-за слабых возможностей СУБД предлагается использовать секционирование и шардирование. Это, в свою очередь ломает всю теорию реляционных баз данных, что опять-таки приводит к резкому снижению надежности системы и резкому повышению сложности программирования под неё.
5 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
Вы можете подробнее рассказать про такие случаи?
Не хотелось бы углубляться в эту довольно грязную тему. Ну вот, например:
-- равносильно field = $1::uuid, но теперь pg не знает, что здесь константа
field = split_part($1::uuid::text || '_' || field2, '_', 1)::uuid and ...
Использование uuid объектов как то ломает оптимизацию?
Можно пояснить, а зачем такую сугубо внутреннюю вещь как идентификатор объекта вообще использовать, тем более вытаскивать ее на верхний уровень в виде текста? что вообще означает получениеuuid результата вычисления? что тут можно ожидать кроме случайного текста?
>> что тут можно ожидать кроме случайного текста
Тут обратите внимание, что функция split_part нумерует части строки с единицы, а не с нуля. Т.е. в результате этой функции получаем тот же самый $1::uuid.
Здесь мы запретили PostgreSQL использовать индекс, начинающийся с поля field, т.к. он не может вычислить правую часть выражения до того, как получит значение поля field2.
-- равносильно field = $1::uuid, но теперь pg не знает, что здесь константа
А Oracle 8i знает?
Почему вы хотите от планировщика по сути функциональности оптимизирующего компилятора?
Google решили массу таких проблем в своём AlloyDB, подняв перфоманс на отдельных тестах в 100 раз.
Проблема в том, что Postgres в опенсорс, готовый из коробки к применению в энтерпрайзах не выгоден его разработчикам. Они и куча вендоров по всему миру кормятся с поддержки, продавая кастомные сборки с исправлением ошибок.
Отсутствие возможности валидировать XML по XSD-схеме;
Отсутствие возможности группировать PL/pgSQL-код по пакетам.
Хм, мы используем 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, то могут быть проблемы.
ERP-системы для относительно немаленьких бизнесов с тысячами пользователей, работающих в системе, и все это на одиночных серверах. И не платить ничего при этом ни Oracle, ни Microsoft. Все прекрасно работает в связке Debian / ванильный PostgreSQL.
И это нормально, на этом уровне PostgreSQL уже может конкурировать с Ораклом, Оракл плотно держит “лютый экнерпрайз”, всякие телекомы, банки и т.д.
И это нормально, на этом уровне PostgreSQL уже может конкурировать с Ораклом, Оракл плотно держит “лютый экнерпрайз”, всякие телекомы, банки и т.д.
Вот это странная классификация. У любого лютого энтерпрайза тоже разные процессы есть. И во многих из них возможностей PostgreSQL будет выше крыши. А в количественном выражении таких процессов больше, чем тех, где требуется мультимастер репликация и т.д. И там вполне можно отказаться от Oracle.
Да, понятно, что обработке транзакций в банках без Oracle тяжело. Но там есть еще сотни процессов, где можно спокойно уйти с оракла.
Вот это странная классификация. У любого лютого энтерпрайза тоже разные процессы есть. И во многих из них возможностей PostgreSQL будет выше крыши. А в количественном выражении таких процессов больше, чем тех, где требуется мультимастер репликация и т.д. И там вполне можно отказаться от Oracle.
И да и нет, есть условный крупный банк со своей биллинговой системой с миллионами транзакций построенной на Оракле, есть у них какая то менее серьезная/критичная/нагруженная система, даже не знаю для какой то внутренней аналитики, скрининговой системы, можно ее построить на Посгри, конечно можно, но это потребует в штате человека который знает этот Постгри.
можно ее построить на Посгри, конечно можно, но это потребует в штате человека который знает этот Постгри.
Там не нужна какая-то супер-пупер квалификация. В большинстве случаев достаточно просто установить, сделать базовые настройки и все будет работать из коробки.
В любом случае, это будет гораздо выгоднее просто за счет лицензий и поддержки оракла.
Ну обычно так и делается, но для этого используется не постгря, а даталейк и биай, так как хранение в с3 куда дешевле любой базы даже бесплатной
И чем хранение в S3 дешевле базы? S3 - те же файлы, та же дисковая подсистема, откуда там выигрыш в стоимости-то может появиться?
стоимость использования сервиса с3 в любом облаке значительно дешевле любого другого способа хранения, иначе б его не существовало и никто бы им не пользовался. вижу, вы хотите самостоятельно собрать что-то на кухне на коленке, в таком случае экономии не выйдет. )
А при чем тут облака? Тут сравнивают PG или Oracle, причем исключительно в on-prem. А для on-prem разницы в стоимости дисков для БД или для S3 - нет никакого, это просто диски.
А что в каких-то публичных облаках нет других механизмов хранения файлов, кроме S3 - не делает S3 каким-то особенно дешевым способом.
И это если не вспоминать, что S3 - просто семейство протоколов для хранения LOBов и стоимость хранения очень зависит от реализации. Где-то подешевле, где-то сильно дороже.
Да и Data Lake и BI - не обязательно связаны с S3 (собственно, почти всегда не связаны с S3).
Ну если цель именно никому не платить, то можно смириться с чем угодно и радоваться.
А почему нет репликации? Хозяин такой жмот, что даже стендбай базы не хочет держать на готове, или у вас настолько небогатый опыт, что база ни разу не падала и не приходилось её часами оживлять из бекапа? Ну, если бизнес с тысячами пользователей может себе позволить подождать, тогда все понятно. Жалко мне ваших клиентов.
Ну если цель именно никому не платить, то можно смириться с чем угодно и радоваться.
Нет, это не цель, а приятный бонус.
А почему нет репликации? Хозяин такой жмот, что даже стендбай базы не хочет держать на готове, или у вас настолько небогатый опыт, что база ни разу не падала и не приходилось её часами оживлять из бекапа?
Некоторые делают асинхронные реплики, некоторые нет. Мы просто никогда не отвечаем за инфраструктуру, а это делают клиенты. И это ответственность их администраторов баз данных. Некоторые настраивают реплику, некоторые нет. Благо сама настройка из коробки ванильного PostgreSQL занимает минут 5 (сам много раз делал).
Что касается падения PostgreSQL, то Вы удивитесь, но ни разу не падал PostgreSQL. Просто ни один крупный клиент не экономит на СХД с RAID'ом. И SSD, как правило, не умирает "внезапно". Там начинает деградировать запись и это обычно видно заранее. Просто СХД сигнализирует, что есть какая-то проблема с конкретным SSD. Админ переключает на другой (обычно держат резерв) и все продолжает работать нормально.
С чего вообще должна порушиться база ? За десять лет и сотни клиентов ни разу не было. PostgreSQL - супер надежный, если с дисками все ок. Но если ручки кривые у администратора (например, если выключить fsync), то конечно будет рушиться постоянно.
Ну, будем честными, мультимастер в Оракле тоже сомнительная вещи и для обработки транзакций не очень пригоден. Да и PG вполне справляется с процессингом на десятки миллионов активных пользователей - если нормально готовить.
5 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
А из опыта этот вывод как-то подтверждается? У нас есть опыт миграции нагруженных оракловых серверов на постгрес и ни разу миграция не потребовала наращивания железа.
Я бы по четвертому пункту добавил, что формально в постгресе размер таблицы - 32 терабайта, а число таблиц в базе что-то типа миллиона. А де факто у нас в компании рекомендация не делать базу больше 10 терабайт, иначе будут проблемы с бэкапом. В итоге при миграции с оракла на постгрес получается шардированная база из 16 узлов, в то время как в оракле это была одна база, и проблем с бэкапом не было.
Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
Ну вообще хинты-то есть, это вы зря. pg_hint_plan вроде звать это расширение, у нас его по умолчанию везде ставят. Детальнее сравнить не возьмусь. А насчет оптимизатора - согласен. При массовой миграции массово же напоролись на то, что запросы, которые оракл прекрасно оптимизировал, стали работать фигово, потому что оптимизатор например не умеет делать push predicate в подзапрос (впрочем, такая же примерно проблема у наших не особо новых версий MS SQL была).
Хм, переносить логику с Oracle на PG - плохая идея. Новая БД требует новых подходов к разработке, так что если запросы Оракла плохо работают на PG - не говорит о проблемах PG, только о проблемах перехода с Oracle.
С бэкапом - да, есть проблемы. Впрочем, бэкап на 10TB и для Оракла не очень разумен.
Хм, переносить логику с Oracle на PG - плохая идея.
Ну вообще в сегодняшних реалиях РФ никто не спрашивает обычно. Переносить - это требование государства для некоторых компаний.
Что до конкретных запросов - то у меня лично претензия только к оптимизатору, который несколько ограничен. Логика эта - обычный SQL, с подзапросами, вполне стандартный. Там где специфичная нестандартная оракловая логика не переносится (например, где-то мы активно применяли SCN, и замены ему нифига не видно) - ну какие тут претензии к PG реально могут быть?
А бэкап... ну как бы, вопрос тут скорее к тому, что по документации - можно таблицу 32Тб. А по факту - можно базу 10Тб со скрипом. А до миграции была база примерно 160Тб, и ничего, работала как-то. А сейчас стало 16 * 10.
Ну и да, я прекрасно понимаю, что огромному числу компаний до таких объемов расти и расти, и они ничего такого не заметят вовсе.
Есть по крайней мере одна вещь, где PostgreSQL точно выигрывает у Oracle. Это в скорости компиляции запросов. Мы используем у себя в lsFusion внутренний язык, который затем компилируется в SQL. Но пишут на нем люди, которые не всегда хорошо понимают, как это все будет выполняться (низкий порог вхождения).
Иногда получается так, что компилируются запросы в 2 миллиона символов. Так вот, PostgreSQL умудряется скомпилировать такие запросы, например, за 500 мс, а выполнить за 200 мс. В последнее время, я даже увеличил в некоторых местах лимит на такие запросы до 8 миллионов символов, и они тоже выполняются за более менее адекватное время. В итоге, местами мы даже перестали оптимизировать такой код - зачем, если и так работает, а запрос выполняется редко.
Oracle же на запросе в 2 миллиона символов только компиляцию делал больше 10 секунд, а иногда и вообще уходил в минуты. Что и не удивительно. В PostgreSQL очень простой планировщик. Да, он бывает ошибается. Да, сваливается в Nested Loop. Но зато он очень быстрый в компиляции и выполнении, что бывает более выгодно (хоть и имеет свои минусы).
Помню, как бывало на олимпиадах по информатике, когда кто-то садился и очень быстро писал очень быстрый перебор, и он проходил все тесты (авторы не думали, что он пройдет). А кто-то долго писал правильный алгоритм, но в итоге проигрывал по времени.
Такие поверхностные статьи не писали даже в 90х, на заре становления РСУБД. Печально,
В статье нет самого главного - упоминания области применения БД, объемов данных, характера нагрузки, требованиям к отказоустойчивости, безопасности и т.п. В банках и телекомах постгреса в ядре как-то не видать.
Именно за это все ораклу и платят деньги, а движки для вебсайтов конечно же на оракле никто не делает.
Точка зрения из тех самых 90-х. Сейчас Оракл в банках как исторический рудимент, не для нового проекта.
вам бы матчасть изучить. не знаю как сейчас в РФ, но оракл в крупном бизнесе везде и альтернативой ему является только мсскл, может быть еще где-то есть дб2 (про дб2 правда давно ничего не слышал).
Хм, в старых проектах - да. И нет, MS SQL не является альтернативой Ораклу (не больше, чем PG). Но для новых проектов выбор БД - не очень простая задача, так как много вариантов.
Я видел множество проектов на Oracle. Видел даже, когда на базе PL/SQL создавался ООП. Ну и простыни PL/SQL, хаки с оптимизатором запросов и прочим и прочим и прочим.
Могу сказать одно, Oracle во всех увиденных проектах был избыточен. Не использовалась даже половины функций. Очень часто всё многообразие хаков с оптимизаторами можно было бы решить пересмотрев структуру хранения данных, добавив к некоторым таблицам дополнительные ключи. Да и вообще, не знаю как вам, но мне всегда попадались DBA, которые в конце концов вам скажут: «План запроса, это здорово, но даже при наличии хаков то, как Oracle выполнит запрос до конца не известно на 100%»
Так что, тот ландшафт банков и прочих с Oracle мне видится, как анахпонизм из эпохи, когда надо было на Unix а что ставим, а давай Oracle. И с тех пор так и тянут этот чемодан без ручки.
У бизнеса нет денег и времени, чтобы хотя бы приступить к постепенной миграции, но зато есть куча бабок поддерживать давным давно созданные решения.
PostgreSQL как подарок судьбы
Начнём с самого очевидного: PostgreSQL — бесплатный и Open Source. Это очень приятный бонус. Вы получаете всю мощь системы без необходимости покупать лицензии, платить за дополнительные модули или беспокоиться о процессорных ограничениях.
Ну это же не серьезный аргумент, даже не имеет смысла его упоминать при техническом сравнении, бизнес для которого покупка лицензии Оракла дорогая, скорее всего не имеет тех объемов данных и тех нагрузок для которых ему в принципе нужен Оракл.
Полностью согласен. Open Source в итоге приводит к двум вариантам:
внутри компании появляется "как бы вендор" который отвечает за сборку
выбирается вендор типа Postgres Pro
Оба варианта имеют свои плюсы и минусы ... но оба не бесплатные ( в первом случае ЗП и риски в случае ошибки или не вовремя закрытой уязвимости, во втором такая же модель оплаты как с Oracle)
В целом текст не своевременный. Я понимаю, что если не попадать под регулирование, 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% от функционала и скорости.
"Богомерзкий MVCC" нельзя считать абсолютным злом - зависит от способа использования. Конечно bloat это плохо, зато без проблем выполняются долгие запросы. В Оракле на нагруженной базе долгие запросы приводят к snapshot too old, а большие апдейты вообще противопоказаны, поскольку могут закончиться переполнением undo tablespace и длительным откатом с блокировкой таблицы.
К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.
К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.
Да в итоге тот же Оракл и получится, когда потребуются петабайты, кластера, репликация, и пр, все эти расширения так же нужно будет поддерживать, править баги и т.д, что потребует денег не меньше чем покупка лицезии на Оракл.
Про "не mvcc" хранилища давно слежу, и EDP пыталось, по zheap новостей уже лет 5 нет. Реально там скорее всего все упирается, в то что индексы не версионируются.
В Oracle undo управляемое зло, в PostgreSQL - MVCC не управляем, стандартная беда на фоне долгой транзакции регулярно меняется одна строка (например, остаток на счету кассы) и привет... в индексе на одну строку 100500 записей и столько же записаей в heap и оно быстро не лечится. В оракле у вас со snapshot to old слетит сам долгий запрос, в PostgreSQL раком встанет вся система.
К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.
Вообще-то, у PostgreSQL изначально не было MVVC-хранилища - и я помню время, когда некто Бартунов (наверняка, многим тут известный) выбрал Interbase в качестве СУБД для сайта: пусть и идеологически чуждый - ибо (на тот момент) не Free и даже не Open Source, а всего лишь бесплатный - но зато поддерживавший ту самую многоверсионность, котрая сайту была нужна по условиям эксплуатации (заливка новой информации из БД фронт-офисной программы параллельно с работой сайта).
Но это было, ну, очень давно.
Golden Gate - ничего сопоставимого нет от Open Source, Debezium - жалкое подобие и 10% от функционала и скорости.
StreamGate. SIDEC. Не уверен, что и то и другое можно даром, но в целом они уже близки к GG оба. Не opensource ни разу. Но ведь и OGG тоже же не.
У 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), это закрытый рынок с должностями под конкретных людей.
В целом, я плохо понимаю, кому из пользователей Хабра в в 2024 году может понадобится Oracle на новом проекте.
Зависит от проекта, если бэкенд веб магазина то да, если ядро телекома, то посгресс просто может не потянуть.
Если вы работаете на компанию из РФ или РБ, то это сомнительно с точки зрения complience.
А если через год, два, пять лет, начнется новая оттепель, перестройка, перезагрузка? И я правильно понят, что основной ваш аргумент, что сейчас Оракл хуже Посгри именно из-за политики, я не против такого аргумента, но просто нужно признать что технически Посгри еще сильно отстаёт от Оракла.
Мы вот телеком и да, постгрес вполне тянет (в отличие от мускуля кстати). И невозможно себе представить что могло бы нас заставить вернуться на Оракл, независимо от политики.
Да, в целом Оракл получше, но с учетом его стоимости и отсутствия принципиальных преимуществ его использование оправдано только для обработки очень высокомаржинальных (с большой выручкой на байт) данных.
Можете рассказать, во что вы уперлись с MySQL. А то вот Uber, например, наоборот предпочла MySQL: https://habr.com/ru/companies/slurm/articles/322624/
Мускуль проигрывал постгресу по производительности на всех основных типах запросов кроме массовых (не атомарных) апдейтов. Раздражала его способность выжирать память свыше значений в настройках innodb, что требовало периодических перезапусков.
Но решающее значение имел факт систематических крашей баз данных, содержащих партиционированные таблицы при достижении неких критических нагрузок: объяснения этому так и не нашлось и на этом доверие к этому изделию было окончательно утрачено.
Раздражала его способность выжирать память свыше значений в настройках innodb, что требовало периодических перезапусков
PostgreSQL тоже этим страдает, кстати. Мы для этого в автоматическом режиме время от времени закрываем/открываем соединения, чтобы процессы перезапустились и память очистилась.
Но надежность PostgreSQL действительно выше всяких похвал.
Во-первых, что такое "ядро телекома", и зачем ему именно реляционная СУБД? Как это "ядро" будет шардироваться? А то есть подозрения, что там основные данные будут в какой-нибудь Kafka сохраняться и дальше по разным системам растаскиваться.
А если через год, два, пять лет, начнется новая оттепель, перестройка, перезагрузка?
То Oracle в следующий раз выберут в лучшем случае лет через 20. Потому что все разработчики на локальном рынке уже переучились на другие СУБД и другие архитектуры.
просто нужно признать что технически Посгри еще сильно отстаёт от Оракла
Безусловно. Но это не значит, что кто-то возьмёт Oracle вместе Postgres. Возьмут Kafka и поставят его перед несколькими инстансами Postgres/MariaDB и ClickHouse. СУБД - это не вещь в себе. Это часть инфраструктуры. Сбер тот же ещё в 2018 активно съезжал с Oracle на Postgres. Нафига ему съезжать обратно?
Но это не значит, что кто-то возьмёт Oracle вместе Postgres. Возьмут Kafka и поставят его перед несколькими инстансами Postgres/MariaDB и ClickHouse.
Ну в итоге то решение не дешевле (если не дороже Оракла) если мы говорим про большие объёмы данных, требования к надежности, отказоустойчивости, и т.д.
Сбер тот же ещё в 2018 активно съезжал с Oracle на Postgres. Нафига ему съезжать обратно?
Сбер компания богатая может позволить себе платить за условный Platform V Pangolin и я к слову не вижу в этом ни чего плохого, разрушат монополию Оракла, я не против, но сама суть останется той же, хочется чего то сопоставимого с Ораклом, придётся платить плюс минус как за Оракл, не Ораклу, так вендору Посгри, не вендору, так содержать свой отдел разработки и поддержки.
Хм, почему не дешевле Оракла?
Админы дешевле, лицензии дешевле. Да, если покупать PgPro - то будет дороже. Но, вообще говоря, смысл покупать PgPro возникает довольно редко и не связан с технологическими особенностями.
А надежность и большие объемы данных требуют вообще других решений, не про PG и не про Oracle )
Хм, а зачем в телекоме Оракл? Те задачи, что в телекоме требуют реляционной БД - потянет и PG. А те, что не потянут - не реляционные )
В финтехе, в общем, та же ситуация )
Дайте подумать...🤔 Нигде? 😬
Подсаживайтесь на бесплатный Postgres а потом хоба! https://lab50.net/blog/astra-linux-special-edition-1-8-prices/
Статья довольно поверхностная.
Например, можно ещё была бы добавить, что для если требуется ACID полноценная репликация без тонны денег, то есть Cockroach DB, который по прочим, суть, тот же PostgreSQL но сотказоустойчивым кластером.
Это, как пример.
Лично моё мнение, от Oracle следует уходить хоть тушкой, хоть чучелом. Учитывая его жадность и то, что внутри себя представляет база данных Oracle, её код, это решение морально устарело.
(Под, что такое Oracle я имел ввиду саму кодовую базу системы с её миллионом флагом в 99% ещё из, 80-х. Ссылку на соответствую статью я не нашёл)
Если суммировать смысл статьи, то остается только преимущество по стоимости и оно действительно есть, даже с учетом использования платной версии PostgreSQL Pro.
Вроде получается что статья не совсем техническая? )
P.S. И честно говоря хранения в колонках JSON / BSON и всякого другого текста содержащего частично структурированные данные - это разумеется анти-паттерн, особенно в PostgreSQL из за особенностей его реализации (https://www.postgresql.org/docs/current/storage-toast.html)
Где PostgreSQL выигрывает у Oracle DB