PostgreSQL или MySQL: benchmark не може да избере вместо натоварването

По-подходящата база за конкретно приложение е тази, която изпълнява важните за него заявки и транзакции с приемлива латентност при очакваното натоварване. При избор между PostgreSQL и MySQL трябва да се сравнят и изискванията към репликацията, настройката и поддръжката. Една стойност за скорост не обхваща всичко това.

В сравнението на DoltHub PostgreSQL 15.5 постига по-ниска медианна латентност от MySQL 8.0.35 в повечето показани Sysbench сценарии: при oltp_point_select стойностите са 0,14 срещу 0,18 ms, но при index_join MySQL води с 1,37 срещу 1,96 ms и има малка преднина при select_random_ranges. Резултатът се сменя според заявката, а измерените стойности се отнасят до конкретните версии, конфигурация и тестове.

Какво показва Sysbench и къде свършва изводът

Публикуваният тест е полезен за сравнение на отделни видове заявки. Той използва стандартни настройки и данни, които се побират в паметта; сценариите се изпълняват поотделно, без конкурентни операции. Така се вижда разликата при дадена заявка в тази среда, но не и как системите ще се държат, когато приложението едновременно чете, записва и променя едни и същи данни.

Изборът на тест също влияе на резултата. Точково търсене по ключ натоварва базата различно от справка с няколко таблици, групиране и филтри; еднакъв среден резултат може да прикрива бавна операция, от която зависи важна функция. Затова публикуваните латентности са ориентир кои заявки да се разгледат по-внимателно, а не обща оценка за всяко приложение.

Разборът на MonPG посочва, че фабричните настройки, гаранциите за трайност на записа, управлението на връзките и продължителността могат да наклонят сравнението. Ако едната система е настроена внимателно, а другата е оставена с началните си настройки, разликата включва и ефекта от подготовката. Същото важи за транзакциите: ускорение чрез по-слаба гаранция за запис не е равностойна победа, когато приложението изисква промяната да оцелее при срив.

Матрица според работата на приложението

Най-полезната матрица започва от операциите, които определят времето за отговор и надеждността на приложението. Всяка група има собствена мярка за успех:

• Кратки OLTP заявки. При търсене по ключ и кратки транзакции сравнете действителната смес от четене и запис, включително заявките, които се изпълняват заедно. Ако текуща система вече покрива нужната латентност, преднина в изолирано четене сама по себе си не оправдава миграция.
• Сложни joins и справки. Значение имат размерът на таблиците, разпределението на стойностите, филтрите и наличните индекси. Проверете плановете на конкретните бавни заявки: предимството при един index_join сценарий не предсказва резултата при различно свързване, сортиране или групиране.
• JSON филтри. Сравнете търсенето по полетата, които приложението действително използва, заедно със записите, които поддържат индексите актуални. Наличието на JSON тип в двете системи не означава еднаква схема за индексиране или еднаква цена на обновяването.
• Четене от реплики. Отделете латентността на заявката от закъснението, с което промяната достига до репликата. За екран, който трябва веднага да покаже току-що записани данни, бързият отговор със старо съдържание не изпълнява изискването.
• Опит на екипа. Времето за настройка, диагностика, архивиране и възстановяване е част от цената на избора. Дори измерима преднина може да загуби стойност, ако екипът няма капацитет да поддържа конфигурацията, с която е постигната.

Тези критерии нямат еднаква тежест навсякъде. Приложение с чести кратки транзакции трябва да даде по-голяма тежест на тяхната латентност и поведението при конкуренция. При тежки справки решаващи може да се окажат плановете за няколко конкретни заявки, а при разпределено четене — допустимото закъснение на данните.

JSON: сравнявайте схемата и индексите

При PostgreSQL разликата между json и jsonb има значение за теста. Документацията за jsonb описва обработен формат, който позволява индексиране и избягва повторното解析иране на текста при четене, но изисква преобразуване при запис. Следователно тест само с четене може да пропусне важен разход за приложение, което често променя JSON стойности.

При MySQL ръководството за JSON уточнява, че JSON колоната не се индексира директно; индекс може да се създаде върху генерирана колона с извлечена стойност, а InnoDB поддържа и индекси с множество стойности за JSON масиви. Затова сравнимият тест трябва да използва индекси, съобразени с едни и същи реални филтри. Иначе разликата може да идва от подготвената схема, а не от избора на база.

Проверявайте и обновяванията на полетата, по които се търси. Индекс, който ускорява често четен филтър, трябва да се поддържа при промяна на данните. За приложение с много записи това може да промени баланса между бързото намиране на стойност и времето за завършване на транзакцията.

Репликацията добавя друга мярка за скорост

Ръководството за репликация на MySQL 8.4 описва асинхронна репликация по подразбиране: записите се изпращат към основния сървър, а четенията могат да се разпределят към реплики. Това увеличава възможностите за обслужване на четене, но репликата може още да не е приложила последната промяна. Времето за отговор и актуалността на върнатите данни трябва да се измерват отделно.

Сравнение между PostgreSQL и MySQL в такава архитектура трябва да отразява къде действително ще отиде всяка заявка. Четене от основния сървър и четене от реплика отговарят на различни изисквания след запис. При избор на топология имат значение също допустимото прекъсване при отказ и начинът, по който приложението продължава работа; таблица с латентности на единични заявки не съдържа тези характеристики.

Минимален възпроизводим тест със собствени заявки

За решение на екипа е достатъчен ограничен, но представителен набор от операции, изпълнен при ясно записани условия. Наборът трябва да обхваща най-честите заявки и онези, чието забавяне има най-голямо значение за приложението.

1. Групирайте реалните заявки по функция и честота: например търсене по ключ, транзакция със запис, тежка справка и JSON филтър, ако се използва. Запазете типичните параметри и дела на всяка група в трафика, без да включвате чувствителни данни в споделените тестови материали.
2. Подгответе данни със сходен размер и разпределение, нужните за всяка система индекси и еднакъв клас хардуер. Запишете версиите, настройките на паметта, гаранциите за запис и начина на управление на връзките, така че резултатът да има ясни условия.
3. Изпълнете една и съща смес от операции при очакваната едновременност. Следете медианата, бавния край на разпределението, пропускателната способност, грешките и използваните ресурси. Продължете достатъчно дълго, за да се проявят и фоновите операции, вместо да избирате само най-бързия кратък период.
4. Проверете плановете на бавните заявки, настройте всяка система с еднаква грижа и повторете измерването. Запазете данните, скриптовете, конфигурацията и причината за всяка промяна, за да може друг член на екипа да получи съпоставим резултат.

Решението следва операциите и гаранциите, от които приложението действително зависи. Ако и двете системи ги покриват с близки резултати, опитът на екипа и усилието за дългосрочна поддръжка стават разумните решаващи критерии.

Прочетете също:

• Google Workspace или Microsoft 365: миграцията може да изяде ценовата разлика
• DNS през HTTPS във Firefox: максималната защита може да счупи локални адреси
• Валидният JSON пак може да греши: проверете смисъла след схемата