Никогда не используйте MySQL, всегда используйте PostgreSQL12.11.2024 15:46

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

• 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 I/O Utilization

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

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

PostgreSQL I/O Utilization

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

Вывод

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

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

CPU

mysql cpu utilization

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

pg cpu utilization

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

RAM

mysql ram utilization

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

pg ram utilization

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

HDD (Storage)

mysql hdd utilization

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

pg hdd utilization

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 — адресные объекта, это все компоненты адреса имеющие собственное имя, то есть это регионы, населённые пункты, улицы.

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