PostgreSQL či MySQL: rýchlejší výsledok sa mení podľa typu dotazu

Pri jednoduchých transakciách môže byť rýchlejší MySQL, pri zložitejších dotazoch a analytike PostgreSQL. Porovnávacia štúdia namerala pri MySQL 8.0 až o 21 % vyššiu špičkovú priepustnosť v jednoduchom teste OLTP než pri PostgreSQL 16; v komplexnej záťaži TPC-C dosiahol PostgreSQL lepší výsledok. Obe zistenia platia pre testovanú zostavu a konkrétne pracovné záťaže.

Poradie sa môže zmeniť aj pri podobne pomenovanom teste. Meranie DoltHubu na notebooku s Windows nameralo pri výbere podľa kľúča medián latencie 0,09 ms pre PostgreSQL 16.1 a 0,12 ms pre MySQL 8.0.34. Ide o inú metriku, prostredie a konfiguráciu než v štúdii transakčnej priepustnosti. Pre vývojára z toho vyplýva priama odpoveď: vyberať podľa dotazov vlastnej aplikácie, nie podľa univerzálneho poradia databáz.

Matica záťaží: čo môže zmeniť poradie

Krátky dotaz podľa primárneho kľúča má iné nároky než spojenie viacerých tabuliek alebo súhrn nad veľkou časťou dát. Pri porovnávaní preto treba oddeliť druh operácie od jej frekvencie: aj pomalý analytický dotaz môže byť pre používateľov menej dôležitý než veľmi časté krátke čítanie.

• Jednoduché čítanie: Výber jedného riadka podľa kľúča je vhodný samostatný test. Rozdiel v čase databázového dotazu však môže byť pre celú požiadavku malý, ak väčšinu odozvy tvorí komunikácia po sieti alebo práca aplikácie.
• Zápisy: Vkladanie nových riadkov, aktualizácia indexovaného poľa a zmena dokumentu JSON sú odlišné operácie. Výsledok ovplyvní veľkosť dávky, počet indexov, súbeh klientov aj okamih potvrdenia transakcie. Jedno číslo za „výkon zápisu“ tieto rozdiely zakryje.
• Komplexné spojenia: Pri filtroch, spojeniach a agregáciách záleží na pláne vykonania a odhade počtu riadkov. Konkrétny dotaz môže zvýhodniť jednu databázu aj vtedy, keď iný dotaz s rovnakým počtom tabuliek zvýhodní druhú.
• Analytika: Prechod veľkej časti tabuľky a tvorba súhrnu zaťažujú pamäť, procesor a disk inak než krátke transakcie. Ak analytika beží popri zápisoch, dôležitá je aj odozva transakcií počas súbehu, nielen čas dokončenia súhrnu.
• JSON: Vyhľadanie známej hodnoty, filtrovanie podľa meniacich sa ciest a častá úprava časti dokumentu vyžadujú odlišné indexy a príkazy. Samotná podpora dátového typu preto neurčuje víťaza.

JSON: vyhľadávanie a aktualizácia sú rôzne úlohy

PostgreSQL ponúka pre jsonb porovnávacie operátory, operátory na prístup k prvkom dokumentu aj funkcie SQL/JSON. Dokumentácia funkcií JSON opisuje napríklad vyhľadávanie podľa cesty a prevod vybraných hodnôt na relačné riadky. Šírka funkcií je užitočná pri rôznorodých dotazoch, sama však nezaručuje krátku odozvu každého z nich.

Pri filtrovaní rozhoduje aj index. Opis indexovania jsonb rozlišuje triedy GIN jsonb_ops a jsonb_path_ops: druhá podporuje užší súbor operátorov, ale pri vhodnom vyhľadávaní môže vytvoriť menší a špecifickejší index. Ak aplikácia zisťuje samotnú existenciu kľúča, tento rozdiel je podstatnejší než všeobecné tvrdenie, že používa „index na JSON“.

MySQL má inú možnosť pri úprave uloženého dokumentu. Príručka MySQL 8.4 uvádza, že pri splnení podmienok môže aktualizovať časť hodnoty JSON na mieste namiesto zápisu celého dokumentu. Príkaz musí použiť JSON_SET(), JSON_REPLACE() alebo JSON_REMOVE() na ten istý stĺpec; zmeny nesmú pridávať nové prvky a väčšia náhradná hodnota potrebuje dostupné miesto. Priame priradenie celého dokumentu optimalizáciu nevyužije. Preto má zmysel merať príkazy UPDATE, ktoré aplikácia skutočne posiela.

Prečo cudzie benchmarky nestačí zoradiť podľa rýchlosti

Špičková priepustnosť udáva, koľko transakcií zostava dokončí pri danej záťaži. Medián latencie opisuje čas typickej operácie v inom rozdelení výsledkov. Porovnávanie týchto metrík bez počtu klientov a podoby transakcie môže vytvoriť zdanlivý spor tam, kde testy odpovedajú na rozdielne otázky.

Rovnako dôležitá je veľkosť dát voči pamäti. Dotaz nad údajmi, ktoré sa zmestia do vyrovnávacej pamäti, zaťažuje disk inak než ten istý dotaz nad väčším súborom. Rozdiel vytvoria aj indexy, aktualizované štatistiky, spôsob pripájania klientov, izolačná úroveň a nastavenia trvanlivosti. Pri zápisoch treba overiť, či obe zostavy potvrdzujú transakcie za porovnateľných podmienok.

Verzia databázy patrí k výsledku rovnako ako hardvér. Staršie meranie môže dobre ukázať postup testovania, ale jeho poradie nemožno bez ďalšieho preniesť na novšie vydania. Pri spojeniach navyše nestačí rovnaké SQL: plán vykonania môže spracovať odlišný počet riadkov, ak sa líšia štatistiky alebo indexy.

Malý reprodukovateľný test vlastnej schémy

Pre rozhodnutie o databáze stačí začať niekoľkými dotazmi, ktoré majú v aplikácii skutočný význam. Vzorka dát má zachovať približnú veľkosť tabuliek, rozloženie filtrovaných hodnôt a podiel často používaných záznamov. Na oboch systémoch treba pripraviť funkčne rovnocennú schému a overiť, že dotazy vracajú rovnaké výsledky.

1. Vyberte typické čítanie podľa kľúča, zápis, náročné spojenie, analytický súhrn a používaný dotaz nad JSON. Zaznamenajte, ako často sa každý z nich v aplikácii vykonáva.
2. Zapíšte verzie databáz, indexy, izolačnú úroveň, nastavenia potvrdenia transakcií, veľkosť dát a počet súbežných klientov. Pred meraním spustite na oboch zostavách rovnakú zahrievaciu záťaž.
3. Merajte priepustnosť aj rozdelenie latencie. Opakujte behy a pridajte zmiešanú záťaž, ak v prevádzke čítanie a zápis prebiehajú súčasne.
4. Pri výraznom rozdiele otvorte plán vykonania. Overte použitý index, odhad a skutočný počet spracovaných riadkov skôr, než výsledok pripíšete samotnej databáze.

Ak sú rozdiely pri dôležitých dotazoch malé alebo sa medzi behmi mení ich poradie, do výberu vstupujú aj náklady na zmenu: úprava SQL, zálohovanie, monitoring a skúsenosti tímu. Migrácia má presvedčivejší výkonový dôvod vtedy, keď sa výhoda opakuje práve pri záťaži, ktorá aplikáciu obmedzuje, a pretrvá aj po zohľadnení prevádzkových nákladov.

Prečítajte si aj:

• Claude Code či GitHub Copilot: víťaz sa mení podľa typu úlohy
• Finax či Portu: detský účet mení výsledok viac než značka
• Webflow či Wix: rýchlejší štart sa môže skončiť drahším prerábaním