17 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

От Oracle к PostgreSQL – путь длиною в 4 года, доклад Андрея Рынкевича

Содержание

Oracle отговаривает россиян мигрировать на СУБД PostgreSQL

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

«Безопасность государства важна, и ее надо обеспечивать, но тот способ, который выбран, лично мне не очень нравится», — заявил на конференции разработчиков свободной СУБД PostgreSQL начальник отдела технического консалтинга по серверным технологиям российского представительства Oracle Марк Ривкин.

Иллюстрируя идею массового внедрения СПО как альтернативы решениям американских разработчиков, Ривкин привел метафору: «Котлован можно копать импортным бульдозером, а можно отечественной лопатой. Кардинально неправильный подход — не дожидаясь поломки бульдозеров начать вооружать всех лопатами».

Конечно, «на всякий несчастный случай» нужно иметь «План Б», говорит представитель Oracle. Но все же лучше до последнего момента использовать тот инструмент, который дает максимальную производительность, считает он.

Сейчас, говорит Ривкин, «людей заставляют заменять системы, которые обеспечивают высокую надежность и безопасность, на системы открытого кода». Где-то это оправдано, есть масса систем, в которых открытый код более предпочтителен, но есть ниши, системы с десятками тысяч пользователей, с сотнями терабайтов данных, «куда тоже пытаются запихнуть этот открытый код», и это неправильно, уверен он.

В понимании Марка Ривкина, «План Б» должен состоять в том, чтобы создавать приложения, работающие под разными базами данных: «Хотите — под Oracle, хотите — под Postgres, хотите — под DB2. Если что-то нехорошее случится, вы продолжите жить и работать».


Марк Ривкин из Oracle просит не спешить с миграцией на PostgreSQL. Слева направо: Владимир Захаров («Ланит»), Владимир Рубанов («НТЦ ИТ РОСА»), Марк Ривкин, Александр Жижкин («Иновентика технолоджес») и Олег Бартунов (Postgres Professional)

Ривкин жестко раскритиковал возможности СУБД PostgreSQL: «Слушая выступающих (на конференции — прим. CNews), непосвященному человеку, бизнесмену или менеджеру, который не имеет отношения к СУБД, становится непонятно, зачем платить бешеные деньги за западные продукты, когда и на свободном ПО все работает очень быстро, очень безопасно и гипернадежно годами. К сожалению, на самом деле ситуация выглядит совсем по-другому».

Известны критерии, по которым люди выбирают базу данных: это производительность, безопасность, масштабируемость, обновляемость, уровень техподдержки, работа с очень большими данными и цена владения, и по каждому из этих пунктов у PostgreSQL есть очень много дыр, полагает Ривкин.

«Возьмем самый простой вариант — производительность. В мире СУБД вот уже несколько лет происходит революция производительности систем. Я обычно говорю, что есть прошлое — года два назад, есть наше настоящее, и есть будущее, которое наступит уже в 2015 г.», — рассказывает он.

В «прошлом СУБД», говорит Ривкин, появились специализированные программно-аппаратные комплексы, машины баз данных, специализированное оборудование, на котором СУБД работают быстрее. Они увеличивают производительность на порядок.

«Сегодня» для роста производительности СУБД в Oracle используются технологии поколоночного хранения, процедуры векторных процессоров, преимущества большой памяти (обработка данных in-memory), что дает еще порядок роста производительности. «Завтра» появятся процессоры, «у которых в силикон зашиты команды СУБД. Они тестируются уже сейчас».

«Однако, послушав разработчиков PostgreSQL, я понял, что существует «позапрошлое», когда люди рассказывают, что они «тут немного код подтюнили, там функцию ускорили». Увеличение производительности [только] за счет резервов кода — это позавчерашний день разработки СУБД», — заявил представитель Oracle.


Олег Бартунов из Postgres Professional отвечает Марку Ривкину. Слева направо: Марк Ривкин (Oracle), Александр Жижкин («Иновентика технолоджес») и Олег Бартунов

Конечно, у Oracle есть чему поучиться, отвечает Ривкину гендиректор компании Postgres Professional Олег Бартунов. Postgres разрабатывают много людей с Oracle-бэкграундом, и сам Postgres всегда позиционировался как наиболее близкая к Oracle СУБД, нацеленная на надежность и целостность хранения данных, говорит он.

Однако, напоминает Бартунов, то, что в Postgres разрабатывается сейчас, у Oracle еще не появилось — например, возможности обработки неструктурированных данных.

«Не зря EnterpriseDB (американского вендора и разработчика Postgres — прим. CNews) в 2014 г. включили в магический квадрат Gartner вместе с Oracle, а 64 компании из Fortune-500 и 111 компаний из Forbes являются пользователями Postgres», — добавляет он.

В то же время, по приведенным Олегом Бартуновым данным, Oracle сейчас занимает до 70% российского рынка СУБД.

Что же касается машин для баз данных, то «железные эплайнсы» под Postgres у Fujitsu появились еще раньше, чем у Oracle, уточняет гендиректор Postgres Professional.

Базы данных, построенные на СУБД PostgreSQL, способны демонстрировать высокую производительность, говорит Бартунов: «Не думаю, что у японских компаний, например, NHK, или у фонда пенсионного обеспечения Франции, которые работают на Postgres, маленькие нагрузки».

Владимир Захаров, руководитель направления «Электронное правительство» в «Ланите», рассказывает, что в его компании уже есть решения, которые работают как на Postgres, так и на Oracle. «Для ряда задач не нужен Oracle, нет необходимости оплачивать эти безумные лицензии», — говорит он.

Явный интерес российских властей к открытой СУБД PostgreSQL как альтернативе Oracle был публично продемонстрирован на этой же конференции главой Минкомсвязи Николаем Никифоровым, который заявил, что PostgreSQL является «важнейшим инструментом в нынешней политике импортозамещения».

Немного ранее стало известно, что основатель и бывший гендиректор интегратора «Энвижн Груп» Антон Сушкевич инвестировал несколько миллионов долларов в компанию Postgres Professional, созданную командой живущих в России ведущих разработчиков (Major Contributor) PostgreSQL.

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 миллионов рублей.

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

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

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

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

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

Читать еще:  Victoria privileged instruction что делать?

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

Илья Космодемьянский признает, что оспаривать техническое первенство 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 Роман Друзягин, сначала нужно протестировать систему, зафиксировать все проблемы, найти пути их решения, провести несколько тестовых миграций и только затем, хорошенько выспавшись, устраивать час «Ч».

Сравнение PostgreSQL, Oracle и MySQL на боевой нагрузке

Если вы хотите подробнее ознакомиться с возможностями обеих СУБД, мы подобрали для вас ссылки:

«Яндекс»: Переход с Oracle на открытое ПО.

В июле 2016 года «Яндекс» завершил перевод своего почтового сервиса на PostgreSQL. Переписывание всего кода для работы с Oracle и PostgreSQL в общей сложности заняло 10 человеко-лет.

Развертывание почтового сервиса на базе PostgreSQL потребовало использования в три раза больше аппаратного обеспечения.

Экономический эффект от миграции в компании предпочли не комментировать, равно как и планы по переводу с Oracle на PostgreSQL каких-либо других своих систем и сервисов.

Недостатки СУБД Oracle

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

Во-первых, Oracle стоит как чугунный мост. Во-вторых, частенько мы наталкиваемся на какие-то внутренние оракловые проблемы. Единственный способ что-то сделать — это обратиться в поддержку. Они нам обещают, что когда-нибудь починят, но «когда-нибудь» — это плохо. Нам надо прямо сейчас. По этим двум причинам мы решили отказываться от Oracle, — об этом говорил Владимир Бородин, выступая на конференции PostgreSQL Meetup еще в сентябре 2014 года

На конференции PGConf в феврале 2015 года он отмечал, что Oracle перестал устраивать «Яндекс» задолго до санкций и импортозамещения.

2012-2013: Старт проекта миграции на PostgreSQL и «пилот»

В 2012 году компания приняла «политическое» решение избавиться от Oracle за три года.
С июля 2013 года июнь 2014 года «Яндекс» проводил эксперимент на базе PostgreSQL со сборщиками почты. Сборщик — это «такая штука, которая ходит в другие почтовые системы по IMAP или POP3, собирает письма и кладет к вам в ящик. Нужно хранить информацию, куда и как ходить, и информацию о том, что уже собрано. Все метаданные лежали в Oracle, ровно как и все метаданные почты», рассказывал Владимир Бородин.
В результате миграции сборщиков в Postgres было перенесено 2,5 ТБ данных (около 17 млрд строк). Нагрузка системы — 40 тыс. запросов в секунду. По времени проект занял примерно полгода.
На лицензиях в результате отказа от Oracle в этом проекте, по словам Бородина, сэкономили столько, «что людям, которые этим занимаются, хватит на Бентли».

2015: Сотрудничество с Postgres Professional

По мнению Олега Бартунова, гендиректора компании «Постгрес Профессиональный», «Яндекс» всерьез заинтересовался Postgres. «За последнее время я прочитал их сотрудникам три лекции», — сообщил он TAdviser в июле 2015 года.

В проекте миграции почты «Яндекс» «сам проявил инициативу, сэкономил кучу денег, обеспечил нагрузку, отказоустойчивость», добавляет заместитель гендиректора «Постгрес Профессиональный» Иван Панченко.

Но интерес «Яндекса» в отношении Postgres, по словам Бартунова, гораздо шире, чем почтовый проект (в самом «Яндексе» это не подтверждают).

Они обратились к нам с просьбой создать в Postgres такие инструменты, чтобы им было легче проводить миграцию других систем, — рассказал TAdviser гендиректор «Постгрес Профессиональный». — Мы сделали возможность профилирования базы данных для работы в многоядерных серверах — это вещь, которая нужна всем владельцам крупных систем. Ее наличие позволит сделать Postgres еще более подходящим для крупных заказчиков.

Читать еще:  Как восстановить стертые файлы с жесткого диска?

В «Яндексе» TAdviser пояснили, что «Постгрес Профессиональный» разрабатывает для компании дополнительную функциональность, связанную с диагностикой и оптимизацией производительности: «Через некоторое время она будет доступна в бесплатной открытой сборке PostgreSQL, чтобы ей могли пользоваться и другие разработчики – это одно из условий нашего договора».
В «Постгрес Профессиональный» называют «Яндекс» одним из важнейших клиентов: «Для многих других компаний он является серьезным примером, показывающим возможности Postgres».

2016: Завершение миграции

К декабрю 2015 года сборщики почты были полностью переведены на новую СУБД, а в январе 2016 года начался основной перенос на нее почтового сервиса, следует из материалов Владимира Бородина. По итогам проекта в «Яндекс» осознали, что это далеко не последний проект с Postgres: «Нам очень понравилось. Были запущены другие проекты».

В июле 2016 года «Яндекс» завершил перевод своего почтового сервиса на PostgreSQL. Переписывание всего кода для работы с Oracle и PostgreSQL в общей сложности заняло 10 человеко-лет, приводят данные в «Яндексе».

Возникшие в процессе миграции проблемы Владимир Бородин связывает, в основном, не с PostgreSQL, а с данными: за более чем 10 лет существования «Яндекс.Почты» их накопилось очень много. Кроме того, возникали ошибки в коде переноса. В «Яндексе» заявили TAdviser, что в основном работали над ошибками в логике переноса данных.

В целом сложностей в ходе эксплуатации почты на PostgreSQL оказалось меньше, чем ожидал «Яндекс», но они, конечно, были, отметили в разговоре с TAdviser представители компании.

Развертывание почтового сервиса на базе PostgreSQL потребовало использования в три раза больше аппаратного обеспечения. Это связано с принципиальными различиями используемого «железа», с изменившейся нагрузкой на СУБД и ее производительностью, объяснили TAdviser в «Яндексе».

Мы перешли от вертикального масштабирования небольшого количества дорогих серверов к горизонтальному, когда серверов больше, но они дешевле, — заявили TAdviser в «Яндексе», добавив, что при этом изменилась только структура, производители не менялись.

Говоря о преимуществах PostgreSQL, в «Яндексе» отметили:

PostgreSQL – открытая система, поэтому мы можем сами оперативно решать возникающие проблемы. Это важно для сервиса, работающего в режиме 24/7. Кроме того, в PostgreSQL кэш библиотек не блокируется, а значит развертывание изменений (в том числе и на этапе тестирования) становится проще, — заявили TAdviser в компании.

Экономический эффект от миграции в компании предпочли не комментировать, равно как и планы по переводу с Oracle на PostgreSQL каких-либо других своих систем и сервисов. Ранее Владимир Бородин рассказывал, что PostgreSQL успешно используется в «Яндекс.Картах» — «из-за божественного PostGIS’а». В этом проекте свободная СУБД была выбрана изначально.

Сравнение MySQL и PostgreSQL

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

MySQL существует достаточно давно и зарекомендовала себя как отличное решение, Postgresql пришла на рынок приблизительно в то же самое время, но предоставляет достаточно много интересных функций и возможностей, благодаря чему стремительно набирает популярность. В этой статье мы попытаемся выполнить сравнение MySQL vs Postgresql, сравним основные отличия этих систем, выясним как они работают и попытаемся понять какая система будет лучше для вашего проекта.

Системы управления базами данных

Базы данных предназначены для структурированного хранения и быстрого доступа к различным данным. Каждая база данных, кроме самих данных, должна иметь определенную модель работы, по которой будет выполняться обработка данных. Для управления базами данных используются СУБД или системы управления базами данных, именно к таким программам относятся MySQL и Postgresql.

Реляционные системы управления базами данных позволяют размещать данные в таблицах, связывая строки из разных таблиц и, таким образом, связывая разные, объединенные логически данные. Перед тем, как вы сможете сохранять данные, необходимо создать таблицы определенного размера и указать тип данных для каждого столбца. Столбы представляют поля данных, а сами данные размещены в строках. Обе системы управления базами данных, и MySQL vs Postgresql принадлежат к реляционным. Дальше мы рассмотрим подробнее чем отличаются обе программы. А теперь перейдем к более детальному рассмотрению.

Краткая история

MySQL

Разработка MySQL началась еще в 90х годах. Первый внутренний выпуск базы данных состоялся в 1995 году. За это время разработкой программы занимались несколько компаний. Разработка была начата шведской компанией MySQL AB, которую приобрела Sun Microsystems, которая, собственно перешла в собственность Oracle. На данный момент, начиная с 2010 года, разработкой занимается Oracle.

Postgresql

Разработка Postrgresql началась в далеком 1986 году в стенах Калифорнийского университета Беркли. Разработка длилась почти восемь лет, затем проект разделился на две части коммерческую базу данных IIlustra и полностью свободный проект Postrgesql, который разрабатывается энтузиастами.

Хранение данных

MySQL

MySQL — это реляционная база данных, для хранения данных в таблицах используются различные движки, но работа с движками спрятана в самой системе. На синтаксис запросов и их выполнение движок не влияет. Поддерживаются такие основные движки MyISAM, InnoDB, MEMORY, Berkeley DB. Они отличаются между собой способом записи данных на диск, а также методами считывания.

Postgresql

Postgresql представляет из себя объектно реляционную базу данных, которая работает только на одном движке — storage engine. Все таблицы представлены в виде объектов, они могут наследоваться, а все действия с таблицами выполняются с помощью объективно ориентированных функций. Как и в MySQL все данные хранятся на диске, в специально отсортированных файлах, но структура этих файлов и записей в них очень сильно отличается.

Стандарт SQL

Независимо от используемой системы управления базами данных, SQL — это стандартизированный язык выполнения запросов. И он поддерживается всеми решениями, даже MySQL или Postgresql. Стандарт SQL был разработан в 1986 году и за это время уже вышло нескольких версий.

MySQL

MySQL поддерживает далеко не все новые возможности стандарта SQL. Разработчики выбрали именно этот путь развития, чтобы сохранить MySQL простым для использования. Компания пытается соответствовать стандартам, но не в ущерб простоте. Если какая-то возможность может улучшить удобство, то разработчики могут реализовать ее в виде своего расширения не обращая внимания на стандарт.

Postgresql

Postgresql — это проект с открытым исходным кодом, он разрабатывается командой энтузиастов, и разработчики пытаются максимально соответствовать стандарту SQL и реализуют все самые новые стандарты. Но все это приводит к ущербу простоты. Postgresql очень сложный и из-за этого он не настолько популярен как MySQL.

Возможности обработки

Из предыдущего пункта выплывают и другие отличия postgresql от mysql, это возможности обработки данных и ограничения. Естественно, соответствие более новым стандартам дает более новые возможности.

MySQL

При выполнении запроса MySQL загружает весь ответ сервера в память клиента, при больших объемах данных это может быть не совсем удобно. В основном по функциям Postgresql превосходит Mysql, дальше рассмотрим в каких именно.

Postgresql

Postgresql поддерживает использование курсоров для перемещения по полученным данным. Вы получаете только указатель, весь ответ хранится в памяти сервера баз данных. Этот указатель можно сохранять между сеансами. Здесь поддерживается построение индексов сразу для нескольких столбцов таблицы. Кроме того, индексы могут быть различных типов, кроме hash и b-tree доступны GiST и SP-GiST для работы с городами, GIN для поиска по тексту, BRIN и Bloom.

Postgresql поддерживает регулярные выражения в запросах, рекурсивных запросов и наследования таблиц. Но тут есть несколько ограничений, например, вы можете добавить новое поле только в конец таблицы.

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

Базы данных должны обязательно быть оптимизированы для окружения, в котором вы будете работать. Исторически так сложилось что MySQL ориентировалась на максимальную производительность, а Postgresql разрабатывалась как база данных с большим количеством настроек и максимально соответствующую стандарту. Но со временем Postgresql получил много улучшений и оптимизаций.

MySQL

В большинстве случаев для организации работы с базой данных в MySQL используется таблица InnoDB, эта таблица представляет из себя B-дерево с индексами. Индексы позволяют очень быстро получить данные из диска, и для этого будет нужно меньше дисковых операций. Но сканирование дерева требует нахождения двух индексов, а это уже медленно. Все это значит что MySQL будет быстрее Postgresql только при использовании первичного ключа.

Postgresql

Вся заголовочная информация таблиц Postgresql находится в оперативной памяти. Вы не можете создать таблицу, которая будет не в памяти. Записи таблицы сортируются по индексу, а поэтому вы можете их очень быстро извлечь. Для большего удобства вы можете применять несколько индексов к одной таблице.

В целом PostgreSQL работает быстрее, за исключениям использования первичных ключей. Давайте рассмотрим несколько тестов с различными операциями:

Типы данных

Один из основных моментов обоих баз данных это поддерживаемые типы данных, которые вы можете использовать. Поскольку оба решения пытаются соответствовать синтаксису SQL, то они имеют похожие наборы, но все же кое-чем отличаются.

MySQL

MySQL поддерживает такие типы данных:

  • TINYINT: очень маленькое целое.;
  • SMALLINT: маленькое целое;
  • MEDIUMINT: целое среднего размера;
  • INT: целое нормального размера;
  • BIGINT: большое целое;
  • FLOAT: знаковое число с плавающей запятой одинарной точности;
  • DOUBLE, DOUBLE PRECISION, REAL: знаковое число с плавающей запятой двойной точности
  • DECIMAL, NUMERIC: знаковое число с плавающей запятой;
  • DATE: дата;
    DATETIME: комбинация даты и времени;
  • TIMESTAMP: отметка времени;
  • TIME: время;
    YEAR: год в формате YY или YYYY;
  • CHAR: строка фиксированного размера, дополняемая справа пробелами до максимальной длины;
  • VARCHAR: строка переменной длины;
  • TINYBLOB, TINYTEXT: двоичные или текстовые данные максимальной длиной 255 символов;
  • BLOB, TEXT: двоичные или текстовые данные максимальной длиной 65535 символов;
  • MEDIUMBLOB, MEDIUMTEXT: текст или двоичные данные;
  • LONGBLOB, LONGTEXT: текст или двоичные максимальной данные длиной 4294967295 символов;
  • ENUM: перечисление;
  • SET: множества.
Читать еще:  Чувствительность наушников дб какое лучше?

Postgresql

Поддерживаемые типы полей в Postgresql достаточно сильно отличаются, но позволяют записывать точно те же данные:

  • bigint: знаковое 8-байтовое целое;
  • bigserial: автоматически увеличиваемое 8-байтовое целое;
  • bit: двоичная строка фиксированной длины;
  • bit varying: двоичная строка переменной длины;
  • boolean: флаг;
  • box: прямоугольник на плоскости;
  • byte: бинарные данные;
  • character varying: строка символов фиксированной длины;
  • character: строка символов переменной длины;
  • cidr: сетевой адрес IPv4 или IPv6;
  • circle: круг на плоскости;
  • date: дата в календаре;
  • double precision: число с плавающей запятой двойной точности;
  • inet: адрес интернет IPv4 или IPv6;
  • integer: знаковое 4-байтное целое число;
  • interval: временной промежуток;
  • line: бесконечная прямая на плоскости;
  • lseg: отрезок на плоскости;
  • macaddr: MAC-адрес;
  • money: денежная величина;
  • path: геометрический путь на плоскости;
  • point: геометрическая точка на плоскости;
  • polygon: многоугольник на плоскости;
  • real: число с плавающей точкой одинарной точности;
  • smallint: двухбайтовое целое число;
  • serial: автоматически увеличиваемое четырехбитное целое число;
  • text: строка символов переменной длины;
  • time: время суток;
  • timestamp: дата и время;
  • tsquery: запрос текстового поиска;
  • tsvector: документ текстового поиска;
  • uuid: уникальный идентификатор;
  • xml: XML-данные.

Как видите, типов данных в Postgresql больше и они более разнообразны, есть свои типы полей для определенных видов данных, которых нет MySQL. Отличие MySQL от Postgresql очевидно.

Разработка

Оба проекта имеют открытый исходный код, но развиваются по-разному. Развитие MySQL нравится далеко не всем. И в этом сравнение mysql и postgresql дает много отличий.

MySQL

База данных MySQL разрабатывается компанией Oracle и ходят слухи, что компания намерено тормозит развитие движка. Было создано очень много форков проекта, в том числе форк MariaDB от разработчика оригинальной MySQL. Но все же развитие остается медленным.

Postgresql

Как было сказано в начале статьи разработка началась в университете Беркли. Затем перешла в коммерческую компанию. Сейчас программа разрабатывается независимой группой программистов и советом нескольких компаний. Новые версии выпускаются достаточно активно и получают все новые и новые функции.

Выводы

В этой статье мы выполнили сравнение mysql и postgresql, рассмотрели основные отличия обоих систем управления базами данных и попытались понять что лучше postgresql или mysql. В общем результате лучшим по возможностях получается Postgresql, но он сложен и не везде его можно применять. MySQL проще, но не поддерживает некоторых интересных функций. А какую базу данных вы выберите для своего проекта? Почему именно ее? Напишите в комментариях!

На завершение видео с описанием возможностей и перспектив Postgresql:

В Ria.ru поменяли Oracle на PostgreSQL

31 марта 2016 в 13:05
Roem.ru / editor@roem.ru

По информации Roem.ru , «Россия сегодня» ( в эту медиагруппу входят Ria.ru , «Прайм», ИноСМИ и другие проекты. Russia Today в группу не входит) прекратили использование продуктов Oracle. Все необходимые техпроцессы теперь завязаны на PostgreSQL , сопровождение которой обходится « на порядок дешевле».

Миграцией вторую половину 2015-го года занимались бывшие сотрудники Rambler Михаил Чеканов ( Михаил ещё известен руководством веб-проектов Олимпийских игр в Сочи) и Сергей Томулевич. По словам Михаила Чеканова , получившаяся инфраструктура на базе PostgreSQL обходится « на порядок дешевле», подрядчики в ходе переезда не привлекались , внутри проекта использовали имеющиеся ресурсы: переводили часть проектов на PostgreSQL , освобождали оборудование , после чего переводили следующую часть.

По мнению Михаила Чеканова , парадоксом Oracle является то , что их главное конкурентное преимущество на рынке — это цена ( которая , естественно , выше , чем у вариантов внедрения на PostgreSQL). Как объясняет Михаил Чеканов , в процессе выбора решения для инфраструктуры , лица принимающие решение могут обосновать выбор Oracle как « самое лучшее на рынке решение» и его « лучшесть» очевидна и понятна начальству из-за цены. Любое другое решение в случае каких-либо проблем даёт CTO возможность сказать , что начальство само виновато , поскольку не последовало рекомендациям технарей.

Использование Oracle , тем не менее , не гарантирует работоспособности даже критических приложений: например , в 2012-м году « Сбербанк» пережил падение процессинга своих карт , которое продолжалось вечером пятницы в течение трёх часов.

Как Oracle появился в «РИА Новостях»

На Oracle проекты МИА « Россия сегодня» ( тогда ещё РИА « Новости») перешли в 2008-м году с той же PostgreSQL. Анатолий Стояновский , отвечавший за переезд в 2008-м , в комментарии Roem.ru так описал процесс и причины перевода:

Oracle использовался прежде всего для хранения особо критичных данных — в случае РИА это был новостной контент. У нас сложилась такая конфигурация — под базы данных Oracle были отданы лучшие сервера , лучшая команда DBA и системных администраторов. За почти 9 лет я не помню ни одной существенной аварии с потерей данных , и только несколько , приведших к короткой недоступности. Дальше это уже напоминает снежный ком: новые проекты автоматически строятся на Oracle. Эта СУБД обладает таким инструментарием анализа и оптимизации запросов , позволяет настолько детально препарировать их исполнение под высокой нагрузкой , что достаточно быстро это стало определяющим фактором в быстрой разработке.

Если говорить о нашей веб-платформе , то вопрос о переезде на более дешевые альтернативы поднимался почти каждый год. Мы безусловно имели возможность в любой момент начать перенос собственного ПО на другое хранилище данных. Но каждый раз баланс между рисками пусть временного , но снижения надежности и темпами развития склонялся в сторону последнего. Что означает проект переезда в ситуации динамично развивающейся компании? Команда разработчиков перестает заниматься новыми проектами на год ( в нашем случае , т.к. ораклового кода было много). Мало перенести код , нужно его заново оптимизировать. Используя Oracle , мы потратили много времени на оптимальную балансировку производительности всех запросов , индексов , конфигураций и т. п. — в больших базах данных с динамическими ( разными) запросами и высокой нагрузкой это очень важно. Немаловажный фактор — переобучение или замена системных администраторов. Не каждый сертифицированный Oracle DBA с таким же энтузиазмом переключится другие СУБД.

Первым этапом ( еще в 2008 году) мы перенесли из Oracle в Postgres все данные , связанные с кэшированием , так что теперь мы могли горизонтально масштабироваться без приобретения дополнительных лицензий. Вторым этапом начался перенос некритичных к потере данных в другие хранилища ( в основном это был MongoDB) — контент остался в Oracle , а такие вещи , как данные о пользователях и их поведении переехали в более удобные для таких задач хранилища. Третьим этапом был осуществлен перенос контента и полный отказ от Oracle ( эту часть команда делала уже без меня — после ликвидации РИА Новости у программистов появилась возможность нормально сфокусироваться на этом проекте). Насколько я знаю , качеством работы под Postgres сейчас довольны.

Резюмируя , изначально Oracle был выбран по классической стратегии « не плодить зоопарк» — часть систем уже использовали эту СУДБ с каких-то древних лет , одно цеплялось за другое. Каждая новая команда сначала смотрела на Oracle с опаской , но спустя какое-то время признавала удобство работы. В условиях динамичного развития , оказалось дешевле оплачивать лицензии , чем связывать ресурсы команды переносом кода , хотя технологическая возможность этого в будущем закладывалась изначально. И далее — «мягкий» многоэтапный переезд на бесплатные аналоги с аккуратным планированием ресурсов.

Кто отходит от Oracle

Цены на лицензии Oracle номинируются в рублях , но привязаны к доллару , что сильно увеличило стоимость поддержки IT-систем после роста курса доллара за последние полтора года. От продукции Oracle последовательно отказывались:

Этим список « отказников» не исчерпывается , и Oracle , в качестве меры противодействия , разослал по партнёрам инструкцию как убеждать клиентов выбирать продукты Oracle для внедрения: больше всего неприятностей у Oracle будет именно в будущем. То же «Открытие» не только перевело часть своих систем на PostgreSQL , но и создало задел дальнейшей миграции с Oracle.

« Мы реализуем стратегию перехода с дорогостоящих решений на СПО , в частности постепенно отказываемся от Oracle в пользу свободно распространяемых баз данных , таких как PostgreSQL и Tibero. Пока рассматриваем и осуществляем миграцию не критических для бизнеса систем , предварительно проводя оценку эффективности и трудоемкости миграции. Уже наращиваем внутреннюю компетенцию по сопровождению этих баз данных. В разработке новых систем дистанционного банковского обслуживания изначально закладываемся в сторону свободно распространяемых технологий и баз данных» — говорит Дмитрий Федоров , директор по развитию интернет технологий , ПАО « Ханты-Мансийский Банк Открытие»

Олег Бартунов , CEO Postgres Professional , по сути уже отвечал на претензии Oracle в отношении PostgreSQL, в частности , он отмечал , что проблем с производительностью PostgreSQL систем не выявляли крупные заказчики вроде пенсионного фонда Франции.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector