Kodėl vis dar kalbame apie šias dvi duomenų bazes?
Kai pradedi naują projektą ir reikia pasirinkti duomenų bazę, greičiausiai susidursi su amžinu klausimu: PostgreSQL ar MySQL? Taip, yra ir kitų variantų – MongoDB, MariaDB, Microsoft SQL Server – bet šios dvi reliacinės duomenų bazės vis dar dominuoja diskusijose tarp kūrėjų. Ir ne be priežasties.
Abi šios duomenų bazės egzistuoja jau daugiau nei du dešimtmečius. PostgreSQL atsirado 1996-aisiais kaip akademinis projektas, kuris turėjo įrodyti, kad galima sukurti tikrai pažangią, atvirojo kodo duomenų bazę. MySQL pasirodė maždaug tuo pačiu metu, bet su visiškai kita filosofija – būti greita, paprasta ir lengvai diegiama.
Šiandien abi šios sistemos yra brandžios, stabilios ir naudojamos milijonų projektų. Bet jų skirtumų vis dar pakanka, kad pasirinkimas nebūtų akivaizdus. Pažiūrėkime giliau, kas iš tikrųjų jas skiria ir kaip pasirinkti tinkamą savo projektui.
Architektūros filosofija ir tai, kaip ji veikia realybėje
PostgreSQL buvo kuriamas kaip objektinė-reliacinė duomenų bazė. Tai reiškia, kad ji nuo pat pradžių buvo orientuota į sudėtingas užklausas, duomenų vientisumą ir standartų laikymąsi. Kai skaitai PostgreSQL dokumentaciją, jauti, kad sistema sukurta žmonių, kurie tikrai domisi duomenų bazių teorija.
MySQL, priešingai, atsirado kaip greitas sprendimas web aplikacijoms. Pradžioje ji net neturėjo foreign keys palaikymo! Filosofija buvo paprasta: duok kūrėjams įrankį, kuris veikia greitai ir nereikalauja doktorantūros laipsnio, kad jį suprastum.
Šios skirtingos filosofijos atsispindi ir šiandien. PostgreSQL turi daug daugiau įtaisytų duomenų tipų – nuo JSON ir XML iki geometrinių duomenų ir tinklų adresų. Gali sukurti savo duomenų tipus, rašyti funkcijas įvairiomis kalbomis (ne tik SQL), net įdiegti išplėtimus, kurie iš esmės keičia duomenų bazės elgesį.
MySQL išliko paprastesnė. Tai nereiškia, kad ji primitivi – tiesiog ji nesiūlo tiek daug galimybių iš dėžės. Daugeliui projektų tai privalumas, ne trūkumas. Mažiau pasirinkimų reiškia mažiau galimybių suklysti.
Našumo klausimai, kurie ne tokie paprasti
Jei paskaitytumėte senus forumus, rastumėte nesibaigiančias diskusijas apie tai, kuri duomenų bazė greitesnė. Tiesa ta, kad atsakymas priklauso nuo to, ką darai.
MySQL istoriškai buvo greitesnė paprastoms read operacijoms. Jei tavo aplikacija daugiausia skaito duomenis ir retai juos keičia, MySQL su MyISAM varikliu galėjo būti žaibiškai greita. Bet MyISAM neturi transakcijų palaikymo, todėl šiandien dauguma naudoja InnoDB variklį, kuris yra transakcinis.
PostgreSQL paprastai geriau tvarko sudėtingas užklausas su JOIN’ais, subquery ir agregacijomis. Jos query planner yra sofistikuotesnis ir dažnai sugeba optimizuoti sudėtingas užklausas geriau nei MySQL. Jei rašai analitines užklausas ar dirbi su dideliais duomenų kiekiais, tai svarbu.
Bet štai įdomus dalykas: dauguma projektų niekada nepasiekia taško, kur duomenų bazės našumas tampa bottleneck’u. Paprastai problema būna prastai parašytose užklausose, trūkstamose indeksuose ar aplikacijos logikoje. Tad jei renkiesi duomenų bazę tik dėl našumo, gali būti, kad sprendžia ne tą problemą.
Vienas konkretus atvejis, kur skirtumas tikrai matomas: write-heavy aplikacijos su daug concurrent vartotojų. PostgreSQL MVCC (Multi-Version Concurrency Control) implementacija leidžia skaitymams ir rašymams nevykti vieniems kitiems į kelią. MySQL InnoDB taip pat turi MVCC, bet PostgreSQL implementacija paprastai geriau veikia su daug konkuruojančių transakcijų.
Duomenų vientisumas ir ACID compliance
Čia PostgreSQL tikrai šviečia. Ji nuo pat pradžių buvo kuriama su ACID principais galvoje. Tai reiškia, kad duomenų vientisumas yra prioritetas, ne pasirinkimas.
PostgreSQL palaiko visus constraint tipus, kuriuos tikėtumėisi: foreign keys, check constraints, unique constraints, exclusion constraints. Ir ji juos tikrai vykdo. Negali išjungti foreign key patikrinimų, net jei labai norėtum (o kartais norisi, kai importuoji didelius duomenų kiekius).
MySQL čia turi sudėtingesnę istoriją. InnoDB variklis palaiko foreign keys ir transakcijas, bet MyISAM ne. Ir nors šiandien InnoDB yra default, vis dar gali susidurti su legacy sistemomis, kurios naudoja MyISAM ar kitus variklius. Be to, MySQL leidžia daugiau „atlaidumo” – gali įterpti neteisingos datos reikšmes, kurios bus automatiškai konvertuotos į „0000-00-00”, vietoj to, kad mestų klaidą.
Jei dirbi su finansiniais duomenimis, medicinos įrašais ar bet kuo, kur duomenų vientisumas yra kritinis, PostgreSQL griežtesnis požiūris yra privalumas. Jei dirbi su content management sistema ar paprastu blog’u, MySQL atlaidumas gali būti patogesnis.
JSON ir NoSQL funkcionalumas reliacinėje bazėje
Prieš kokius dešimt metų visi kalbėjo, kad reliacinės duomenų bazės yra praeitis, o ateitis priklauso NoSQL sprendimams kaip MongoDB. Na, nevisai taip išėjo.
PostgreSQL atsakė į šį iššūkį pridėdama puikų JSON palaikymą. Ir ne tik saugojimą – gali indeksuoti JSON laukus, rašyti užklausas, kurios filtruoja pagal JSON struktūrą, net naudoti GIN indeksus greitam paieškai. JSONB duomenų tipas (binary JSON) yra ypač galingas – jis saugo duomenis optimizuotu formatu, leidžiančiu greitą prieigą.
Tai reiškia, kad gali turėti „best of both worlds” – struktūruotus duomenis reliacinėse lentelėse ir lankstų, schema-less JSON tose vietose, kur tai turi prasmę. Pavyzdžiui, vartotojo nustatymus ar metadata gali saugoti kaip JSON, o pagrindinius duomenis – tradicinėse lentelėse su foreign keys.
MySQL taip pat pridėjo JSON palaikymą, bet jis nėra toks galingas. Gali saugoti JSON ir atlikti kai kurias operacijas, bet funkcionalumas ir našumas nėra toks geras kaip PostgreSQL. Jei JSON yra svarbi tavo projekto dalis, PostgreSQL aiškiai laimi.
Ekosistema, įrankiai ir community
Abi duomenų bazės turi dideles, aktyvias bendruomenes, bet jos šiek tiek skiriasi.
MySQL turi ilgesnę istoriją web hostinge. Dauguma shared hosting planų automatiškai suteikia MySQL prieigą. LAMP (Linux, Apache, MySQL, PHP) stack’as buvo standartas dešimtmečius. Tai reiškia, kad MySQL turi daugiau tutorialų pradedantiesiems, daugiau legacy kodo ir daugiau žmonių, kurie ją moka.
PostgreSQL bendruomenė linkusi būti labiau techninė. Dokumentacija yra išsami ir gerai parašyta, bet kartais gali jaustis per daug akademiška. Kita vertus, PostgreSQL extensions ekosistema yra įspūdinga. PostGIS geografiniams duomenims, TimescaleDB time-series duomenims, Citus distributed duomenų bazėms – šie extensions iš esmės paverčia PostgreSQL specialized duomenų baze be poreikio keisti sistemą.
Įrankių prasme, abi turi puikių variantų. pgAdmin ir DBeaver PostgreSQL, MySQL Workbench ir phpMyAdmin MySQL. Bet PostgreSQL psql command-line interface yra žymiai galingesnis nei MySQL mysql client – tai gali atrodyti smulkmena, bet kai dirbi su duomenų baze kasdien, geri command-line įrankiai tikrai svarbu.
Licencijavimas ir verslo realybės
Čia reikia būti atsargiems, nes situacija yra sudėtingesnė nei atrodo.
PostgreSQL naudoja PostgreSQL License, kuri yra labai liberali (panaši į MIT ar BSD). Gali daryti beveik bet ką – naudoti komercinėse aplikacijose, modifikuoti, net parduoti. Nėra jokių string’ų prisegta.
MySQL situacija komplikuotesnė. Oficialiai ji yra GPL licencijos, bet priklauso Oracle. Tai reiškia, kad jei nori įterpti MySQL į savo komercinį produktą (ne tiesiog naudoti ją kaip backend), gali prireikti komercines licencijos iš Oracle. Praktikoje, jei tavo aplikacija jungiasi prie MySQL per standartinį client API, GPL neturėtų būti problema. Bet jei kurti produktą, kuris bus parduodamas su MySQL, pasikalbėk su teisininku.
Dėl šios priežasties atsirado MariaDB – MySQL fork’as, kuris išliko tikrai open source. Jei tau svarbu išvengti bet kokių Oracle string’ų, MariaDB gali būti geresnis pasirinkimas nei MySQL.
Oracle nuosavybė taip pat reiškia, kad MySQL vystymasis gali būti mažiau nuspėjamas. Kai kurios features atsiranda tik komercinėje versijoje. PostgreSQL, būdama community-driven, neturi šios problemos.
Migracija, mokymasis ir komandos kompetencija
Vienas dažnai ignoruojamas aspektas: kas tavo komandoje jau žino? Jei turi tris kūrėjus, kurie dirbo su MySQL penkis metus, perėjimas prie PostgreSQL turės kainą. Ne tik mokymosi kreivė, bet ir produktyvumo kritimas pirmuosius mėnesius.
Sakoma, kad jei moki vieną SQL duomenų bazę, lengvai išmoksi kitą. Tai tik iš dalies tiesa. Taip, pagrindiniai SQL statement’ai panašūs, bet devils in the details. PostgreSQL turi skirtingą sintaksę string concatenation (|| vietoj CONCAT), skirtingai tvarko date arithmetic, turi RETURNING clause, kurį MySQL neturi (bent jau ne visose versijose).
Jei planuoji migraciją iš vienos į kitą, būk pasirengęs, kad tai nebus tiesiog dump ir restore. Turėsi perrašyti stored procedures (jei naudoji), patikrinti visas užklausas dėl sintaksės skirtumų, galbūt pakeisti kai kuriuos duomenų tipus. Yra įrankiai, kurie padeda (pvz., pgloader PostgreSQL pusėje), bet tikėkis, kad prireiks rankinio darbo.
Praktinis patarimas: jei pradedi naują projektą ir dar neturi stiprių preferencijų, PostgreSQL greičiausiai yra saugesnis pasirinkimas ilgalaikėje perspektyvoje. Ji turi daugiau features, geresnį standartų palaikymą ir mažiau vendor lock-in rizikos. Bet jei jau turi MySQL expertise komandoje arba dirbi su legacy sistema, nėra būtinybės skubėti keisti.
Kas iš tikrųjų svarbu jūsų projektui
Po viso šio teksto, tiesa yra ta, kad dauguma projektų puikiai veiktų su bet kuria iš šių duomenų bazių. Skirtumai, kurie atrodo dideli popieriuje, praktikoje dažnai nėra tokie svarbūs.
Pasirinkite PostgreSQL, jei:
– Dirbate su sudėtingais duomenimis ir reikia pažangių features
– Duomenų vientisumas yra kritinis (finansai, medicina)
– Planuojate naudoti JSON ar kitus specialty duomenų tipus
– Norite išvengti vendor lock-in
– Jūsų komanda jau turi PostgreSQL patirties
Pasirinkite MySQL (ar MariaDB), jei:
– Jums reikia paprastumo ir greito setup
– Dirbate su legacy sistema, kuri jau naudoja MySQL
– Jūsų hosting provider geriau palaiko MySQL
– Komanda jau moka MySQL ir nėra stiprios priežasties keisti
– Projektas yra paprastas ir nereikalauja pažangių features
Bet svarbiausia – nesukite sau galvos per daug. Abi šios duomenų bazės yra puikios, brandžios sistemos. Jūsų projekto sėkmė priklausys nuo to, kaip gerai suprojektuosite schemas, kaip efektyviai rašysite užklausas ir kaip gerai optimizuosite indeksus. Ne nuo to, ar pasirinkote PostgreSQL ar MySQL.
Pradėkite su ta, kuri jums patogesnė dabar. Jei vėliau paaiškės, kad reikia keisti, migracija nėra neįmanoma. Bet greičiausiai neprireiks – dauguma projektų niekada nepasiekia taško, kur duomenų bazės pasirinkimas tampa limituojančiu faktoriumi. Paprastai problema būna mūsų parašytame kode, ne duomenų bazės variklyje.