PostgreSQL vai MySQL? Työkuorma ratkaisee benchmarkin

PostgreSQLin ja MySQL:n välillä ei ole yleispätevää nopeusvoittajaa. Valitse tietokanta sen perusteella, kumpi toteuttaa sovelluksesi tarvitsemat ominaisuudet ja pitää tärkeimpien kyselyiden sekä kirjoittavien tapahtumien vasteajat hyväksyttävinä omalla aineistollasi. Yksi benchmarkin kokonaistulos ei kerro, miten järjestelmä selviytyy juuri näistä tehtävistä.

Aloita tunnistamalla kuormat, joita sovellus todella tuottaa: pääavaimella tehtävät haut, suodatetut listaukset, samanaikaiset muutokset, raportit ja JSON-ehtoihin perustuvat kyselyt. Jos lähes kaikki käyttäjäpyynnöt ovat pistehakuja, raporttikyselyn voitolla on vähän painoa. Jos taas raportti pysäyttää kriittisen työnkulun, keskimääräinen tapahtumamäärä sekunnissa voi peittää olennaisen vasteaikaongelman.

Miksi yksi kokonaistulos johtaa harhaan?

ComputingForGeeksin Rocky Linux -vertailussa PostgreSQL 17.9 saavutti MySQL 8.4.8:aa suuremman läpimenon yhdistetyssä luku- ja kirjoituskuormassa (2 886 vastaan 436 tapahtumaa sekunnissa), pelkässä lukukuormassa (5 628 vastaan 5 400) ja INSERT-kuormassa (7 255 vastaan 2 206); kokeet ajettiin maaliskuussa 2026 samalla neljän virtuaalisen suorittimen ja kahdeksan gigatavun virtuaalikoneella käyttäen sysbench 1.0.20:tä. Tulokset kuvaavat sen aineistoa, asetuksia ja tapahtumien rakennetta, eivät kaikkien sovellusten nopeusjärjestystä.

Yhdistetty kuorma antaa eniten painoa niille operaatioille, joita sen skriptissä on eniten. Siksi sen tulosta ei voi soveltaa suoraan sovellukseen, jonka kyselyjakauma poikkeaa skriptistä. Lisäksi tapahtumamäärä sekunnissa kertoo vähän käyttäjän kokemuksesta, jos osa pyynnöistä odottaa pitkään lukkoa tai levyltä luettavaa dataa. Työkuormittain erotellut vasteajat, hitaimpien pyyntöjen jakauma ja virheet kertovat valinnasta enemmän.

Pistehaku, aluehaku ja kirjoitus kuormittavat eri tavoin

Small Datumin suoritinpainotteisessa sysbench-sarjassa PostgreSQL johti pistehauissa ja kirjoituksissa, kun taas MySQL oli nopeampi aluehauissa myös aggregoinnin kanssa; sarja käytti välimuistiin mahtuvaa aineistoa, 48-ytimistä palvelinta ja 40 samanaikaista asiakasta, ja mukana olivat muun muassa PostgreSQL 17.8 ja MySQL 8.4.7. Sarjan tekijä huomautti myös, etteivät uudempien versioiden merkistöasetukset olleet täysin yhtenevät. Sen aluehaut mittaavat eri tehtävää kuin Rocky Linux -vertailun pelkkä luku-OLTP, joten tulokset eivät muodosta samaa mittausta eri laitteilla.

Omassa sovelluksessa pääavaimella tehty haku ja suodatettu, järjestetty listaus kannattaa erottaa toisistaan. Ensimmäinen voi löytää yksittäisen rivin, kun taas jälkimmäisen kustannus riippuu palautettavien rivien määrästä, indeksin rakenteesta ja siitä, joutuuko tietokanta lajittelemaan tuloksen. Mittaa kyselyt sovelluksen todellisilla ehdoilla ja tulosmäärillä. Sama sana ”luku” ei tee niistä suorituskyvyn kannalta samaa työkuormaa.

Kirjoituskokeessa yksittäinen lisäys kertoo vain rajatusta tilanteesta. Sovelluksen tapahtuma saattaa päivittää useita rivejä, tarkistaa yksilöllisyysehdon ja muuttaa useita indeksejä samalla, kun muut tapahtumat tavoittelevat samoja rivejä. Tällöin läpimenon rinnalle tarvitaan odotusaika, epäonnistuneet tapahtumat ja uusintayritykset. Indeksi, joka nopeuttaa lukua, voi myös lisätä kirjoituksen vaatimaa työtä; molemmat vaikutukset kuuluvat samaan päätökseen.

Raporttikysely tarvitsee oman mittauksensa

Analytiikassa ratkaisevia voivat olla liitokset, ryhmittely, lajittelu ja suurten rivijoukkojen suodatus. Aluehaun aggregointitulos ei vielä kerro, miten usean taulun raportti toimii sovelluksen skeemalla. Siksi kriittinen raportti kannattaa ajaa kummassakin tietokannassa sellaisella tietomäärällä ja arvojen jakaumalla, jota tuotannossa odotetaan. Molempien kyselyjen on palautettava sama looginen tulos.

Indeksien ei tarvitse olla määrittelyiltään identtisiä, jos moottorit tarjoavat eri keinot samaan hakutehtävään. Vertailukelpoisuus syntyy samoista tiedoista ja vaaditusta tuloksesta sekä siitä, että kummallekin annetaan tarkoituksenmukainen skeema. Tarkista suoritussuunnitelmasta, mitä rivejä kysely lukee, missä se liittää ja lajittelee sekä käyttääkö se suunniteltua indeksiä. Mittaa sitten raportin vasteaika ja indeksien vaikutus levytilaan sekä kirjoittaviin tapahtumiin.

JSON-vertailussa ratkaisee hakuehto ja indeksi

PostgreSQL:n JSON-tyyppien ohje erottaa alkuperäisen tekstimuodon säilyttävän json-tyypin käsittelyyn optimoidusta jsonb-tyypistä. Jsonb-sarakkeelle voi rakentaa GIN-indeksin, joka tukee esimerkiksi avainten ja avain–arvo-parien hakua. Koko dokumentin indeksi tarjoaa joustavuutta, mutta vain usein haettuun polkuun kohdistuva indeksi voi olla pienempi. Valinta riippuu siis siitä, etsitäänkö tunnetun kentän arvoa vai monenlaisia ehtoja eri dokumenteista.

MySQL:n JSON-dokumentaation mukaan sen natiivi JSON-tyyppi tallentaa arvot sisäiseen muotoon, jota ei tarvitse jäsentää tekstistä jokaisella lukukerralla. JSON-saraketta ei indeksoida suoraan, mutta poimitulle skalaarille voi tehdä indeksoidun johdetun sarakkeen; InnoDB tukee myös moniarvoisia indeksejä JSON-taulukoille. Vertailussa MySQL:n JSON:ää ei siten pidä käsitellä pelkkänä tekstisarakkeena eikä PostgreSQL:n jsonb:tä automaattisena voittona ilman kyseistä hakuehtoa.

Toistettava JSON-koe sisältää saman dokumenttiaineiston, samoja osumia palauttavat hakuehdot ja kummallekin tietokannalle sopivat indeksit. Mittaa tunnetun polun haku erikseen laajemmasta dokumenttijoukkoon kohdistuvasta ehdosta. Jos dokumentteja muutetaan usein, lisää mukaan päivitys: hakua nopeuttavan indeksin ylläpito näkyy myös kirjoituskuormassa.

Toistettava koe pgbenchillä ja sysbenchillä

PostgreSQL:n pgbench-ohjeen oletustapahtuma on rajattu, TPC-B:tä mukaileva SELECT-, UPDATE- ja INSERT-komentojen sarja; työkalulla voi ajaa myös omia tapahtumaskriptejä. Oletuskoe sopii PostgreSQL-asennuksen vertailupisteeksi. Tietokantavalintaa varten pgbenchin omiin skripteihin on kuitenkin vietävä sovelluksen PostgreSQL-tapahtumat, ja järjestelmien väliseen suoraan vertailuun tarvitaan samaa työtä tekevä kuorma molemmille.

1. Kirjaa molempien tietokantojen ja sysbenchin tarkat versiot, prosessori, muisti, tallennus, käyttöjärjestelmä, yhteystapa ja palvelinasetukset. Aja tietokannat samalla laitteistolla yksi kerrallaan; tallenna myös pgbenchin versio PostgreSQL-koetta varten.
2. Lataa sama looginen skeema ja aineisto molempiin. Merkitse rivimäärät, arvojen jakauma, dokumenttien koko ja indeksit. Testaa tarvittaessa sekä välimuistiin mahtuva että sitä suurempi aineisto, sillä ne kuormittavat laitteistoa eri tavoin.
3. Aja sysbenchillä vertailukelpoiset pistehaku-, luku- ja kirjoitustapahtumat molempiin tietokantoihin. Aja sovelluksen PostgreSQL-tapahtumat erikseen pgbenchin omilla skripteillä. Vertaa tapahtumamääriä suoraan vain silloin, kun skriptit tekevät saman työn ja palauttavat saman tuloksen.
4. Määritä tapahtumarajat, vaadittu kestävyys ja eristystaso tietoisesti sekä kirjaa käytetyt arvot. Lämmitä järjestelmät ennen varsinaista mittausta, aja useita samanaikaisuustasoja toistuvasti ja tallenna läpimeno, vasteaikojen jakauma, virheet sekä suorittimen, muistin ja levyn käyttö.

Säilytä skeema, kyselyt, kuormaskriptit ja asetukset tulosten rinnalla. Jos järjestys muuttuu välimuistin, samanaikaisuuden tai asetuksen mukana, tulos kertoo juuri sen ehdon vaikutuksesta. Näin myöhempi versio voidaan mitata samalla tehtävällä ilman, että sovelluksen kyselyjakauma vaihtuu huomaamatta.

Miten valinta tehdään?

PostgreSQL on perusteltu valinta, jos sen ominaisuudet palvelevat sovelluksen tärkeimpiä raportti- tai JSON-kyselyjä ja oma koe osoittaa myös kirjoitusten vasteajan riittäväksi. MySQL on perusteltu, jos sen skeema ja indeksit täyttävät samat toiminnalliset vaatimukset paremmin tai sen käyttö sopii nykyiseen ylläpitoympäristöön. Ratkaiseva mittari on kriittisen työkuorman hyväksyttävä vasteaika, ei tietokannan yleinen arvosana.

Lue myös:

• GraphRAG vai vektori-RAG? Kysymyksen rakenne ratkaisee valinnan
• Ollama vai ChatGPT? Yksityisyys voittaa paikallisesti, teho pilvessä
• Firefox vai Brave? Oletussuoja ratkaisee ennen lisäosia