Тестирование скорости работы MySQL и PostgreSQL
Единственная тестовая система с открытым кодом, способная тестировать скорость работы как MySQL Server, так и PostgreSQL (а также других СУБД), о существовании которой нам известно, - наша собственная разработка. Ее можно найти по адресу http://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 мы в связи с этим тестом ни в чем не обвиняем.
Упомянутый тест осуждался во многих сообщениях и телеконференциях, так что мы просто коротко перечислим его недостатки.
Тесты выполнялись дорогой коммерческой программой, что сделало задачу проверки их результатов невыполнимой для Open Source-компании, каковой мы являемся; мы даже не можем выяснить, как же на самом деле проводились эти тесты. Причем сама программа, даже не является специализированной утилитой для тестирования производительности - она представляет из себя универсальный инструмент для настройки и тестирования приложений. Называть ее "стандартным" тестом - это уж слишком большая натяжка.
Компания Great Bridge признала, что база данных PostgreSQL была оптимизирована (а перед проведением теста была запущена программа VACUUM) и специально настроена для проведения тестов, чего не делалось ни для одной другой СУБД, участвовавшей в тестировании. Они заявили буквально следующее: "Этот процесс оптимизирует индексы и высвобождает немного дискового пространства. Оптимизированные индексы в некоторой степени повышают производительность." Проведенные нами тесты недвусмысленно свидетельствуют о том, что разница в скорости выполнения большого количества выборок (SELECT"ов) из базы данных, прошедшей чистку VACUUM, и не прошедшей ее, может быть десятикратной.
Результаты тестов тоже вызывают сомнения. В тестовой документации AS3AP упоминается о том, что при тестировании выполняются "выборки, простые связи, проекции, аггрегация, обновления с одним набором значений для атрибута и массовые обновления".
PostgreSQL отлично выполняет операции SELECT и JOIN (особенно после VACUUM), но отнюдь не здорово справляется с INSERT или UPDATE. А результаты показывают, что выполнялись только операции SELECT (или операций обновления выполнялось очень мало). Это правдоподобно объясняет отличные результаты, показанные PostgreSQL в данном тесте. А причина, по которой MySQL показал неважные результаты, станет понятной несколько ниже.
Так называемый тест запускался с компьютера, работающего под управлением Windows и связывавшегося с Linux через ODBC, а такая конфигурация никакому нормальному пользователю СУБД, особенно при работе с многопользовательским приложением, даже в голову не придет. В этом случае тестируется не СУБД, а ODBC-драйвер и Windows-протокол, связывающие клиентов.
При связи базы с Oracle и MS-SQL (Great Bridge косвенно указала на примененные в тесте СУБД) использовался не соответствующий им протокол, а ODBC. Любой, кто когда-либо имел дело с Oracle, знает, что во всех настоящих приложениях используется не ODBC, а "родной" интерфейс. Проводить тесты через ODBC и утверждать, что они имеют какое-либо отношение к использованию СУБД в реальной работе, попросту нечестно. Нужно было провести два теста, с ODBC и без него, чтобы получить истинные факты (причем все СУБД перед проведением тестов должны были бы настраиваться специалистами).
Представители компании постоянно говорят о TPC-C тестах, но нигде не упоминают о том, что проведенный ими тест вовсе не относился к TPC-C, а проводить TPC-C они просто не имели права. TPC-C может проводиться только по правилам, утвержденным комитетом TPC Council (http://www.tpc.org/). Great Bridge в комитет не обращалась. Не сделав этого, она не только вступила в конфликт с торговой маркой TPC, но и дискредитировала свои тесты. Установленные комитетом TPC Council правила очень строги, чтобы никто не мог выдавать ложных результатов или делать недоказуемые заявления. Очевидно, у Great Bridge не было желания следовать этим правилам.
После проведения первого теста мы связались с Great Bridge и сообщили ее представителям о наиболее очевидных из допущенных при тестировании MySQL Server ошибок:
Использование отладочной версии нашего ODBC-драйвера
Запуск сервера под управлением ОС Linux, не оптимизированной для работы с потоками.
Использование старой версии MySQL, хотя уже существовала более современная
Отказ от запуска MySQL Server с соответствующими настройками для работы с большим количеством пользователей (по умолчанию послеустановки MySQL Server настраивается для минимального использования ресурсов)
Great Bridge провела новый тест, с нашим оптимизированным драйвером ODBC и лучшей настройкой MySQL Server, но отказалась применить обновленную библиотеку glibc или нашу стандартную бинарную поставку (ее используют 80% наших пользователей), которая была статически слинкована с конкретной glibc. Насколько нам известно, компания Great Bridge не сделала абсолютно ничего для правильной настройки других СУБД при тестировании. Впрочем, мы уверены, что в Oracle или Microsoft они за советом не обращались. ;)
Тестирование было оплачено Great Bridge, и эта компания решила опубликовать не все результаты, а только выборочно - те, что были ей выгодны.
Тим Пердью (Tim Perdue), преданный обожатель PostgreSQL и не слишком большой любитель MySQL, опубликовал свое сравнение на сайте PHPbuilder (http://www.phpbuilder.com/columns/tim20001112.php3).
Узнав об этом, мы связались с Тимом по телефону с тем, чтобы обсудить некоторые странности в полученных им результатах. Он, например, утверждал, что MySQL Server в его тестах с трудом справлялся с обслуживанием пяти пользователей, хотя нам были известны пользователи с примерно такими же, как у Тима, компьютерами, работающие с MySQL Server при 2000 активных соединениях, выдающих до 400 запросов в секунду (причем в данном случае производительность ограничивалась каналом связи с web, а не базой данных).
Похоже было, что Тим работал с ядром Linux, не умеющим нормально обрабатывать большое количество потоков, как, например, ядра до версии 2.4, у которых возникали серьезные проблемы с обработкой большого количества потоков на мультипроцессорных компьютерах. В настоящем руководстве мы описали решение этой проблемы, и Тим должен был об этом знать.
Существует еще одна возможная причина возникновения проблем: Тим мог воспользоваться старой библиотекой glibc или не загрузить откомпилированный исполняемый файл MySQL (слинкованный с исправленной библиотекой glibc) с нашего сайта, но скомпилировал его сам. В любом из этих случаев симптомы были бы именно такими, как описал Тим.
Мы спросили Тима, может ли он предоставить нам его данные с тем, чтобы мы могли повторить тест, а также попросили его проверить свою версию MySQL и сообщить нам. Пока что он этого не сделал.
Из за этого его тесту мы тоже не можем доверять. :(
Все течет, все изменяется, и старые тесты теряют актуальность. Теперь MySQL обзавелся парой новых обработчиков таблиц, которые обеспечивают совершенно разные характеристики в разрезе скорости/параллелизма. See section 7 Типы таблиц MySQL. Было бы интересно узнать, какие результаты показали бы вышеупомянутые тесты с разными типами транзакционных таблиц в MySQL. Конечно, в PostgreSQL с тех пор тоже появились новые возможности. Так как эти тесты недоступны общественности, выяснить, как СУБД показала бы себя в них сегодня, мы не можем.
Заключение:
Единственные существующие на сегодня тесты, позволяющие сравнить MySQL Server и PostgreSQL, которые любой может загрузить и запустить, - это тесты из комплекта MySQL. Мы, сотрудники MySQL AB, считаем, что Open Source-СУБД должны тестироваться при помощи Open Source-инструментов! Только так можно получить гарантии того, что никто не сможет провести невоспроизводимые тесты и на основе их результатов утверждать, что одна СУБД лучше другой. Не зная всех фактов, подтвердить или опровергнуть подобные утверждения просто невозможно.
Нам кажется странным, что невоспроизводимые тесты с участием PostgreSQL показывают преимущество этой системы, в то время как наши тесты, которые может повторить любой, четко доказывают обратное. Этим мы вовсе не хотим сказать, что PostgreSQL не годится для решения многих задач (еще как годится!) или что при определенных условиях эта система не обгонит MySQL Server. Но нам просто хотелось бы для разнообразия увидеть честный тест, в котором PostgreSQL покажет отличные результаты, - исключительно с целью поддержания товарищеской конкуренции!
Дополнительную информацию о нашей тестовой системе вы можете получить из раздела section 5.1.4 Набор тестов MySQL (The MySQL Benchmark Suite).
Мы занимаемся разработкой еще лучшего комплекса тестов, в состав которого будут включены многопользовательские тесты, а также более подробное описание того, что собственно делает каждый отдельный тест и как расширить комплекс.
1 2 3 4
8 8 8
| |
*
Обратная связь