Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему: по результатам нагрузочного тестирования

• PostgreSQL в два раза меньше потребляет ресурса CPU,

• PostgreSQL в два раза меньше потребляет ресурса RAM,

• PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage),

• PostgreSQL в три раза быстрее выполняет запросы.

• PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Тестирование проводилось на настройках по умолчанию, ни какого тюнинга СУБД не было, была использована виртуалка СберКлауда (OS Ubuntu 22), 4 CPU, 6 Gb RAM, 100 GB SSD.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

Тут я хочу передать привет Битриксу, который по умолчанию идёт на MySQL, но если заморочиться, то можно использовать PostgreSQL, используйте PostgreSQL, не пожалеете.

Подробности тестирования читайте ниже, будут картинки.

Картинки

Сначала картинки.

Первые две картинки наверное сразу объяснят в чём проблема у MySQL и какой проблемы нет у PostgreSQL. Проблема эта называется эффективность использования ввода вывода.

Как видим MySQL использует ресурс пропускной способности ввода/вывода на 100%, наверное это не очень хорошо, даже наверное MySQL упирается в потолок и ему не хватает скорости, для MySQL нужен диск побыстрей.

Теперь посмотрим на PostgreSQL.

Использование ввода/вывода растёт от 15% до 20%. Для PostgreSQL можно использовать более медленные диски.

Вывод

Наверное именно поэтому PostgreSQL быстрее отработал тестовую программу, потому что операции ввода/вывода занимали в разы меньше времени. Все остальные показатели это производные от этой особенности в работе PostgreSQL.

Посмотрим другие картинки.

CPU

MySQL в среднем 45%, значительная доля это ожидание ввода/вывода.

PostgreSQL в среднем 25%, ожидание ввода/вывода занимает не значительную долю.

RAM

MySQL на всём протяжении теста около 1 гигабайта.

PostgreSQL в два раза меньше — 512 мегабайт.

HDD (Storage)

MySQL , от 5% до 30% в конце теста и до 20% после TRUNCATE TABLE, то есть сами данные заняли 10%, а ещё 15% (20% в конце минус 5% в начале) не понятно чем забились. Кто знает ответ ? Пожалуйста, напишите в комментариях.

PostgreSQL, от 4% до 19%, и после TRUNCATE TABLE осталось 5%, не пойми что заняло 1%, сами данные и индекс 15%, у MySQL это было 10%, возможно что MySQL не удалил индекс, а PostgreSQL индекс удалил вместе с таблицей, поэтому PostgreSQL освободил на 5% больше места.

Длительность выполнения тестового сценария

Длительность видно по всем картинкам, приблизительно это для PostgreSQL 1 час, для MySQL 3 часа.

Разницы в ТРИ раза !

При этом в среднем один прогон для

• PostgreSQL в начале один прогон был 31 секунду, в конце 35,

• Для MySQL время возрастало от 48 секунд и по нарастающей до 212.

PostgreSQL время вставки выросло не значительно, при том что был создан индекс по колонкам REGION и ID и поскольку прогоны повторялись, то 99 раз надо было вставлять одно и то же сочетание REGION и ID в ранее добавленные позиции индекса. То есть индекс всё время пересчитывался, и это мало сказалось на времени выполнения вставки каждой новой записи (+13%).

По MySQL рост на 341%, от 100% (48 секунд) до 441% (212)

Тестовый сценарий

В качестве нагрузки для СУБД был выбран импорт базы ФИАС в формате ГАР (XML файлы).

Сто прогонов с вставкой по 400 000 записей за прогон. Была использована только одна таблица — ADDR_OBJ — адресные объекта, это все компоненты адреса имеющие собственное имя, то есть это регионы, населённые пункты, улицы.

Пример записи:

    <OBJECT ID="765" OBJECTID="733" OBJECTGUID="88582cfc-5bc1-4ac5-93f8-ad4c7cb84334" CHANGEID="1883" NAME="Ветеранов"             TYPENAME="ул" LEVEL="8" OPERTYPEID="1" PREVID="0" NEXTID="0" UPDATEDATE="2014-01-05" STARTDATE="1900-01-01"             ENDDATE="2079-06-06" ISACTUAL="1" ISACTIVE="1"/>

Метрики измеряли с помощью prom/node-exporter:latest.

Метрики собирались с помощью prom/prometheus:latest с разрешением 5 секунд

Метрики рисовались с помощью grafana/grafana-enterprise

Скрипт теста был написан на PHP (php8)

PostgreSQL был установлен с помощью команды

apt install postgresql postgresql-contrib

Версия 16 точно, возможно 17.

MySQL был установлен с помощью команды

apt install mysql-server

Версия MySQL наверное 8, какая минорная не скажу. А вдруг MySQL 5 ?? Проверить версию мне в голову как то не пришло, извините.

Ещё диска не хватило и пришлось его расширять, был на 10 забиля после 50-ти прогонов, увеличил до 100. Как увеличивал, добавлю в статью позже. Это полезная инструкция.

Disclaimer

Может быть если бы тест был про вставку в несколько таблиц и и не только вставку, но и выборки данных и обновление данных и происходило это всё более хаотично, то результаты не были бы настолько шокирующими. Возможно 🙂

Кто то может быть может дать ссылки на адекватные бенчмарки, не такие как это однобокое нечто ?

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

PS

Код тестового стенда можно посмотреть на GitHub

Если хотите повторить мои опыты, то пишите в мессенджеры (есть в профиле), подскажу как настроить конфиги, а главное подскажу где (в исходниках) лежит скрипт развёртывания базы данных (таблицы и схемы), и где взять базу ФИАС, это тоже важно 🙂