PostgreSQL или MySQL: один тест не должен выбирать базу за проект

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

Сторонний тест помогает понять, какие условия способны изменить результат. Его цифру можно использовать как ориентир для похожей задачи, если известны состав запросов, настройки серверов и способ измерения. Решение для собственного приложения требует воспроизводимого прогона, в котором вместе с числом завершённых операций видны задержка и ошибки.

Что именно измерял платёжный тест

В испытании SQLpipe автор оценил PostgreSQL 17.0 как более быстрый на 474% по сравнению с MySQL 9.1.0 при обработке переводов в Reserva: каждый перевод затрагивал шесть таблиц и требовал четырёх обращений к базе, а прогон шёл два часа при 64 одновременных запросах. Обе системы обрабатывали одинаковый сценарий на одном выделенном для базы мини-ПК; в нагрузку входило и удаление записей. Измерялось количество выполненных переводов, а не скорость произвольного SQL-запроса.

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

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

Какая нагрузка отвечает на вопрос проекта

Руководство MySQL по измерению производительности различает проверку отдельной операции на спокойной системе и длительное испытание всей рабочей нагрузки. Для архитектурного выбора важен второй вариант: изолированный быстрый запрос не показывает, что произойдёт, когда приложение одновременно читает, обновляет и добавляет данные. Руководство также предупреждает, что результат может измениться в другой среде.

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

Если приложение ещё не работает, доли операций остаются предположением. Их полезно оформить как отдельные варианты: обычную работу, пик записи и поток с преобладанием чтения. Так станет видно, сохраняется ли преимущество одной СУБД при изменении профиля. Сводить результаты этих вариантов к одной средней скорости опасно: она может скрыть задержку именно той операции, от которой зависит пользовательский опыт.

Как сделать условия сопоставимыми

Обеим базам нужны одинаковые логические данные, сопоставимые индексы и один результат прикладной операции. Зафиксируйте объём и распределение записей, число активных клиентов, длительность прогрева и измерения, место запуска генератора нагрузки, тип хранилища и сетевой путь. Если одна сторона пользуется пулом соединений, а другая создаёт соединение заново для каждого обращения, итог будет характеризовать также различие клиентских схем.

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

Эквивалентность сценария определяется прикладным действием, а не буквальным совпадением SQL. Синтаксис и планы выполнения могут различаться, но операция должна менять или возвращать те же данные с теми же требованиями к целостности. После прогона проверьте конечное состояние базы и число ошибок: высокий счётчик обращений бесполезен, если часть переводов не завершилась или данные оказались неверными.

Как повторить сравнение через pgbench и sysbench

Документация pgbench описывает пользовательский сценарий через параметр -f, число параллельных клиентов через -c и длительность испытания через -T; инструмент выводит среднее число завершённых сценариев в секунду и задержку. Встроенный сценарий pgbench основан на собственной модели обновления счетов. Для проекта нужен файл с его операциями и фактическими границами транзакций, иначе измеренная скорость ответит на вопрос о встроенной модели.

Для MySQL ту же прикладную последовательность можно задать пользовательским сценарием на Lua: руководство sysbench описывает собственные сценарии, рабочие потоки, ограничение времени, прогрев и процентили задержки. Встроенные задания двух генераторов различаются, поэтому сопоставлять их готовые показатели напрямую нельзя. Сверять следует завершённые прикладные операции, фактическую параллельность, частоту подачи нагрузки и интервал измерения.

1. Подготовьте одинаковый по смыслу набор данных и проверьте индексы и результаты основных операций.
2. Запишите сценарии для обеих баз и убедитесь, что каждый завершённый запуск даёт одинаковое прикладное изменение.
3. Прогрейте системы, проведите повторные прогоны при согласованных длительности и уровнях параллелизма.
4. Сохраните команды, сценарии, конфигурации, характеристики машин и журналы задержек и ошибок.

Нужно заранее решить, что означает одинаковая нагрузка. При запуске на максимальной скорости более медленная система получает меньше новых операций, поскольку клиенты дольше ждут ответа. Если важна задержка при ожидаемом потоке пользователей, задайте одинаковую целевую частоту запросов и следите за очередью; если нужен предел пропускной способности, увеличивайте параллельность и фиксируйте точку, после которой задержка быстро растёт. Это разные вопросы, и их результаты нельзя смешивать.

По каким результатам выбирать

Главный показатель — число успешно завершённых прикладных операций при приемлемой для проекта задержке. Рядом нужны распределение времени ответа, ошибки и уровень параллелизма. Среднее время может выглядеть спокойным, когда небольшая часть запросов уже отвечает слишком долго; высокий процентиль показывает эту часть нагрузки. Сравнивайте такие значения при одной и той же интенсивности потока.

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

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

Читайте также:

• 10 сервисов аналитики Instagram: один инструмент не закроет все задачи
• Виды сайтов: почему лендинг и WordPress нельзя ставить в один ряд
• Мониторинг цен конкурентов: один ценник больше не даёт верного сравнения