PostgreSQL или MySQL: бржи benchmark не доноси одлуку без истог нивоа изолације

У објављеном поређењу са 17 сценарија PostgreSQL је био бољи у 14, али тај збир не одређује бржу базу за сваку апликацију. У мешовитом раду измерено је 23.441 упит у секунди (QPS) за PostgreSQL и 6.300 за MySQL; ти резултати су добијени при различитом задатом темпу. За избор су зато важни и исти захтев за изолацију трансакција, стварни упити, шема и латенција.

Изолација мења шта трансакција сме да види док други корисници уписују податке. InnoDB подразумевано користи Repeatable Read и подржава сва четири стандардна нивоа, док је за PostgreSQL подразумеван Read Committed. У поменутом тесту MySQL је намерно подешен на Read Committed. То чини упоредне бројеве кориснијим за тај режим, али апликација која остаје на подразумеваном InnoDB подешавању мора да процени и његово понашање и цену.

Шта показују читање, упис и мешовити рад

У тесту су мерени пропусност и p99 латенција: p99 је граница испод које је завршено 99 одсто измерених упита. Већи QPS описује колико је упита обрађено у јединици времена, док нижи p99 описује спорији део захтева. Резултате зато има смисла раздвојити по облику посла, а не сабрати победе у јединствену оцену базе.

• Читање по кључу: за корисника пронађеног по идентификатору PostgreSQL је постигао 55.200 QPS уз p99 од 5,446 ms, а MySQL 33.469 QPS уз 12,721 ms. Код поруџбине спојене са корисником MySQL је био испред: 29.223 према 28.194 QPS, уз p99 од 14,543 према 19,823 ms. Већ у групи читања резултат зависи од потребног спајања табела.
• Упис: при уметању једног корисника PostgreSQL је достигао 21.338 QPS и p99 од 4,009 ms, а MySQL 4.383 QPS и 42,729 ms. Код пакета од 1.000 ставки поруџбина MySQL је обрадио више пакета у секунди, 543 према 389, али је PostgreSQL имао нижи p99, 394,913 према 482,361 ms. То је пример различитог рангирања по пропусности и латенцији.
• Измена и брисање: при промени више колона корисника по идентификатору PostgreSQL је забележио 18.046 QPS и p99 од 4,704 ms, а MySQL 3.747 QPS и 39,774 ms. Брисање корисника по идентификатору завршило је са 18.285 према 5.596 QPS, уз p99 од 4,661 према 43,039 ms.
• Мешовити рад: читања и уписи били су равномерно заступљени: на свака три читања долазили су уметање, измена и брисање. При задатих 7.500 QPS PostgreSQL је стварно обрадио 7.413, а MySQL 6.300 QPS; њихови p99 били су 3,068 и 40,635 ms. При посебном пролазу од 25.000 задатих QPS PostgreSQL је обрадио 23.441 QPS, уз p99 од 4,634 ms.

Шема, кеш и темпо ограничавају поређење

Објављени тест покренут је на једном локалном рачунару, а обе базе су радиле у Docker контејнерима са ограничењем од осам процесорских језгара и 16 GB меморије по контејнеру. Користио је MySQL 9.5 и PostgreSQL 18.1. За сваку базу посебно су подешени кеш и меморија; пул веза имао је 128 конекција за MySQL и 64 за PostgreSQL, јер је већи пул у том окружењу побољшао резултате MySQL-а. То су резултати конкретних конфигурација, а не својства која се могу приписати само називу базе.

Модел података обухвата кориснике, поруџбине, артикле и ставке поруџбина, са јединственим вредностима за адресу е-поште и назив артикла, спољним кључевима и индексима за везе између табела. После почетних уписа преостали сценарији радили су над већ попуњеним табелама. Тај детаљ је битан: тражење корисника по јединственом кључу, спајање поруџбине са њеним ставкама и масовни упис не оптерећују исте делове система.

У мешовитом сценарију највећи приказани резултати настали су при различитој понуђеној брзини, па их не треба тумачити као контролисано поређење при истом захтеву. Постоји и пролаз у којем је за обе базе тражено 7.500 QPS: ту PostgreSQL и даље има вишу пропусност и нижи p99. Одвојени пролаз са већим захтевом показује колико је та PostgreSQL конфигурација обрадила када јој је понуђено више рада; није директан пар истоветно оптерећеном MySQL пролазу.

Изолација мења и исправност и цену трансакције

Код InnoDB-а обично читање у Repeatable Read трансакцији користи снимак успостављен првим таквим читањем. У Read Committed режиму свако обично читање добија нови снимак. За читања са закључавањем, измене и брисања разликују се и правила закључавања: јединствени услов над индексом и претрага распона могу обухватити различите записе и празнине између њих. Промена зато није само прекидач за брзину већ и избор видљивости и могућих конфликата.

PostgreSQL омогућава да се карактеристике задају по трансакцији. Према правилима за SET TRANSACTION, одложива трансакција која је истовремено Serializable и само за читање може сачекати погодан снимак, а потом радити без уобичајеног трошка провере серијализабилности. Тај режим је намењен дугим извештајима или резервним копијама; чекање на почетку такође улази у процену његове корисности.

Исти назив нивоа изолације је полазни услов поређења, али сам назив не гарантује идентично понашање свих упита у различитим системима. Посебно су важни вишеструка читања у једној трансакцији, упити са закључавањем и понављање трансакције после конфликта. Ако пословно правило тражи стабилан снимак током целе трансакције, резултат добијен на Read Committed не може сам да одреди избор под другачијим захтевом.

Шта пресуђује за сопствену апликацију

Из ових мерења следи предност PostgreSQL-а за више испитаних читања по кључу, уписа и мешовити сценарио, али и конкретан изузетак у читању спојених табела. За стварни избор важнији је скуп упита који апликација најчешће извршава: њихов однос читања и уписа, индекси, величина података, трајање трансакција и вршни број истовремених захтева. Синтетичка мешавина са равномерним читањем и уписом служи као оријентир само ако је слична стварном саобраћају.

Поновљено мерење има смисла са сопственом шемом и истим понуђеним темпом за обе базе, уз ниво изолације који апликација заиста може да користи. Одлука се затим заснива на пропусности коју систем постиже док p99 остаје у прихватљивим границама за корисничке захтеве. Ако се за MySQL планира подразумевани Repeatable Read, треба измерити управо њега; објављени QPS за MySQL потиче из Read Committed конфигурације.

Прочитајте и:

• Ollama или LM Studio: бржи одговор није и већа пропусност