Единственная тестовая система с открытым кодом, способная тестировать скорость работы как MySQL Server, так и PostgreSQL (а также других СУБД), о существовании которой нам известно, - наша собственная разработка. Ее можно найти по адресу https://www.mysql.com/information/benchmarks.html.

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

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

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

При тестировании PostgreSQL в режиме --fast мы запускаем VACUUM после каждой операции UPDATE и DROP TABLE, чтобы обеспечить отличное состояние базы для последующих операторов SELECT. Время, уходящее на работу VACUUM, измеряется отдельно.

Однако при тестировании PostgreSQL 7.1.1 мы не смогли запустить программу в режиме --fast, так как во время теста INSERT, postmaster (демон PostgreSQL) дал сбой и база данных была повреждена настолько, что перезапустить демон не удалось. Когда это случилось дважды, мы решили отложить тестирование в режиме --fast до выхода следующей версии PostgreSQL. Подробную информацию о компьютере, на котором выполнялись тесты, вы найдете на странице тестов.

Перед тем как переходить к описанию других известных нам тестов, мы дадим побольше информации о таких тестах вообще.

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

Это то же самое, если бы мы решили сравнить скорость работы MySQL Server и PostgreSQL просто сравнив общие результаты тестов MySQL, приведенных на нашей странице. По таким результатам MySQL Server оказался бы более чем в 40 раз быстрее PostgreSQL, а это, конечно, неверно. Можно было бы подлить масла в огонь, избрав для тестирования PostgreSQL тесты, на которые эта система тратит больше всего времени, - и утверждать что MySQL Server более чем в 2000 раз быстрее PostgreSQL.

Дело тут в том, что MySQL оптимизирует многое из того, чего не оптимизирует PostgreSQL. И наоборот. SQL-оптимизатор вообще очень сложная штука, и можно потратить годы исключительно на его улучшение.

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

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

Один из этих тестов был заказан компанией Great Bridge, которая в течение 16 месяцев пыталась построить бизнес на основе PostgreSQL, но в конце концов прекратила свою деятельность. Вероятно, это худший из когда-либо проводившихся кем-либо тестов. Он не только принимает во внимание лишь те области, в которых PostgreSQL оказывается ``на коне'', но и ставит абсолютно все остальные СУБД в заведомо проигрышное положение.

Примечание: Нам стало известно о том, что даже некоторым ключевым разработчикам PostgreSQL отнюдь не понравилось то, как фирма Great Bridge проводила свое тестирование, так что команду разработчиков PostgreSQL мы в связи с этим тестом ни в чем не обвиняем.

Упомянутый тест осуждался во многих сообщениях и телеконференциях, так что мы просто коротко перечислим его недостатки.

Тим Пердью (Tim Perdue), преданный обожатель PostgreSQL и не слишком большой любитель MySQL, опубликовал свое сравнение на сайте PHPbuilder (https://www.phpbuilder.com/columns/tim20001112.php3).

Узнав об этом, мы связались с Тимом по телефону с тем, чтобы обсудить некоторые странности в полученных им результатах. Он, например, утверждал, что MySQL Server в его тестах с трудом справлялся с обслуживанием пяти пользователей, хотя нам были известны пользователи с примерно такими же, как у Тима, компьютерами, работающие с MySQL Server при 2000 активных соединениях, выдающих до 400 запросов в секунду (причем в данном случае производительность ограничивалась каналом связи с web, а не базой данных).

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

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

Мы спросили Тима, может ли он предоставить нам его данные с тем, чтобы мы могли повторить тест, а также попросили его проверить свою версию MySQL и сообщить нам. Пока что он этого не сделал.

Из за этого его тесту мы тоже не можем доверять. :(

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

Заключение:

Единственные существующие на сегодня тесты, позволяющие сравнить MySQL Server и PostgreSQL, которые любой может загрузить и запустить, - это тесты из комплекта MySQL. Мы, сотрудники MySQL AB, считаем, что Open Source-СУБД должны тестироваться при помощи Open Source-инструментов! Только так можно получить гарантии того, что никто не сможет провести невоспроизводимые тесты и на основе их результатов утверждать, что одна СУБД лучше другой. Не зная всех фактов, подтвердить или опровергнуть подобные утверждения просто невозможно.

Нам кажется странным, что невоспроизводимые тесты с участием PostgreSQL показывают преимущество этой системы, в то время как наши тесты, которые может повторить любой, четко доказывают обратное. Этим мы вовсе не хотим сказать, что PostgreSQL не годится для решения многих задач (еще как годится!) или что при определенных условиях эта система не обгонит MySQL Server. Но нам просто хотелось бы для разнообразия увидеть честный тест, в котором PostgreSQL покажет отличные результаты, - исключительно с целью поддержания товарищеской конкуренции!

Дополнительную информацию о нашей тестовой системе вы можете получить из раздела Раздел 5.1.4, «Набор тестов MySQL (The MySQL Benchmark Suite)».

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