Выявление преимуществ использования СУБД PostgreSQL над MySQL

Данная статья посвящена сравнительному анализу двух систем управления базами данных (СУБД): реляционной MySQL и объектно-реляционной PostgreSQL.

Исследование и сравнение свободно распространяемого программного обеспечения (ПО) является актуальным, поскольку финансовый аспект играет немаловажную роль в деятельности организаций. Приобретение платной лицензии СУБД для коммерческого использования становится довольно затратным мероприятием, особенно это затруднительно для организаций, находящихся на начальных стадиях развития, когда финансовое состояние может не предусматривать расходы на приобретение ПО. Так, например, для инсталляции коммерческой редакции MySQL Standard Edition Subscription в компании, имеющей около 20 пользователей, потребуется купить годовую лицензию на сервер стоимостью около 250 000 рублей. Таким образом, использование сервера СУБД на свободном программном обеспечении (вместо приобретения платной коммерческой лицензии MySQL) позволит организациям с небольшим числом сотрудников решить задачу автоматизации без финансовых затрат.

Рассмотрим один из возможных подходов решения данной задачи. Например, на компьютер с операционной системой семейства Linux можно установить распространяемую в свободном доступе версию объектно-реляционной СУБД PostgreSQL с открытым исходным кодом. Данного вида сервер позволяет беспрепятственно организовать доступ к стороннему установленному серверу или совместить с ролью базы данных иные роли (облачное хранилище, Web Server и пр.).

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

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

СУБД PostgreSQL, созданная на основе некоммерческой Postgres, также имеет коммерческие решения от компании EnterpriseDB, ориентированные на наличие коммерческой поддержки и интеграции с Oracle Database. Однако в данной статье будет рассмотрен функционал версии MySQL ветки 5.7 для сравнения с возможностями именно свободно распространяемой версии PostgreSQL 9.6 по следующим критериям:

·     общая производительность в нагрузке;

·     эффективность механизмов репликации;

·     наличие документации и соответствие стандартам;

·     простота администрирования.

Первым критерием сравнения СУБД в статье были выбраны механизмы репликации. В реализации репликации MySQL имеет место множество проблемных ситуаций – некорректность и нестабильность функционирования, часто невысокая производительность. При этом указанные ситуации являются не совсем связанными между собой или даже вовсе разносторонними. Обратившись к описаниям хронологически более ранних версий, можно сказать, что проблемы осуществления репликации в MySQL связаны не с неполноценностью работы самого механизма, а, без сомнения, с введением поддержки подключаемых движков (storage engine): MyISAM, InnoDB, HEAP, NDB и др. Таким образом, разработчики MySQL не решили уделить достаточное внимание вопросам синхронизации появившихся движков с журналом, а также способу их участия в репликации. В то же время, в начале 2000-х годов, попытавшись найти «storage engine» в исходном коде PostgreSQL, движков в нем невозможно было обнаружить, потому что там они на тот момент и не планировались создаваться. Свой выбор разработчики прокомментировали тем, что понимают высокую вероятность возможных угроз возникновения проблем с репликацией и транзакциями между движками.

На данный момент, спустя более 10 лет, ситуация такова, что в MySQL наблюдается некорректная работа транзакций между таблицами на разных движках, а также возникают проблемы с репликацией. За это время в PostgreSQL были реализованы подключаемые типы данных и индексы, появился механизм репликации. Этим преимущество MySQL над PostgreSQL, можно сказать, было ликвидировано, а проблемы первой СУБД остались не менее актуальными. В версии MySQL 5.7, анонсированной 23 апреля 2013 года, была проведена попытка увеличить эффективность репликации путем распараллеливания операций. Исходя из того, что любой масштабный проект, реализуемый на практике, сильно зависит от уровня производительности операций по репликации, заинтересованными лицами был проведен ряд тестов на производительность репликации в СУБД MySQL версий 5.5 и 5.7. В результате тестирования было выявлено, что в большинстве случаев однопоточная репликация версии MySQL 5.5 работает быстрее параллельной, реализованной в версии 5.7, т.е. для «нагруженных» проектов репликация последней версии является абсолютно неэффективной.

Также возможные проблемы, ведущие к неэффективности операций репликации в MySQL и в PostgreSQL, различаются своим характером: в первой СУБД они логические, а во второй – физические, соответственно используемым механизмам репликации. Логическая репликация, безусловно, имеет свои преимущества (независимость от формата хранения данных, доступность для чтения с каждого узла, частичная репликация отдельных таблиц и схем и др.). Однако физическая репликация PostgreSQL в силу большей оптимизации перекрывает превосходства MySQL, т.е. практически все то, чего нет в первой, уже можно реализовать сейчас или в скором времени.

Разница в производительности между различными уровнями репликации двух СУБД возникает в большей степени из-за того, что MySQL использует два или четыре журнала (для запросов и для репликации), а PostgreSQL достаточно одного. При этом механизм репликации в PostgreSQL, при котором запросы и операции репликации попадают в один журнал, является стабильным и оптимизированным, а дублирование транзакций между журналами в MySQL определенно негативно сказывается на производительности.

В PostgreSQL есть также триггерная репликация (Tungsten): по исполнению созданных триггеров данные передаются в таблицы или создаются файлы, которые затем читаются на реплике. Репликация MySQL же исполняется так, как предписывает движок, без возможности свободного изменения. Поэтому обозримое преимущество логической репликации MySQL на данный момент заключается только в большем возможном размере журнала.

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

На сегодняшний день имеет место критика при сравнении документации PostgreSQL с Oracle, в то время как MySQL с Oracle сравнивать никто не пытался. Сложившаяся ситуация позволяет предположить, что СУБД PosgreSQL по своим возможностям и производительности может конкурировать с мощной СУБД Oracle. Среди реализованных на PostgreSQL довольно крупных проектов выделяется 1C. Рассматриваемая СУБД частично может заменить мощную MS SQL.

Кроме того, PostgreSQL соответствует стандартам SQL-92, SQL-98, SQL-2003 и поддерживает многие возможности SQL-2011, когда MySQL не поддерживает даже SQL-92 и все еще не имеет эффективного оптимизатора. Очевидно, разработчики MySQL опустили то, что стандарты – это не мелкие изменения между версиями, а также новые функциональные возможности.

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

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

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