PostgreSQL ці MySQL: адзін бенчмарк не выбірае базу на гады

PostgreSQL і MySQL варта выбіраць паводле нагрузкі будучага сэрвісу, патрабаванняў да JSON і рэплікацыі, а таксама досведу каманды. Калі пераважае прадказальны CRUD і каманда ўпэўнена падтрымлівае MySQL, гэта рацыянальны выбар. Калі праект патрабуе разнастайных запытаў да JSON, складаных злучэнняў табліц і справаздач, магчымасці PostgreSQL заслугоўваюць асаблівай увагі. Перавага ў адным плацежным тэсце сама па сабе не вызначае вынік для іншага сэрвісу.

Параўнанне мае сэнс, калі яно паўтарае вашы аперацыі: якія радкі чытаюцца, што абнаўляецца ў транзакцыі, як часта запыты выконваюцца адначасова і якія адказы патрэбныя прыкладанню. Каталог тавараў, сістэма пераводаў і справаздачны сэрвіс ствараюць розную нагрузку нават пры аднолькавым аб’ёме даных. Таму вынік бенчмарка трэба суаднесці з яго схемай, наладамі і спосабам вымярэння, перш чым рабіць выснову для свайго праекта.

Спачатку — запыты і схема

Для простага CRUD істотна, ці знаходзіць запыт патрэбныя радкі праз індэкс і ці не канкуруюць частыя абнаўленні за тыя самыя запісы. Умоўны сэрвіс, які пераважна чытае аб’ект па ідэнтыфікатары і зрэдку мяняе яго стан, мала што даведаецца пра сябе з тэсту складанага пераводу. Тут больш карысці дасць ацэнка рэальнай схемы, тыповых фільтраў і колькасці адначасовых злучэнняў, чым агульны рэйтынг СКБД.

Пры складаных JOIN і агрэгацыі важны ўжо не адзін хуткі SELECT, а яго праца побач з транзакцыйным запісам. Справаздача можа чытаць вялікую частку табліцы, пакуль прыкладанне працягвае абслугоўваць карыстальнікаў; індэкс, які паскарае чытанне, таксама трэба падтрымліваць пры змене радкоў. Такі профіль патрабуе ацэнкі планаў запытаў, часу адказу і кошту індэксаў на даных, падобных да будучых вытворчых.

Суадносіны чытання і запісу таксама змяняюць вынік. Тэст хуткага чытання па ключы не паказвае, як база павядзе сябе пры канкурэнтным абнаўленні балансаў, а тэст пераводаў не адказвае, колькі будуць каштаваць складаныя справаздачы. Гэта розныя пытанні да адной схемы, і ніводнае з іх не замяняе астатнія.

Што сапраўды вымераў Reserva

У плацежным тэсце Reserva ад SQLpipe аўтар ацаніў прадукцыйнасць PostgreSQL 17.0 на 474% вышэй за MySQL 9.1.0; кожны перавод закранаў шэсць табліц і патрабаваў чатырох зваротаў да базы. Сцэнар паслядоўна правяраў удзельнікаў плацяжу, картку і рахунак, пасля чаго змяняў балансы і запісваў перавод. Нагрузка ўключала і выдаленне даных.

Абедзве СКБД выконвалі адну версію Reserva, але выкарыстоўвалі розныя памеры буфераў, падабраныя аўтарам для адпаведных сістэм. На хуткасць уплывала і сетка: у апісанні тэсту гаворыцца, што змена спосабу падключэння прыкметна змяніла колькасць апрацаваных пераводаў. Вымераная перавага адносіцца да гэтай сукупнасці праграмы, схемы, абсталявання і налад.

Пры пераносе выніку асабліва важна супаставіць транзакцыі. Калі ў вашым сэрвісе няма праверкі некалькіх удзельнікаў, адначасовай змены балансаў і запісу плацяжу, доля часу на асобныя запыты і сеткавыя звароты будзе іншай. Тое ж датычыцца колькасці адначасовых аперацый, памеру табліц і частаты канфліктаў пры запісе.

Для ўласнага параўнання дастаткова некалькіх маршрутаў, якія сапраўды будуць у прыкладанні: чытання па ключы, характэрнай транзакцыі, складанага запыту і пошуку ў JSON, калі ён патрэбны. Індэксы і патрабаванні да пацвярджэння запісу павінны адпавядаць тым, з якімі сістэма пойдзе ў эксплуатацыю. Інакш вымярэнне пакажа перавагу адной канфігурацыі, але не дапаможа выбраць базу для вашага рэжыму працы.

JSON: спосаб пошуку важнейшы за назву тыпу

Дакументацыя PostgreSQL 18 пра JSON адрознівае тыпы json і jsonb: першы захоўвае ўваходны тэкст, а другі — разабранае бінарнае прадстаўленне і падтрымлівае індэксы GIN. json захоўвае парадак ключоў і прабелы; jsonb гэтых асаблівасцяў тэксту не захоўвае. Для прыкладання, якое часта шукае дакументы па ключах або значэннях, істотная магчымасць індэксаваць адпаведныя аператары, а не толькі захоўваць дакумент цалкам.

Дакументацыя MySQL 9.7 пра JSON апісвае натыўны тып з аўтаматычнай праверкай карэктнасці і ўнутраным фарматам, які дае доступ да элементаў без паўторнага разбору тэксту. Сам слупок JSON непасрэдна не індэксуецца: для скалярнага значэння можна стварыць індэкс на вытворным слупку. InnoDB таксама падтрымлівае шматзначныя індэксы для масіваў JSON.

Адрозненне праяўляецца ў канкрэтных умовах пошуку. Калі запыты звяртаюцца да розных укладзеных ключоў, варта паглядзець, якія з іх паскарае абраны GIN-індэкс у PostgreSQL і якіх індэксаў запатрабуе схема MySQL. Калі праграма стабільна фільтруе па некалькіх вядомых палях, іх можна вынесці ў рэляцыйныя слупкі; гэта зробіць схему і прызначэнне індэксаў больш выразнымі ў абедзвюх сістэмах.

JSON таксама ўплывае на запіс. Вялікі дакумент, часткі якога часта мяняюцца незалежна, можа ствараць лішнюю працу і канкурэнцыю за радок; PostgreSQL асобна звяртае ўвагу на блакаванне ўсяго радка пры абнаўленні такога дакумента. MySQL апісвае частковае абнаўленне JSON пры пэўных формах запыту, але гэта не адмяняе патрэбы ацаніць структуру даных і частату змен.

Рэплікацыя: што азначае пацверджаны запіс

Дакументацыя PostgreSQL пра standby паказвае, што патокавая рэплікацыя па змаўчанні асінхронная: пасля пацвярджэння транзакцыі асноўны вузел можа выйсці з ладу раней, чым змены трапяць на рэпліку. Пры сінхроннай рэплікацыі транзакцыя чакае адказу standby, што павялічвае час запісу. Асобны рэжым чакання прымянення змен дазваляе звязаць пацвярджэнне з іх бачнасцю для чытання на рэпліцы.

Дакументацыя MySQL пра рэплікацыю таксама называе асінхронны рэжым стандартным. У паўсінхронным рэжыме асноўны сервер чакае, пакуль рэпліка пацвердзіць атрыманне і запіс падзей транзакцыі. Такое пацверджанне само па сабе яшчэ не азначае, што рэпліка прымяніла змены і верне іх у наступным запыце чытання.

Для сэрвісу гэта пытанне дапушчальнай страты даных і чакання карыстальніка. Калі прыкладанне чытае з рэплікі адразу пасля запісу, яму трэба ўлічваць адставанне; калі чакае пацверджання рэплікі перад адказам, расце затрымка транзакцыі. Камандзе давядзецца назіраць за адставаннем, аднаўляць вузлы пасля перапынкаў і разумець, што адбудзецца пры адмове асноўнага сервера.

Кошт падтрымкі і канчатковы выбар

Калі абедзве базы выконваюць патрабаванні па запытах і надзейнасці, досвед каманды становіцца тэхнічным аргументам. Знаёмыя інструменты рэзервовага капіявання, назірання, абнаўлення версій і разбору павольных запытаў скарачаюць час падтрымкі. Новая для каманды СКБД можа даць патрэбную магчымасць, але яе асваенне таксама трэба ўлічыць у кошце рашэння.

Пры прадказальным CRUD і моцнай практыцы працы з MySQL няма патрэбы мяняць выбар толькі праз чужы плацежны вынік. Пры разнастайным пошуку ў jsonb, складаных запытах і патрабаваннях да паводзін рэплікі PostgreSQL можа быць больш дарэчным кандыдатам. Рашэнне на працяглы тэрмін трымаецца на тым, ці адпавядаюць магчымасці СКБД рэальным аперацыям сэрвісу і ці здольная каманда ўпэўнена яе падтрымліваць.

Чытайце таксама:

• Ацэнка стартапа без выручкі: адзін метад памыляецца на мільёны