Comments 23
Хоть вы и пишете, что статья не является пиаром оракла, но воспринимается она именно так. Каждое предложение по шаблону — "<непонятное слово> есть в оракле и нет в постгресе, поэтому оракл в несколько раз быстрее и лучше". Мне что каждое это непонятное слово гуглить?
Вы еще не видели остальных 29 комментариев, оставленных автором за последний год. Там что не строка — ода ораклу.
UFO landed and left these words here

Partitioning — опция 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).

что стандарт, что экспресс, там пропасть. то пародия на партишенинг, что реализована в постгрес есть и в экспресс редакции оракла. patitioning view завется, так же на Instead of тригерах на view сделаны.
Еще можно добавить лицензирование каждого ядра в кластере vmware, даже если используется только 8 из 512 ядер, лицензирование diagnosticPack, data guard, multitenant 12c. Все выливается в огромные суммы.
У меня пара вопросов:
1. Зачем нормально спроектированной базе нежен частый Merge, и почему insert… on conflict… в PostgreSQL в этих случаях не может справиться?

2. Чем RESULT_CACHE так лучше обычных материализованных представлений, кроме может ленивости и отсутствия необходимости следить за представлением.

Кроме того замечание о неверном выборе базы порадовало. Мне видится крайне маловероятным, что почта Яндекса жила на Оракле просто потому, что кому-то очень понравилась идея заплатить этой компании. Следует признать, что за PostgreSQL в последнее время взялись основательно, и много чего туда добавили. ИМХО, именно рост этой БД и попадание её по своим возможностям в список альтернатив для перехода в крупных проектах и стало причиной бодрого переезда на эту БД.

Result Cache от materialized view отличается очень сильно, materialized view это просто таблица-копия которая может обновлятся по определённым правилам, и места занимает как таблица с полным набором данных. Result cache это именно cache.
Merge всё-таки в стандарте, и он реально удобен, конкретно в oracle плюсом идёт rowid, правда минусом move между партициями, merge это всёже в основном update (insert on conflict проще).
А ИМХО по поводу БД в том что продукты развиваются, и постепенно "бесплатные" продукты догоняют полностью коммерчнские(и в некоторых направлениях и обгоняют) поэтому ниша "платных" продуктов сужается и это в принципе (на мой взгляд) хорошо, т.к. в такой ситуации снижаются издержки и у человечества, по идее, остаётся больше свободного времени и ресурсов :)

Реально классная статья, где человек сравнивает то, в чем, по собственным словам, специалистом не является, но пробовал в продаешене, с тем, в чем, опять же, специалистом не является и даже не пробовал. Вывод — Oracle круче, потому как enterprise и там крутятся миллиарды, а posgreSGL хуже потому как не требует десяток тыс долларов за доп возможности.

Стиль статьи, по моему, подразумевает battle Oracle vs. PostgreSQL… что, конечно, нехорошо.
Однако заставляет задуматься — правда ли приведенных вещей нет в PostgreSQL? Или там уже все есть и даже лучше? Кстати, как верно замечено выше, сравнивать надо не обычный Oracle а enterprize — ну тогда уж возмем не стандарный PostgreSQL а… скажем — PostgreSQL-XL (или там XS?). А там… даже лучше чем partition! И давно ведь. У меня получалось базу распараллелить на 115 машин и получать прирост раз в 90 примерно по производительности. И так далее… А если очень неймется обтирайтесь чем придется можно прямо внутри сервера дописать свой обработчик — и будет вам незамутненное счастье!
>У PostgreSQL партиции появятся только в 10 версии.
А какая, по-вашему, текущая релизная ветка уже с год как минимум?
>реализовать через Insert select и хитрый update. Но это далеко не тоже самое.
Обоснуйте, чего такого нельзя сделать с INSERT… ON CONFLICT… чего можно сделать с MERGE.

p.s. Единственное, что действительно хорошо в Оракле — это их столовые в главных офисных зданиях в Редвуде. Остальное так себе. А уж то, чего они натворили с Sun, гики никогда не простят.
Статья уровня детского сада, зерно сомнения не посеяли. Все эти «увеличения скорости в десятки раз» (пункты 1-4) имеют отношение только к Oracle vs. Oracle (или MSSQL vs. MSSQL): с включённой функцией или без неё и никакого отношения к Oracle vs. PostgreSQL (или MSSQL vs. PostgreSQL), т.к. Postgres изначально по другому спроектирован и имеет иные функции для увеличения производительности или изначально работает быстрее на обозначенных случаях.
Попробую написать комментарий в духе статьи. Как-то я писал хранимую процедуру в Oracle и долго не мог понять почему она работает не так, как должна. После долгой отладки выяснилось следующее. Я сохранял в колонку пустую строку '' и далее по коду при определенном условии проверял эту же строку на равенство пустой строке: column = ''. И вот эта проверка не отрабатывала. Само собой, выяснил я это только после перебора множества других вариантов. Оказалось банальная вещь — Oracle конвертирует пустую строку в NULL. Я полез читать почему же так происходит на форумы. О, эти прекрасные форумы. Самые адекватные ответы на подобные вопросы были «исторически сложилось, сорян», но были и другие типа «это же очевидно, не получил сертификат — не лезь».
Было еще несколько удивительных открытий в Oracle (например, невозможность создать булеву колонку), после которых сложилось некоторое отвращение. Но, все равно, я понимаю, что все зависит от задачи, а не от личных симпатий.
точно так же ораклойду хочется убить за то что в таблице половина значений нулл, другая пустая строка и нужно гадать. лошара просто забыл конвертировать в нулл или там какая-то бизнес логика, типа значение есть, но пользователь не заполнил.
лошара просто забыл конвертировать в нулл

Спасибо за комментарий, вспомнил те форумы, ностальгия. Т.е. по вашему вариант:
a = ''
if (a == '') {
//не срабатывает
}

логичный?
P.S. Это псевдокод, если что
по моему в 90% случаев в этом коде ошибка, а нужно if (a == '' or a is null)
и это косяк субд, а в оракле сделано правильно
> Я не являюсь экспертом БД Oracle хотя и проработал с этой БД много лет и не только с ней. Все что я умею — использовать ее преимущества и добиться оптимального быстродействия. Я тем более не являюсь экспертом PostgreSQL (я не разу не использовал его в продакшене).

Неспециалист пишет о том в чем не разбирается… Зачем вообще?
Пользуясь теми же аналогиями, Windows намного лучше Linux, т.к. в винде полноценная поддержка NTFS и DirectX. Само собой, «в десятки и сотни раз».
Ну и автор специально не затрагивал вещи связанные со стоимостью лицензии :) Тут разница может доходить до сотен раз :)
Цена
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. Я в отпуске(слишком поздно промодерировали), и не могу в онлайн комментировать. Некоторые коменти я постараюсь ответить завтра.

И да, всем спасибо за коментарии.

Ещё бы написал, что у Оракла есть exadata, где смарт сканы позволяют обходиться без индексов, а у постгреса этого нет. По сути сравнить Оракл и Постгрес не правильно, разного уровня задачи решаются.
Ну вот такого подлизывания к Оракл я еще не видел))))
Более того скажу, если эта БД просто исчезнет большинство вздохнут с облегчением. правда на рынок труда вывалится куча замкнутых в ее экосистеме людей.

P.S. Сравнение Оракл с постгре это просто пердец товарищ, это как сравнивать Ноги и КАМАЗ, ноги есть, а КАМАЗ стоит кучу бабла, при этом в 90% случаев нужно просто пройти метров 100.
Only those users with full accounts are able to leave comments. Log in, please.