Comments 37
Скорость или потребление ресурсов могут и не быть критерием выбора.
И вот почему, по результатам нагрузочного тестирования:
я не понял какие движки в mysql тестировали
Версия MySQL наверное 8, какая минорная не скажу. А вдруг MySQL 5 ?? Проверить версию мне в голову как то не пришло, извините.
никогда не используйте сам не знаю что... ну вот на что Вы расчитывали выходя с такой статьёй в массы? :) может MariaDB стоило пробовать уже?
Сто прогонов с вставкой по 400 000 записей за прогон. Была использована только одна таблица - ADDR_OBJ - адресные объекта, это все компоненты адреса имеющие собственное имя, то есть это регионы, населённые пункты, улицы.
Длительность видно по всем картинкам, приблизительно это для PostgreSQL 1 час, для MySQL 3 часа.
У меня на рабочей станции десятилетней давности (W7x64, Core Duo какой-то, всего 4Гб RAM), когда я работал с ГАР, импорт ВСЕХ таблиц в БД MySQL v.5.7 занимал порядка 40 минут. Вы их там руками вставляли, что ли?
Тег php добавьте, а то я полез на гитхаб смотреть какой драйвер jdbc и какой пул коннектов использовались и не смог найти
Насчет IO это действительно так, из коробки оно во первых всё сразу напрямую пишет на диск, во вторых бинарные логи включены по-умолчанию. Я думаю из-за них у вас место и не вернулось.
Так что да, нужно готовить. Отчасти можно решить кэшем записи на уровне хоста виртуализации или на уровне RAID контроллера.
А 5% диска - это сколько в гигабайтах?
А 5% диска - это сколько в гигабайтах?
диск 100 гигов, 5% от 100 гигов это 5 гигов. Ответ 5 гб
А, не заметил в начале характеристики. В опросе не хватает варианта "пишу свою субд". В моей это заняло бы около 5 гб и не росло. Правда это за счёт дедупликации. Без неё было бы 15, но оно того стоит, учитывая остальные плюшки. Вообще 100 раз вставлять одни и те же (причём на половину мусорные) данные - довольно странный кейс.
Выглядит как неудачный однобокий тест с громким заголовком.
Не понятно, что конкретно отображено на графиках. Ну загрузка ЦП и памяти. И что? Вы уверены, что это не PHP? Может вы используете драйвер к MySQL с багом или конкретно используемая вами версия PDO работает хуже с MySQL, чем с Postgre. Слишком много неизвестных в вашем тесте.
Что конкретно уходит в СУБД?
Если я правильно увидел, у вас там транзакции используются. Они по-разному в этих СУБД работают.
P.S. И как верно тут отметили, у вас в MySQL может быть включен binary log. Он потребляет дополнительные ресурсы ЦП и занимает место на диске. Если мне память не изменеяет, то он не удаляется после дропа базы и, более того, если его неправильно настроить, он может писаться "тайно" - если процесс БД не убить, файл будет заблокирован и выглядеть пустым.
Очень странное сравнение. Основной сценарий использования БД - это чтение (с join, group by, и т.д.), а не запись. Читаем 20 секунд, пишем одну. Ускорение записи в 3 раза даст меньший выигрыш, чем ускорение чтения на 5%, а в некоторых сценариях будет гораздо выше 1 к 20, какой-нибудь новостной сайт где пишется 100 новостей в день и миллион просмотров.
И получается что БД где запись в три раза быстрее абсолютно проигрывает БД где чтение на каких-то 5% быстрее.
не подскажете, в 2024 актуальны эти статьи?
Актуальны
1 Дают представление как можно смотреть на выбор СУБД через призму практики. Кейс то в том что одна не маленькая компания сначала мигрирует с MySQL на PG в надежде на такие-то улучшения. А потом мигрирует обратно по таким-то проблемам с которыми они столкнулись.
2 Дают представление как они устроены внутри и какие +\- это дает.
3 В каких-то моментах возможны улучшения, но глобально ничего не поменялось.
Никогда не используйте то, чем не умеете пользоваться.
мы, в интернет магазине "Мамси", в 2014 г. пытались перейти с MySQL на PostgresSQL,
и не смогли т.к. тексты запросов у нас были неправильные,
а именно в секцию "GROUP BY" MySQL разрешает добавлять не все нужные поля,
а в PostgresSQL так нельзя (это правильнее, это стандарт)
В общем, PostgresSQL всегда был лучше :-)
MySQL разрешает так делать, только с отключенным ONLY_FULL_GROUP_BY, а по умолчанию он включен (по крайней мере в последних версиях).
а в PostgresSQL так нельзя (это правильнее, это стандарт)
Ну да... а функцию ANY_VALUE() они (и все остальные СУБД, стремящиеся соблюдать стандарты) так, для смеха придумали, да?
Разрешение добавлять в выходной набор поле, не входящее в выражение группировки, без использования ANY_VALUE(), которое имеется в MySQL - это самый что ни на есть синтаксический сахарок, и не более. И уж точно это не основание для того, чтобы считать, что MySQL хуже.
Попробуйте Oracle Database 23ai Free, правда, там ограничения:
2 CPUs for foreground processes
2GB of RAM (SGA and PGA combined)
12GB of user data on disk (irrespective of compression factor)
Хорошо, не будем.
Вы тоже, пожалуйста, в следующий раз не пишите такие статьи :)
Тестирование проводилось на настройках по умолчанию
Дальше, в принципе, можно и не читать.
А почему бы и нет. Вероятно собаку съевший на какой то одной, отдельно взятой базе может ее настроить так, что тест автора выполнится за пару минут. Но кмк среднестатистический прикладной программист нифига не понимает в настройке постгреса или майскула. Он просто ставит его из репы или образ из докерхаба и рад, что его не надо настраивать пол часа и оно работает. Проще перебрать пару баз и выбрать ту, что справляется лучше или удобнее. Проще, чем искать мануалы по тонкой настройке. "Ведь дефолтную настройку выполняли авторы, спецы, а кто я такой?" Это потом, сделав выбор, будет тюнить базу данных под свои юзкейсы. Так что имхо, поставить незнамо что это вполне жизненно.
Другое дело, что начальная загрузка в базу данных не самый типичный юзкейс и возможно автор не то тестировал, но кто знает?
Проще, чем искать мануалы по тонкой настройке. "Ведь дефолтную настройку выполняли авторы, спецы, а кто я такой?"
Дефолтный конфиг мускула(насчет постгри не помню, возможно тоже) рассчитан на то чтобы он стартанул, работал и не падал на условной малине с соответствующей нагрузкой и размером базы. С двух ног заливать туда 400гиговый дамп неизвестно чего - ну ССЗБ. Не нужно быть DBA и тонко его тюнить, но хотя бы getstarted то прочитать надо перед использованием, или калькулятором воспользоваться, благо тысячи их
Сходил на пару собесов и узнал, что в 2к24 до сих пор танцы с бубнами танцуют в mysql, чтобы колонки и индексы в прод базу добавить
Чтобы улучшить производительность MySQL и приблизиться к паритету с PostgreSQL, стоит обратить внимание на несколько ключевых настроек и оптимизаций, которые помогут MySQL работать более эффективно:
Настройка движка InnoDB: Убедитесь, что используется InnoDB, так как он лучше работает с транзакциями и индексами. Оптимизируйте следующие параметры:
- `innodb_buffer_pool_size`: Установите 60-80% от доступной оперативной памяти. Это увеличит кэширование данных и индексов, снижая количество операций с диском.
- `innodb_log_file_size`: Подберите оптимальный размер (например, 512 МБ или больше) для улучшения скорости записи.
- `innodb_flush_log_at_trx_commit=2`: Этот параметр уменьшит нагрузку на диск и повысит скорость записи.
Оптимизация индексов: Как и в PostgreSQL, для улучшения скорости запросов нужно пересмотреть и оптимизировать индексы для часто используемых полей. Избегайте чрезмерного количества индексов, так как они замедляют операции записи.
Настройка кеширования:
- `query_cache_size`: Это поможет кэшировать результаты часто повторяющихся запросов (но будьте внимательны, так как кэширование подходит не для всех типов приложений).
- `table_open_cache` и `table_definition_cache`: Увеличьте их значения, чтобы уменьшить задержки при открытии и закрытии таблиц.
Настройки для высокой нагрузки:
- `thread_cache_size`: Увеличение этого параметра позволяет MySQL быстрее обрабатывать новые подключения.
- `max_connections`: Проверьте и увеличьте, если требуется поддержка большого числа одновременных подключений.
Оптимизация диска и ввода/вывода:
- Используйте файловую систему с хорошей поддержкой MySQL (например, XFS или ext4) и убедитесь, что включена настройка `innodb_flush_method=O_DIRECT` для предотвращения двойного кеширования.
- Проверьте настройки `sync_binlog`, так как уменьшение частоты синхронизации бинарного лога может повысить производительность при снижении надежности.
Анализ и настройка параметров SQL: Используйте инструменты, такие как `EXPLAIN`, чтобы анализировать сложные запросы и избавляться от узких мест.
Если mysql то percona и то потом готовить. А потом ещё ненароком откроете для себя hugepages и много других интересных вещей.
криватифф гуано, аффтар мундиаль 🤣
Всегда выбираю MSSQL
MySQL , от 5% до 30% в конце теста и до 20% после TRUNCATE TABLE, то есть сами данные заняли 10%, а ещё 15% (20% в конце минус 5% в начале) не понятно чем забились. Кто знает ответ ? Пожалуйста, напишите в комментариях.
Бинлоги, очевидно же. Их тоже можно почистить, отдельным запросом.
Напишите пожалуйста как это сделать. Для меня это не очевидная вещь.
Вообще, поисковые системы вроде пока не запрещены на территории нашей страны (что удивительно!), но ладно.
Запрос выглядит как:
PURGE BINARY LOGS BEFORE '2024-11-17 03:00:00';После выполнения оно удалит старые файлы бинлогов, размеры у всех плавающие. Бинлоги в себе хранят все выполненные инсерты, апдейты, делиты. Подробнее про них можно почитать в доке мускуля: https://dev.mysql.com/doc/en/binary-log.html
Обычно бинлоги используют в связке с репликацией, но они включены по-умолчанию, потому даже если вы не настраивали репликацию, то с большой вероятностью они у вас включены. Можно проверить просто заглянув внутрь папки мускуля, файлы так и зовутся (binlog*):
# ls -lh /tmp/mysql/binlog*
-rw-r----- 1 109 115 100M Oct 18 00:00 /tmp/mysql/binlog.002972
-rw-r----- 1 109 115 101M Oct 18 20:51 /tmp/mysql/binlog.002973
-rw-r----- 1 109 115 19M Oct 19 00:00 /tmp/mysql/binlog.002974
-rw-r----- 1 109 115 101M Oct 19 20:46 /tmp/mysql/binlog.002975
...
-rw-r----- 1 109 115 101M Nov 16 21:45 /tmp/mysql/binlog.003027
-rw-r----- 1 109 115 15M Nov 17 00:00 /tmp/mysql/binlog.003028
-rw-r----- 1 109 115 17M Nov 17 02:59 /tmp/mysql/binlog.003029
-rw-r----- 1 109 115 928 Nov 17 00:00 /tmp/mysql/binlog.indexЭто размеры с не-самого активного сервера, если что. Соответственно, чем больше интенсивность операций - тем больше жрёт.
Никогда не используйте MySQL, всегда используйте PostgreSQL