PostgreSQL или MySQL?

Скажем сразу — правильный ответ на вопрос “что лучше, PostgreSQL или MySQL?” звучит как “эти продукты не сравнимы”. Тем не менее, дискуссии и “священные войны” регулярно возникают вокруг этой темы, да и вопрос оперативного выбора СУБД для IT-проекта “с чистого листа” также имеет место быть.

 

Сила Слона

 

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

 

Документацию по MySQL можно назвать скорее формальной, чем полезной — на первый взгляд, честно описаны все опции, параметры и инструменты. Однако при возникновений практичеких кейсов, как правило, приходится гуглить ответы самостоятельно, либо обращаться за помощью к комьюнити — в отличие от изначально “задачно-ориентированной” документации по PostgreSQL.

 

Вопрос о производительности лучше всего демонстрирует тот факт, что PostgreSQL попадает в сравнения и обзоры вместе с таким титаном, как Oracle — при том, что сравнивать MySQL и Oracle в одних рядах, никому даже не приходит в голову.
Оптимизатор запросов в MySQL, конечно же, есть — но по сравнению с PostgreSQL он выглядит, скорее, как парсер и нормализатор. Соответственно, сколь-нибудь сложные запросы — совсем не то, чего можно ожидать от MySQL (к примеру, оптимизация запросов с union all — это из ряда вон для Дельфина). В PostgreSQL есть и качественный оптимизатор запросов, и гистограммы, и многое другое.
Помимо этого, корифей отечественного бухучета и ERP, система 1С, имеет в арсенале PostgreSQL-версию своих продуктов.

 

Следующий вопрос — соответствие SQL-стандартам (то есть, по сути — возможность адекватного масштабирования под различное клиентское ПО). PostgreSQL удовлетворяет спецификациям всех стандартов языка SQL, вплоть до SQL-2003 (и активно работает над совместимостью с SQL-2011).
Команда MySQL изначально не задавалась целью соответствия стандартам, поэтому и по сей день не дотягивает даже до SQL-92. Можно сказать, что политика MySQL ориентирована скорее, на обратную совместимость в своих продуктах и “особый путь” для функциональных новшеств, чем на поддержку стандартов языка.

Отдельным пунктом идет “строгое отношение” Слоника к синтаксису запросов — там, где MySQL “поймет и простит”, PostgreSQL вынудит разработчиков писать все сразу “хорошо и правильно”.

 

И все же Дельфин?..

 

Нужно сказать, что MySQL с настройками “из коробки” занимает места под БД именно столько, сколько они занимают (актуально при критичности места на дисках). Работа с множеством коннектов — также традиционное преимущество Дельфина.

 

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

МуSQL есть на любом shared-хостинге и поддерживается практически любыми CMS (а вот PostgreSQL, напротив, признает далеко не каждая контент-система).

 

По этим причинам, выбор между PostgreSQL и MySQL будет зависеть от ресурсов проекта, инструментов реализации и предполагаемой нагрузки.

 

Профессионально изучить оба продукта и попрактиковаться в использовании каждого из них вы можете на нашем авторском курсе «L2-DB. Администрирование баз данных на Linux”.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *