1.11.2.2 Сравнение возможностей MySQL и PostgreSQL

На странице crash-me (http://www.mysql.com/information/crash-me.php) приведен список ограничений и особенностей СУБД, которые могут быть обнаружены автоматически с помощью специальных программ. Однако не стоит забывать о том, что многие ограничения могут быть изменены настройкой соответствующих баз данных. Впрочем, эта web-страница оказывается очень кстати, если необходимо, чтобы создаваемое приложение нормально работало с несколькими СУБД или для перевода приложения с одной СУБД в другую.

MySQL обладает следующими преимуществами перед PostgreSQL:

• MySQL обычно намного превосходит PostgreSQL по скорости работы. Кроме того, в MySQL 4.0 реализован кэш запросов. Он позволяет во много раз увеличить скорость обработки запросов для сайтов, на которых преобладают неоднократно повторяющиеся запросы на чтение.
• По количеству пользователей MySQL также намного превосходит PostgreSQL. Поэтому код тестируется значительно более придирчиво и опытным путем доказана большая его надежность, нежели у PostgreSQL. MySQL чаще, чем PostgreSQL, используется на производстве, в основном потому, что компания MySQL AB (ранее - TCX DataKonsult AB) предоставляет высококачественную коммерческую техническую поддержку MySQL с момента появления этой системы на рынке, а у PostgreSQL до самого последнего времени никакой поддержки не было.
• MySQL работает в среде Windows лучше, чем PostgreSQL. MySQL Server запускается как настоящее (родное) Windows-приложение (в NT/2000/XP - сервис), в то время как PostgreSQL запускается в среде эмуляции, Cygwin. Нам доводилось слышать о недостаточной стабильности работы PostgreSQL в среде Windows, но самостоятельно эти сведения до сих пор мы проверить не могли.
• MySQL оснащен большим количеством API для других языков и поддерживается большим количеством существующих программ, нежели PostgreSQL. See section B Привнесенные программы.
• MySQL работает на высоконадежных промышленных системах 24/7 (включенных 24 часа в сутки 7 дней в неделю). В большинстве случаев никаких ``чисток'' в MySQL производить не требуется. PostgreSQL же пока что не может работать в таких системах, так как иногда приходится запускать VACUUM для освобождения занятого последствиями работы команд UPDATE и DELETE пространства и проводить статистический анализ, необходимый для достижения максимальной производительности PostgreSQL. Запускать VACUUM необходимо и после каждого добавления к таблице нескольких столбцов. На напряженно работающих системах VACUUM нужно запускать более часто, в худших случаях - по несколько раз в день. А ведь во время работы VACUUM (а ее работа может продолжаться часы, если база данных достаточно велика) база практически ``мертва''. Впрочем, в PostgreSQL версии 7.2 выполнение основных функций этой программы больше не приводит к блокировке базы, и пользователи могут продолжать нормально работать с ней. Новая команда VACUUM FULL берется за дело более серьезно: она, как и в старых версиях, блокирует таблицу и сжимает копию таблицы на диске.
• Репликация MySQL отлично протестирована и используется в таких сайтах, как:
  • Yahoo Finance (http://finance.yahoo.com/)
  • Mobile.de (http://www.mobile.de/)
  • Slashdot (http://www.slashdot.org/)
• В комплект поставки MySQL входят два тестовых пакета, mysql-test-run и crash-me (http://www.mysql.com/information/crash-me.php), а также пакет для замеров производительности. Тестовая система постоянно обновляется, в нее добавляется код для тестирования всех новых возможностей и почти всех воспроизводимых ошибок, которые попали в поле нашего зрения. Перед выпуском каждой новой версии мы используем эти пакеты для тестирования MySQL на нескольких платформах. Наши тесты значительно превосходят по своим возможностям все существующие в PostgreSQL аналоги, и обеспечивают высокое качество кода MySQL.
• Книг о MySQL вышло значительно больше, нежели о PostgreSQL. Книги о MySQL выпустили издательства O'Reilly, SAMS, Que и New Riders. Все возможности MySQL детально описаны в документации, так как это является обязательным условием включения новых возможностей в код.
• MySQL поддерживает больше стандартных функций ODBC, чем PostgreSQL.
• MySQL обладает значительно более мощной реализацией ALTER TABLE.
• В MySQL предусмотрена возможность создания таблиц без транзакций, что необходимо приложениям, требующим максимально возможной скорости работы. Эти таблицы могут храниться в памяти, относиться к типу HEAP-таблиц или дисковых MyISAM. See section 7 Типы таблиц MySQL.
• MySQL может работать с двумя поддерживающими транзакции обработчиками таблиц, а именно - InnoDB и BerkeleyDB. Так как все системы поддержки транзакций в разных условиях работают по-разному, это дает разработчику возможность найти наилучшее решение для условий, в которых будет работать его система. See section 7 Типы таблиц MySQL.
• Команда слияния таблиц MERGE предоставляет в ваше распоряжение уникальную возможность создать представление нескольких идентичных таблиц и работать с ними как с одной. Это особенно удобно для работы с журналами, разбитыми, например, по месяцам. See section 7.2 Таблицы MERGE.
• Возможность сжатия доступных только для чтения таблиц, не отменяющая прямого доступа к их записям, повышает производительность системы, снижая количество операций считывания с диска. Это особенно полезно при архивировании. See section 4.7.4 myisampack, MySQL-генератор сжатых таблиц (только для чтения).
• В MySQL реализован полнотекстовый поиск. See section 6.8 Полнотекстовый поиск в MySQL.
• Имеется возможность работы с несколькими базами через одно соединение (разумеется, в зависимости от привилегий пользователя).
• Система MySQL с самого начала разрабатывалась в расчете на многопоточность, а PostgreSQL использует процессы. Переключение контекстов и доступ к общим данным несколькими потоками осуществляется значительно быстрее, нежели отдельными процессами. Таким образом MySQL Server в многопользовательских приложениях получает неплохое преимущество в производительности, а кроме того, таким образом MySQL Server удается значительно эффективней пользоваться преимуществами, предоставляемыми симметричными мультипроцессорными системами (SMP).
• В MySQL реализована значительно более мощная система привилегий, нежели в PostgreSQL. В то время как PostgreSQL обеспечивает лишь привилегии INSERT, SELECT и UPDATE/DELETE над базой или таблицей, MySQL предоставляет возможность определения полного набора разнообразных привилегий на уровне базы, таблицы и столбца. Кроме того, MySQL позволяет задавать привилегии для комбинаций хост/пользователь. See section 4.3.1 Синтаксис команд GRANT и REVOKE.
• В MySQL используется протокол связи между клиентом и сервером со сжатием данных, что увеличивает производительность системы в условиях низкоскоростных каналов связи.
• Насколько нам известно, только в реляционной системе баз данных MySQL Server используется концепция ``обработчика таблиц''. Благодаря этому создается возможность работы с различными низкоуровневыми типами таблиц из ядра MySQL, причем каждая таблица может быть оптимизирована для различных характеристик производительности.
• Все типы таблиц в MySQL (кроме InnoDB) реализованы в виде файлов (по одной таблице в файле), что значительно облегчает создание резервных копий, перенос, удаление и даже создание символьных ссылок между базами данных и таблицами, даже если сервер находится в нерабочем состоянии.
• Наличие утилиты для восстановления и оптимизации таблиц MyISAM (наиболее распространенного типа таблиц в MySQL). Ее использование требуется только в случае физического повреждения файла данных (например, в результате аппаратного сбоя). Позволяет восстановить большую часть данных.
• Обновление (апгрейд) MySQL проходит совершенно ``безболезненно''. При модернизации MySQL нет нужды в копировании/восстановлении данных, что приходится делать при установке большинства обновлений PostgreSQL.

Недостатки MySQL по сравнению с PostgreSQL:

• Поддержка транзакций в MySQL пока что не настолько хорошо проверена, как в системе PostgreSQL.
• Так как MySQL основан на использовании потоков (threads), пока что еще не безошибочно работающих в некоторых ОС, для обеспечения стабильной работы приходится либо использовать один из откомпилированных пакетов, доступных по адресу http://www.mysql.com/downloads/, либо точно выполнять содержащиеся в section 2.3 Установка исходного дистрибутива MySQL инструкции.
• Блокировка таблиц, применяющаяся в нетранзакционных таблицах MyISAM, во многих случаях работает быстрее, нежели блокировки на уровне страниц, строк или контроль версий. Недостаток этого подхода в том, что если не учитывать механизм работы блокирования таблиц, один длительный запрос может надолго заблокировать таблицу. Обычно этого эффекта можно избежать, приняв соответствующие меры при разработке приложения. Если это не удастся, всегда можно изменить тип таблицы и сделать ее транзакционной. See section 5.3.2 Вопросы блокирования таблиц.
• При помощи UDF (user-defined functions, определяемые пользователем функции) возможности MySQL можно расширить и дополнить обычными SQL-функциями или их объединениями. Но это сделать не так просто, да и система не настолько гибка в этом отношении, как PostgreSQL. See section 9.2 Добавление новых функций в MySQL.
• В MySQL сложнее организовывались обновления, затрагивающие несколько таблиц сразу. Впрочем, это было исправлено в MySQL 4.0.2 реализацией многотабличного UPDATE и в MySQL 4.1 - с помощью подзапросов. В MySQL 4.0 можно одновременно удалять данные из нескольких таблиц. See section 6.4.6 Синтаксис оператора DELETE.

Ниже перечислены преимущества PostgreSQL по сравнению с MySQL на сегодняшний день.

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

Другие причины, по которым можно предпочесть PostgreSQL:

• В некоторых случаях PostgreSQL оказывается ближе к ANSI SQL.
• Работу PostgreSQL можно ускорить, выполняя код в виде хранимых процедур.
• При хранении географических данных R-деревья дают PostgreSQL преимущество перед MySQL (примечание: в MySQL версии 4.1 для таблиц MyISAM реализована поддержка R-деревьев).
• Оптимизатор PostgreSQL в некоторых случаях способен дать лучший в сравнении с существующим на сегодняшний день оптимизатором MySQL результат. Особенно это заметно при слиянии таблиц без соответствующих ключей или при слиянии с использованием разных ключей в сочетании с логическим оператором OR. Набор результатов тестов скорости MySQL, расположенный по адресу http://www.mysql.com/information/benchmarks.html покажет, каких конструкций следует избегать при работе с различными базами данных.
• Команда разработчиков PostgreSQL, пишущих код для сервера, больше.

Недостатки PostgreSQL по сравнению с MySQL:

• VACUUM затрудняет использование PostgreSQL в постоянно работающих системах.
• Наличие только транзакционных таблиц.
• Значительно более медленная работа команд INSERT, DELETE и UPDATE.

Полный список недостатков приведен в первой таблице настоящего раздела.

User Comments

Postgresql has 7.3 in beta testing, and we're
still comparing to 7.0.3? Come on, someone at
MySQL AB must have enough talent to get at least
7.2 up and running and do some comparisons to it,
and not a two year old code base. It makes us
look like cheerleaders, not engineers to compare
our database to a two year old version, especially
if our excuse is that we couldn't get vacuuming to
work reliably. I understand that all vacuum
issues were pretty much solved in the 7.2 release
from January 2002 or so.

Here are the points that I know are incorrect in
this page:

Vacuum no longer really affects performance, you
can run it during normal usage and it hardly
impacts performance. In some testing, I've run it
continuously while doing transactional work, and
the slow down was about 10%. That would hardly
qualify as "practically dead"

Postgresql comes with a complete regression test
package run by using "make test" which is quite
comprehensive.

What ODBC functions do we support that Postgresql
doesn't? I'm not really familiar with this part.

With 7.3 Postgresql's alter table will now have
drop column, so the argument about a more advanced
alter table may go away.

About table handlers, Postgresql does use one,
it's just that it's the only one it uses.

Postgresql autocompresses all text types (char,
varchar, text) so the argument for mysql's read
only compressed tables is weak, since with
postgresql you don't have to do anything to
compress text anyway.

The fact that Postgresql's full text search is
external actually reflects poorly on MySQL's lack
of easy extensibility. Postgresql now has three
different add on full text searches, two of which
are delivered as part of the contrib directory and
fairly easy to add.

Under Linux, threads and processes are pretty much
the same performance wise, so saying that being
multi-threaded makes a big difference on MySQL
should be limited to Solaris / Windows, where
threads are noticeably faster than processes.

Postgresql gets a fully functional priviledge
system for 7.3, which is in beta right now. So
that point may need more close examination.

Postgresql now has compression from client to
server in 7.3 as well.

All Postgresql tables are as well implemented as
files, but due to issues with >2 gig files on some
file systems auto splits them after they reach a
certain size. They still are capable of being
sym-linked elsewhere, just like with MySQL.

Postgresql has a similar program to mysql's isam
repair utility, it's just not very well known.

Most Postgresql upgrades can be accomplished in
place with the upgrade tool, but backups shold be
performed anyway just in case a bug corrupts your
data.

Add your own comment.