Oracle vs PostgreSQL: какую СУБД выбрать?

В то время как в государственном секторе повсеместно и в обязательном порядке происходит переход на свободное программное обеспечение, все больше коммерческих компаний задумываются о добровольной миграции с Oracle на свободную систему управления базами данных PostgreSQL.

Что приобретают и теряют компании при таком переходе? Ответ на этот вопрос искали участники конференции PgConf, которая прошла в начале февраля в Москве.

На ней начальник отдела технического консалтинга по серверным технологиям российского представительства Oracle Марк Ривкин предложил сравнивать СУБД по следующим критериям: производительность, безопасность, масштабируемость, обновляемость, уровень техподдержки, работа с большими объемами данных и цена владения. С таким подходом согласился и эксперт компании PostgreSQL-Consulting.com, специалист по базам данных PostgreSQL, DB2 и Oracle, Илья Космодемьянский.

Хорошо, давайте сравним. И начнем с основного, на наш взгляд, критерия.

Совокупная стоимость владения (Total Cost of Ownership или TCO).

Как известно, основными составляющими ТСО в мире софта являются цена приобретения и стоимость поддержки продукта. Определенное значение имеют и затраты на администраторов баз данных (DBA), но, согласно результатам исследований HeadHunter, эти расходы различаются в пределах 10%.

Стоит признать: цена приобретения Oracle высока, так же как и стоимость поддержки. Кроме того, каждую дополнительную функцию приходится приобретать отдельно, причем за немалые деньги. Об этом верно сказал Илья Космодемьянский: «Лицензии придумывают неглупые люди: Express и Standard-one выпущены для того, чтобы вы купили Enterprise и RAC».

Для примера приведем стоимость лицензии Oracle Enterprise Edition для одного 4-х ядерного CPU и цену сопровождения на один год — около 7,5 миллионов рублей.

Стоимость для ваших решений можно прикинуть в различных калькуляторах:

http://oracle.axoft.ru/catalog/rubric.php?RUBRIC_ID=322

http://www.fors.ru/services/delivery-oracle/calculation/

Как вы уже догадываетесь, именно TCO является ударным аргументом в пользу PostgreSQL, поскольку в случае выбора open-source СУБД цена приобретения является нулевой, аналогичная ситуация и со стоимостью сопровождения. Впрочем, об этом критерии стоит поговорить отдельно.

Сопровождение

Если вы думаете, что «бесплатно» – это синоним слова «плохо», то глубоко заблуждаетесь. Да, в случае с PostgreSQL возникшие проблемы будет решать «комьюнити», а не высокооплачиваемая (вами!) группа профессионалов. И потому вполне вероятно, что это будет сделано с некоторой задержкой, но она, как правило, не слишком критична, а значит, не приведет к серьезным последствиям. Для тех же компаний, кого такой подход не устраивает, есть выход: организации, которые занимаются профессиональной поддержкой PostgreSQL на высоком уровне. Их услуги, конечно, не бесплатны, но стоимость и условия более чем демократичны: нет годовых лицензий, штрафов за пропуск оплат и прочих «приятных» сюрпризов, которыми славится поддержка Oracle.

Кстати, а вы в курсе, что стоимость сопровождения Oracle в год составляет почти четверть стоимости лицензии? Причем эта сумма ежегодно возрастает на 3%-5%. В долларах, конечно. С более подробной информацией можно ознакомиться вот здесь:

http://www.fors.ru/upload/magazine/03/http_texts/fors_technical_support1.html

Производительность

Илья Космодемьянский признает, что оспаривать техническое первенство Oracle глупо. В общем случае эта СУБД обеспечивает больше транзакций в секунду (TPS), чем PostgreSQL. Во сколько раз? А вот на этот вопрос точно ответить пока никто не смог. Для того чтобы сравнить производительность Oracle и PostgreSQL, необходимо провести их тестирование в идентичных условиях: на одинаковом «железе» с равной нагрузкой, используя оптимальные операционные и файловые системы, а также осуществив сопоставимый по уровню «тюнинг» СУБД.

Сложность соблюдений этих условий, их высокая трудоемкость, отсутствие квалифицированных DBA ограничивают подобные исследования.

Тем не менее, на сайте pgconf представлены некоторые цифры по производительности PostgreSQL, правда, без указания ссылок на источники:

сайт Госдумы РФ – 100 ГБ данных, 400 000 хитов в день;
«Яндекс» – 500 млн транзакций в сутки, 5+ ТБ данных на четыре шарда;
Coub.com – 400 млн просмотров в сутки, 10 000 запросов в секунду.

Безопасность

О какой безопасности упоминал Марк Ривкин? Наверное, об опциях типа Oracle advanced security или Label security, которые входят только в самый дорогой пакет Enterprise edition. Это действительно «крутые «фичи», но они не столь актуальны в условиях ожидания новых санкций, которые могут привести к полному отказу в технической поддержке продукта или, что еще более катастрофично, к отключению наших облачных БД.

Масштабируемость

Теперь давайте посмотрим, как обстоят дела с масштабируемостью в Oracle. Начиная с версии Standard edition, предоставляется всем известный RAC (четыре сокета). Однако при работе с highload-проектами, вам, скорее всего, придется купить Enterprise edition, что влетит в копеечку.

В то же время сообщество PostgreSQL бесплатно предоставляет и расширения наподобие PL/Proxy от компании Skype, которое позволяет шардировать информацию по кластеру БД, и отдельные кластерные решения, базирующиеся на PostgreSQL – Postgres-XC и Postgres-XL.

Обновляемость

Oracle не гонится за частотой релизов. Как правило, новый релиз выходит раз в два-три года и отражает качественные изменения в соответствии с потребностями рынка. Проследим хронологию:

1998 год – выпущена версия 8i Release 1 (8.1.5), «i» в названии обозначает «internet», символизируя поддержку интернета.

2001 год – выпущена версия 9i Release 1 (9.0.1), поддержка XML, появление RAC.

2004 год – выпущена версия 10g Release 1 (10.1.0), «g» в названии обозначает «grid» («сеть»), символизируя поддержку грид-вычислений.

2007 год – выпущена версия 11g Release 1 (11.1.0.6).

2013 год – выпущена версия 12c (12.1.0.1), «с» в названии обозначает «cloud» («облако»). Основное новшество релиза – поддержка подключаемых баз данных, которая обеспечивает свойства мультиарендности и живой миграции БД.

Кроме того, ежеквартально выпускаются критические патчи.

Еще более нетороплив при смене номера версии PostgreSQL: релиз выходит примерно раз в пять лет. Но, в отличие от Oracle, добавление новых функций и обновление существующих происходит, по сути, постоянно. Так что, если вы готовы рискнуть стабильностью ради функциональности, обновлять СУБД можно хоть каждый день.

Объем изменений в межрелизных обновлениях можно косвенно оценить из того факта, что их краткое описание занимает несколько экранных страниц.

Ведущий разработчик PostgreSQL Олег Бартунов считает, что спектр возможностей этой СУБД расширяется намного быстрее, чем у Oracle. Поэтому вполне возможно, что в самое ближайшее время PostgreSQL займет лидирующие позиции в данном направлении.

Работа с очень большими данными

Так же как и в случае с производительностью, сравнивать СУБД по этому критерию достаточно сложно. С одной стороны, Enterprise версия Oracle при прочих равных условиях должна быть производительнее PostgreSQL по крайней мере за счет in-memory технологии, но для получения конкретных цифр необходимо сравнивать результаты на рабочих запросах. С другой – PostgreSQL не стоит на месте: в версии 9.4 появились huge pages, что дает прирост производительности от 10% до 30% на машинах с большим объемом памяти.

Для тех, кто хочет иметь некоторые опорные цифры, мы собрали статистику:

Сайт объявлений «Авито» (250 млн просмотров, 7 млн посетителей в сутки), количество серверов БД – около 30. Размер мастер-базы – 1.5 ТБ, более 3 000 запросов в секунду на просмотр информации и около 1 500 запросов в секунду на изменение.
Облачный сервис «Мой склад» с относительно «тяжелыми» запросами к БД: 6 серверов Intel обеспечивают одновременную работу 2 000 пользователей, генерирующих до 1 400 транзакций в секунду на БД размером 700 ГБ.
Компания «Яндекс» мигрировала с Oracle в части почтовой системы: размер БД – 2 ТБ (15+ млрд строк), производительность 40 000 запросов в секунду. Более подробную информацию можно найти здесь: http://www.slideshare.net/yandex/postgresql-39692656.

Итак, какой же совет мы можем дать тем, кто стоит перед выбором СУБД? PostgreSQL представляется достаточно зрелой системой, способной обеспечить потребности средних, а иногда и крупных корпораций (за примерами далеко ходить не надо – «Яндекс», «Авито», Skype). Поэтому, если ваш проект еще не выведен в «продуктив» или существует безболезненный вариант попробовать различные СУБД, то это стоит сделать. Как в таком случае минимизировать риски? На этот вопрос существует только один ответ: необходимо рассчитать, затем эмулировать боевую нагрузку и, в конце концов, оценить результат. Кстати, «Перфоманс Лаб» это умеет.

Если же перед вами стоит острая проблема «импортозамещения» уже работающей системы, то не стоит рисковать и, помолясь индийскому богу Ганеше, запускать скрипт миграции из Oracle в PostgreSQL (а такой скрипт есть). Как советует технический директор 404 Group Роман Друзягин, сначала нужно протестировать систему, зафиксировать все проблемы, найти пути их решения, провести несколько тестовых миграций и только затем, хорошенько выспавшись, устраивать час «Ч».