Comments 23
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).
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 проще).
А ИМХО по поводу БД в том что продукты развиваются, и постепенно "бесплатные" продукты догоняют полностью коммерчнские(и в некоторых направлениях и обгоняют) поэтому ниша "платных" продуктов сужается и это в принципе (на мой взгляд) хорошо, т.к. в такой ситуации снижаются издержки и у человечества, по идее, остаётся больше свободного времени и ресурсов :)
А какая, по-вашему, текущая релизная ветка уже с год как минимум?
>реализовать через Insert select и хитрый update. Но это далеко не тоже самое.
Обоснуйте, чего такого нельзя сделать с INSERT… ON CONFLICT… чего можно сделать с MERGE.
p.s. Единственное, что действительно хорошо в Оракле — это их столовые в главных офисных зданиях в Редвуде. Остальное так себе. А уж то, чего они натворили с Sun, гики никогда не простят.
Было еще несколько удивительных открытий в Oracle (например, невозможность создать булеву колонку), после которых сложилось некоторое отвращение. Но, все равно, я понимаю, что все зависит от задачи, а не от личных симпатий.
лошара просто забыл конвертировать в нулл
Спасибо за комментарий, вспомнил те форумы, ностальгия. Т.е. по вашему вариант:
a = ''
if (a == '') {
//не срабатывает
}
логичный?
P.S. Это псевдокод, если что
Неспециалист пишет о том в чем не разбирается… Зачем вообще?
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. Я в отпуске(слишком поздно промодерировали), и не могу в онлайн комментировать. Некоторые коменти я постараюсь ответить завтра.
И да, всем спасибо за коментарии.
Более того скажу, если эта БД просто исчезнет большинство вздохнут с облегчением. правда на рынок труда вывалится куча замкнутых в ее экосистеме людей.
P.S. Сравнение Оракл с постгре это просто пердец товарищ, это как сравнивать Ноги и КАМАЗ, ноги есть, а КАМАЗ стоит кучу бабла, при этом в 90% случаев нужно просто пройти метров 100.
Oracle vs PostgreSQL. Почему выбор Oracle может быть разумным решением