Читая многочисленные статьи на хабре об успешной миграции с Oracle на PostgreSQL у неискушенного читателя может создаться впечатление что PostgreSQL ничем не хуже, а даже лучше Oracle. И выбор очевиден. А Сотни тысяч компаний, которые в итоге платят миллиарды долларов компании Oracle, просто тратят деньги на ветер. Но постараюсь вас разуверить, где-где, а в больших компаниях умеют считать деньги. И их решения отнюдь не ошибочны.
Цель статьи зародить зерно сомнения в душе читателя, который пытается сделать выбор между реляционными БД которые работают в режиме версионника. Почему именно режиме версионника? Здесь выбор не большой, а в блокировщиках есть достойные соперники и выбор еще сложнее.( Чего только стоит бесплатная версия DB2 для небольших БД).
Я не являюсь экспертом БД Oracle хотя и проработал с этой БД много лет и не только с ней. Все что я умею — использовать ее преимущества и добиться оптимального быстродействия. Я тем более не являюсь экспертом PostgreSQL (я не разу не использовал его в продакшене).
Читая статьи об успешной миграции — я понимаю что этим компаниям и не нужен был Oracle или БД была выбрана изначально не верно. Они использовали только малую долю возможностей этой БД. Только поэтому они могли принять решение об миграции, и его осуществить. Просто если использовать всю мощь этой БД — у вас никогда не возникнет желания мигрировать ибо это сродни написать ваше приложение почти с нуля.
Давайте, наконец, поговорим о тех преимуществах для быстродействия, которые дает Oracle и на основании этой информации Вы найдете ответ для себя сами.
Ну и как говорится, дьявол кроется в деталях, а у 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.
Цель статьи зародить зерно сомнения в душе читателя, который пытается сделать выбор между реляционными БД которые работают в режиме версионника. Почему именно режиме версионника? Здесь выбор не большой, а в блокировщиках есть достойные соперники и выбор еще сложнее.( Чего только стоит бесплатная версия 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.