Цель статьи зародить зерно сомнения в душе читателя, который пытается сделать выбор между реляционными БД которые работают в режиме версионника. Почему именно режиме версионника? Здесь выбор не большой, а в блокировщиках есть достойные соперники и выбор еще сложнее.( Чего только стоит бесплатная версия DB2 для небольших БД).
Я не являюсь экспертом БД Oracle хотя и проработал с этой БД много лет и не только с ней. Все что я умею — использовать ее преимущества и добиться оптимального быстродействия. Я тем более не являюсь экспертом PostgreSQL (я не разу не использовал его в продакшене).
Читая статьи об успешной миграции — я понимаю что этим компаниям и не нужен был Oracle или БД была выбрана изначально не верно. Они использовали только малую долю возможностей этой БД. Только поэтому они могли принять решение об миграции, и его осуществить. Просто если использовать всю мощь этой БД — у вас никогда не возникнет желания мигрировать ибо это сродни написать ваше приложение почти с нуля.
Давайте, наконец, поговорим о тех преимуществах для быстродействия, которые дает Oracle и на основании этой информации Вы найдете ответ для себя сами.
- Partition(8i). Partition — дает возможность роста объема данных практически без влияния на общее быстродействие. Приятный и немаловажный бонус — партицирование индексов. У PostgreSQL партиции появятся только в 10 версии. До этого наследование (INHERITS) — грязный хак. Да и возможности партицирования в Oracle возрастают с каждой версией.
- Merge(8i). Да да, тот самый Merge который есть уже в MSSQL много лет(2008) и которого не будет даже в PostgreSQL 11. Он дает прирост в быстродействии в десятки раз по сравнению с одиночными операциями. Да я знаю что PostgreSQL поддерживает подзапросы и можно все реализовать через Insert select и хитрый update. Но это далеко не тоже самое.
- RESULT_CACHE (Select) (11g). У Oracle эта технология появилась относительно недавно. Если использовать эту технологию с умом — дает выигрыш в некоторых вещах в десятки и сотни раз. Главное научиться “умно” ее использовать.
- Опция INMEMORY (12с) Нет аналога у PostgreSQL. Реальный прирост на некоторых запросах сотни раз.
- Оптимизатор + тюнинг запросов. Начиная с 11g превратился чуть ли не в клик next->next в EM. PostgreSQL с этим посложнее да и отсутствие в целом аналога EM достаточно некомфортно.
PL/SQL. Да я знаю про многообразие языков в PostgreSQL. Но Oracle постоянно улучшает язык с прицелом на быстродействие.
- Компиляция. В байкод происходит во время сохранения (в PostgreSQL во время первого вызова в сессии + план запроса во время первого исполнения). Начиная с 10g в Oracle возможна компиляция в нативный код.
- Нативный Integer — значительно ускоряет работу с числами. В PostgreSQL можно использовать другие более подходящие языки(трансляторы). В оракла это тоже можно решить с помощью Java и С.
- Переключение “контекста” PL/SQL. Oracle очень заботится об оптимизации этого показателя, улучшая его от версии к версии. Для уменьшения задержек Переключение “контекста” придумати BULK COLLECT and FORALL и не только.
Учитывая состояние языков PostgreSQL эта задача вовсе не важна на этом этапе. - Result Cache(function) (11g) При грамотном использовании отзывчивость приложения в целом может вырасти в несколько раз при этом не требует много усилий. На некоторых запросах десятки раз.
Ну и как говорится, дьявол кроется в деталях, а у Oracle эти детали проработаны намного лучше. Oracle не перестаёт удивлять с каждой версией. И не важно на какую БД вы пересядете после Oracle — у Вас всегда останется ощущение: Ну блин, в Oracle это уже давно есть, или в Oracle это сделано лучше.
Я почти уверен что при одинаковом железе и использовании всех возможностей PostgreSQL и Oracle можно получить лучшее быстродействие, при меньших усилиях на ORACLE.
P.S. Ни в коем случае не рассматривайте эту статью как пиар БД Oracle.
Я хорошо понимаю, что обязательно есть вещи которые в PostgreSQL сделаны лучше. Но в целом Oracle в этом сегменте БД №1.
Я специально не затрагивал вещи связанные с администрированием. Просто представьте что вы можете перенести дата файл с диска на диск или восстановить «битый блок» в состоянии Online. И можете осуществить переход на новые сервера без остановки работы БД. И это не новые фичи. У Oracle там все намного лучше, да и я не являюсь админом БД.
Раньше, где то до 10 версии, админ был нужен практически всегда. Сейчас потребность в админе сильно упала, правда и квалификация админа сейчас нужна повыше. Возможно, в версии эдак 15, понятие “admin” БД уйдет в прошлое :)
Да и Pl/SQL продуманнее других, хотя конечно это и не C# :). Правда, это сугубо индивидуально.
Ну и я не затрагивал вещи, которые слабо помогают в быстродействии.
P.S.S. И да, я навряд ли я вспомнил все возможности. Только те которые были на “поверхности” Так что дописывайте в комментах. Я включу в upd.
Комментарии (22)
onix74
08.09.2018 14:32+6Partitioning — опция Enterprise Edition, которая, кроме того, покупается за отдельные деньги. Enterprise Edition лицензируется (если мы не пользовательские лицензии рассматриваем, а в этом случае их рассматривать глупо) по ядрам и стоит это $47500 за ядро + $10450 за техподдержку, которая при первоначальной покупке обязательна (http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf). Да, для интел есть поправочный коэффициент, по-моему, он равен 0.7, но от этого не легче. In-memory появилась только в 12c. На сколько она хороша мне сложно судить, а вот то, что 12c перестала работать с сертификатами в wallet-файлах и теперь нельзя средствами PL/SQL обратиться к HTTPS-ресурсам и мой service request по этому поводу безуспешно пока решается больше недели самим oracle, — моя реальность "данная мне в ощущениях".
Восстановление "битых" блоков online — тоже возможность enterprise edition.
И, да, оракл не перестаёт удивлять от версии к версии (см. упоминание https выше).
Но надо отдать должное — "убить" БД очень и очень сложно. Если поставить себе именно эту цель — можно, но если цель отличается, то он может работать годами не требуя вмешательства. С другой стороны, этого и ждут от решения подобного уровня. И ещё, по-моему, неверно сравнивать enterprise с Posgtres. Сравните, например, бесплатный Oracle XE, или, на худой конец, Oracle Standard Edition 1 (11G) / Standard Edition 2 (12c).Yo1
10.09.2018 15:01что стандарт, что экспресс, там пропасть. то пародия на партишенинг, что реализована в постгрес есть и в экспресс редакции оракла. patitioning view завется, так же на Instead of тригерах на view сделаны.
bankinobi
11.09.2018 18:21Еще можно добавить лицензирование каждого ядра в кластере vmware, даже если используется только 8 из 512 ядер, лицензирование diagnosticPack, data guard, multitenant 12c. Все выливается в огромные суммы.
a0fs
08.09.2018 15:37+3У меня пара вопросов:
1. Зачем нормально спроектированной базе нежен частый Merge, и почему insert… on conflict… в PostgreSQL в этих случаях не может справиться?
2. Чем RESULT_CACHE так лучше обычных материализованных представлений, кроме может ленивости и отсутствия необходимости следить за представлением.
Кроме того замечание о неверном выборе базы порадовало. Мне видится крайне маловероятным, что почта Яндекса жила на Оракле просто потому, что кому-то очень понравилась идея заплатить этой компании. Следует признать, что за PostgreSQL в последнее время взялись основательно, и много чего туда добавили. ИМХО, именно рост этой БД и попадание её по своим возможностям в список альтернатив для перехода в крупных проектах и стало причиной бодрого переезда на эту БД.nikolayv81
10.09.2018 21:50Result Cache от materialized view отличается очень сильно, materialized view это просто таблица-копия которая может обновлятся по определённым правилам, и места занимает как таблица с полным набором данных. Result cache это именно cache.
Merge всё-таки в стандарте, и он реально удобен, конкретно в oracle плюсом идёт rowid, правда минусом move между партициями, merge это всёже в основном update (insert on conflict проще).
А ИМХО по поводу БД в том что продукты развиваются, и постепенно "бесплатные" продукты догоняют полностью коммерчнские(и в некоторых направлениях и обгоняют) поэтому ниша "платных" продуктов сужается и это в принципе (на мой взгляд) хорошо, т.к. в такой ситуации снижаются издержки и у человечества, по идее, остаётся больше свободного времени и ресурсов :)
AlePil
08.09.2018 16:03+7Реально классная статья, где человек сравнивает то, в чем, по собственным словам, специалистом не является, но пробовал в продаешене, с тем, в чем, опять же, специалистом не является и даже не пробовал. Вывод — Oracle круче, потому как enterprise и там крутятся миллиарды, а posgreSGL хуже потому как не требует десяток тыс долларов за доп возможности.
oam2oam
08.09.2018 17:20+2Стиль статьи, по моему, подразумевает battle Oracle vs. PostgreSQL… что, конечно, нехорошо.
Однако заставляет задуматься — правда ли приведенных вещей нет в PostgreSQL? Или там уже все есть и даже лучше? Кстати, как верно замечено выше, сравнивать надо не обычный Oracle а enterprize — ну тогда уж возмем не стандарный PostgreSQL а… скажем — PostgreSQL-XL (или там XS?). А там… даже лучше чем partition! И давно ведь. У меня получалось базу распараллелить на 115 машин и получать прирост раз в 90 примерно по производительности. И так далее… А если очень нейметсяобтирайтесь чем придетсяможно прямо внутри сервера дописать свой обработчик — и будет вам незамутненное счастье!
robert_ayrapetyan
08.09.2018 19:25+1>У PostgreSQL партиции появятся только в 10 версии.
А какая, по-вашему, текущая релизная ветка уже с год как минимум?
>реализовать через Insert select и хитрый update. Но это далеко не тоже самое.
Обоснуйте, чего такого нельзя сделать с INSERT… ON CONFLICT… чего можно сделать с MERGE.
p.s. Единственное, что действительно хорошо в Оракле — это их столовые в главных офисных зданиях в Редвуде. Остальное так себе. А уж то, чего они натворили с Sun, гики никогда не простят.
Tantrido
08.09.2018 19:40Статья уровня детского сада, зерно сомнения не посеяли. Все эти «увеличения скорости в десятки раз» (пункты 1-4) имеют отношение только к Oracle vs. Oracle (или MSSQL vs. MSSQL): с включённой функцией или без неё и никакого отношения к Oracle vs. PostgreSQL (или MSSQL vs. PostgreSQL), т.к. Postgres изначально по другому спроектирован и имеет иные функции для увеличения производительности или изначально работает быстрее на обозначенных случаях.
maxzh83
08.09.2018 21:19Попробую написать комментарий в духе статьи. Как-то я писал хранимую процедуру в Oracle и долго не мог понять почему она работает не так, как должна. После долгой отладки выяснилось следующее. Я сохранял в колонку пустую строку '' и далее по коду при определенном условии проверял эту же строку на равенство пустой строке: column = ''. И вот эта проверка не отрабатывала. Само собой, выяснил я это только после перебора множества других вариантов. Оказалось банальная вещь — Oracle конвертирует пустую строку в NULL. Я полез читать почему же так происходит на форумы. О, эти прекрасные форумы. Самые адекватные ответы на подобные вопросы были «исторически сложилось, сорян», но были и другие типа «это же очевидно, не получил сертификат — не лезь».
Было еще несколько удивительных открытий в Oracle (например, невозможность создать булеву колонку), после которых сложилось некоторое отвращение. Но, все равно, я понимаю, что все зависит от задачи, а не от личных симпатий.Yo1
10.09.2018 15:14точно так же ораклойду хочется убить за то что в таблице половина значений нулл, другая пустая строка и нужно гадать. лошара просто забыл конвертировать в нулл или там какая-то бизнес логика, типа значение есть, но пользователь не заполнил.
maxzh83
10.09.2018 15:39лошара просто забыл конвертировать в нулл
Спасибо за комментарий, вспомнил те форумы, ностальгия. Т.е. по вашему вариант:
a = ''
if (a == '') {
//не срабатывает
}
логичный?
P.S. Это псевдокод, если чтоYo1
10.09.2018 17:17по моему в 90% случаев в этом коде ошибка, а нужно if (a == '' or a is null)
и это косяк субд, а в оракле сделано правильно
vazir
08.09.2018 21:36> Я не являюсь экспертом БД Oracle хотя и проработал с этой БД много лет и не только с ней. Все что я умею — использовать ее преимущества и добиться оптимального быстродействия. Я тем более не являюсь экспертом PostgreSQL (я не разу не использовал его в продакшене).
Неспециалист пишет о том в чем не разбирается… Зачем вообще?
celebrate
08.09.2018 21:59Пользуясь теми же аналогиями, Windows намного лучше Linux, т.к. в винде полноценная поддержка NTFS и DirectX. Само собой, «в десятки и сотни раз».
excentro
10.09.2018 13:15Ну и автор специально не затрагивал вещи связанные со стоимостью лицензии :) Тут разница может доходить до сотен раз :)
OlehR Автор
10.09.2018 23:13Цена
1 ядро с всеми необходимыми опциями по прайсу около 100 000$ По факту цена на половину+ рассрочка.
Ежегодно еще 10 000$. Но стоит учесть, что это не обязательно, ибо эта плата за поддержку и обновления и на легальность продукта не влияет.
Рассматривать покупку чего то кроме Enterprise на мой взгляд смысла нет.
Если вам не нужен Enterprise, точно можно обойтись чем-то дешевле или бесплатным.
Для примера 2х ядер Power 7+ достаточно чтоб работала OLTP система для 100 продуктовых супермаркетов.
Ну вот и считаем. 3 лицензии (2+1 стенбай) 150 000$ + ежегодно 30 000$ Дорого это или нет?
Партишин.
Да уже почти год он есть в посгри.
Но кроме того что он есть, не поленитесь почитать о существующих проблемах.
И после этого решите готовы ли вы использовать их в продакшене.
Я несколько раз начиная новый проект изучал возможность использовать посгри.
Ибо люблю свободный софт, и стараюсь использовать его, когда это целесообразно.
Merge
В комментариях несколько раз проскакивало INSERT… ON CONFLICT
так я отвечу, чем не устраивает — ON CONSTRAINT constraint_name
И скажите на каком месте merge в списке ожидаемых фич посгри? Разве
Специалисты посгри не знают о INSERT… ON CONFLICT?
Да и будь merge синтаксический сахар над INSERT… его б давно реализовали.
Ну и да, merge чаще используется для DW.
Все что я написал — реально помогало на реальном проекте(перешли с 8 ядер на 2 с общим улучшением быстродействия).
давайте по порядку.
Партиции.
В табличке более 500 000 000 записей это информация за 5 лет.
И это не просто табличка в которую делаются insert.
в таблице несколько индексов. Когда идет движение по этой таблице — идет изменение остатков.
Тем не менее благодаря патрициям и субпартициям нет никаких опасений, что через 5 лет придется что-то менять.
Merge существенно ускорил задачи DW. Больше нечего написать.
RESULT_CACHE (Select) (Если грубо — кеширование результата запроса в памяти (для тех кому лень погуглить), с автоматическим пересчетом результата в случае изменения таблиц.)
Поверте ето совсем не то что материализованные вюхи, которые кстати в оракле есть с незапамятних времен)
RESULT_CACHE (Function) Если грубо — кеширование результата запроса функции в памяти (для тех кому лень погуглить), с автоматическим пересчетом результата в случае изменения таблиц, от которых зависит результат функции)
Это настолько крутая фича, что ми ее начали использовать, как только вышел oracle 11R1.(Ми даже пренебрегли золотим правилом использовать новые фичи через релиз.
B конце концов ми нарвались на баг который исправили только 11R2 для нашей платформы)
Самый простой кейс использования в проверке прав пользователя у вюхах(у нас сотни видов объектов в каждом объектов от 10 — до 10 000).
Права как индивидуальнее так и на профили, причем индивидуальнее как на расширении прав так и на сужение.
Чтоб получить результат функции — нужен запрос к нескольким таблицам. (Да, до этого ми использовали кеширование, без него вообще никак)
Благодаря только простой кляузе RESULT_CACHE ми получили более плавный интерфейс, который ощутили все сразу.
Пожалуйста назовите мне аналогичную вещь (для решения данной задачи) в посгри.
Inmemory.(если уж совсем по простому(для тех кому лень погуглить) — табличка размещается в памяти.) Ну да, ето совсем свежая фича. всего то 5 лет ей. :) Я даже не представляю, как объяснить выгоду от нее. Кстати в списке ожидаемых фич посгресовци ее ждут, не так как merge, но все же ждут.
PL/SQL Можно спорить о размещении бизнес логики в БД. Сейчас ето не модно.
Но все же PL/SQL очень бистр. Некоторые вещи я перечислил. Это вообще не полный список, и может даже очень плохой.
P.S. Я написал, что я не эксперт оракл. Ибо чтоб пересчитать реальных экспертов в оракл, наверное, хватит пальцев одной руки.
Как только начинаешь углубляется в детали, понимаешь, что ты не знаешь и 30% возможностей этой БД. Я даже не уверен, что возможно знать хотя б 80% всех возможностей БД.
Я всегда с интересом слежу за выходом новых версий разных БД. Особенно слежу за статьями о посгри. Я всё-таки надеюсь что она выйдет на уровень когда можно будет ее рассматривать как альтернативу ораклу.
И да я писал под разные БД. включая sqlite, mysql, mssql, oracle, И где ето возможно и рационально использовал встроенные языки.
(за плечами многие десятки тысяч строк кода, который работает в продакшене и годами не требует вмешательства) и все равно я не эксперт ни одной БД. А если мне нужно начать работать с новой для меня БД я сначала изучаю нюансы работы этой БД, а только после этого начинаю строить архитектуру БД и писать код.
И да, чуть ли не первое что читаю — это нюанс с null :)
Тем более 2 последних года я больше пишу кода для MsSQL.
И да я уверен, что любую задачу можно решить на любой вменяемой БД.
Вопрос лишь в архитектуре и необходимом усложнении алгоритмов.
Я не религиозный фанатик оракл, я использую БД в зависимости от проекта, наследия, правил и ТД.
Скажу больше било время, когда я любил MySql за простоту и скорость.
P.S.S. Главное что я хотел донести что прокомментировал onix74 ( и собрал наибольше лайков)
https://habr.com/post/422669/#comment_19087833
Я процитирую "И ещё, по-моему, неверно сравнивать enterprise с Posgtres. Сравните, например, бесплатный Oracle XE, или, на худой конец, Oracle Standard Edition 1 (11G) / Standard Edition 2 (12c).
"
Переведу как я это понимаю — oracle enterprise и Posgtres ето продукти для разных сегментов.
И низя считать, что Posgtres c лёгкостью заменит oracle enterprise. Если вы с этим согласны — не зря я писал эту статью и угробил карму :)
P.S.S.S. Я в отпуске(слишком поздно промодерировали), и не могу в онлайн комментировать. Некоторые коменти я постараюсь ответить завтра.
И да, всем спасибо за коментарии.
anijat
10.09.2018 23:14Ещё бы написал, что у Оракла есть exadata, где смарт сканы позволяют обходиться без индексов, а у постгреса этого нет. По сути сравнить Оракл и Постгрес не правильно, разного уровня задачи решаются.
alexxisr
Хоть вы и пишете, что статья не является пиаром оракла, но воспринимается она именно так. Каждое предложение по шаблону — "<непонятное слово> есть в оракле и нет в постгресе, поэтому оракл в несколько раз быстрее и лучше". Мне что каждое это непонятное слово гуглить?
robert_ayrapetyan
Вы еще не видели остальных 29 комментариев, оставленных автором за последний год. Там что не строка — ода ораклу.
Scif_yar
Тоже так думаю! В конце концов, на ведущем технико-политическом сайте рунета могли и сразу писать, что делает эта функция!
В конце концов, я вот не для того за интернет плачу, чтобы по гуглю постоянно лазать!