PostgreSQL ili MySQL: jednostavan OLTP i analitika daju drugog pobjednika

Za aplikaciju u kojoj prevladavaju kratke transakcije MySQL je snažan kandidat; ako su važni povezani poslovni postupci i zahtjevni analitički upiti, prednost se može okrenuti PostgreSQL-u. U usporednom testu PostgreSQL-a 16.0 i MySQL-a 8.0.34 MySQL je pri umjerenoj konkurentnosti postigao do 21 % veći vršni protok u jednostavnom OLTP-u, dok je PostgreSQL ostvario oko 14 % veći protok u složenom TPC-C opterećenju te dovršio ispitani TPC-H skup za 1245 sekundi naspram MySQL-ovih 3890 sekundi.

Ti rezultati opisuju konkretne verzije, postavke i sintetičke upite, pa izbor ne svode na opću ljestvicu brzine. Presudno je koliko aplikacija izvodi jednostavnih čitanja i pisanja, koliko često transakcije zahvaćaju povezane podatke te izvode li se izvještaji na istoj bazi. Jednako je važno može li tim održavati odabrani sustav kada promet poraste ili oporavak podataka postane hitan.

Kratke transakcije: kada MySQL vodi

Prednost MySQL-a u jednostavnom OLTP-u odnosi se na ponavljane, razmjerno kratke operacije čitanja i pisanja. Ispitani SysBench profil uključuje dohvat pojedinačnih redaka i raspona te izmjene podataka. To je korisna usporedba za aplikaciju u kojoj indeks brzo pronalazi traženi zapis, a najveći dio prometa nastaje iz mnogo sličnih zahtjeva.

Vršni broj transakcija ipak ne opisuje cijeli korisnički doživljaj. U istom je pokusu MySQL-ov protok pri većem broju istodobnih klijenata prestao rasti, dok mu je vrijeme odziva raslo; PostgreSQL se u tom dijelu opterećenja ponašao ujednačenije. Ako promet stiže u naletima, baza koja obrađuje više zahtjeva u povoljnoj točki testa ne mora pružiti bolji odziv u najopterećenijem trenutku. Zato su za takav sustav važni i sporiji zahtjevi, a ne samo najveći zabilježeni protok.

Povezane transakcije: važan je cijeli postupak

Jednostavan dohvat retka slabo predstavlja postupak koji istodobno čita i mijenja više povezanih zapisa. Opis mjerila TPC-C obuhvaća unos i isporuku narudžbi, evidentiranje plaćanja, provjeru statusa te stanje zaliha u okruženju s istodobnim korisnicima. Takva mješavina bolje pokazuje što se događa kada transakcije dijele podatke i moraju sačuvati njihovu dosljednost.

U usporednom pokusu PostgreSQL je na tom profilu ostvario veći protok i kraće vrijeme odziva sporijih transakcija. Za aplikaciju u kojoj korisnik čeka dovršetak narudžbe zajedno s promjenom zaliha i evidentiranjem plaćanja to je korisniji signal od brzine izdvojenog čitanja. Omjer se ipak može promijeniti s drukčijim indeksima, raspodjelom zahtjeva i učestalošću sukoba oko istih redaka. Mjerodavna jedinica usporedbe zato je poslovni postupak koji aplikacija doista mora dovršiti.

Analitika: trajanje izvještaja mijenja izbor

Analitičko opterećenje traži drukčije mjerilo od kratkih transakcija. Upit koji spaja velike tablice, filtrira mnogo redaka i računa agregate može dugo zauzimati procesor i memoriju premda se pokreće rijetko. U ispitanom TPC-H skupu PostgreSQL je završio znatno prije MySQL-a, pa rezultat ide u prilog PostgreSQL-u kada baza uz korisničke transakcije mora obrađivati i zahtjevne izvještaje.

Razlika u ukupnom trajanju skupa upita ipak ne govori jednako mnogo o svakom izvještaju. Neki produkcijski upiti spajaju malo podataka nakon selektivnog filtriranja, dok drugi moraju pročitati velik dio tablica. Njihovo trajanje ovisi o raspodjeli vrijednosti, dostupnim indeksima i planu izvršavanja. Ako se izvještaji obrađuju u zasebnom analitičkom sustavu, njihova brzina ima manju težinu pri izboru baze koja služi ponajprije kratkim korisničkim transakcijama.

Granice prijenosa benchmarka u produkciju

Test je proveden u određenom računalnom okruženju, uz podešenu memoriju, pohranu i broj veza. Te odluke utječu na usporedbu jednako kao i izbor baze. U opisu jednostavnog OLTP pokusa postoji i važan nesklad: tekst tvrdi da je skup podataka veći od memorije dodijeljene virtualnom stroju, premda navedeni kapaciteti pokazuju suprotan odnos. Iz toga se ne može pouzdano zaključiti kako bi se sustavi poredali kada radni skup ne bi stao u memoriju.

Treba razlikovati i test koji koristi TPC-C ili TPC-H profil od službeno objavljenog rezultata po pravilima tih mjerila. Usporedni rad izvještava o protoku transakcija i ukupnom vremenu izvođenja vlastitog skupa upita. Te su vrijednosti korisne za usporedbu unutar njegova pokusa, ali se ne mogu izravno usporediti s rezultatima drugih konfiguracija objavljenima prema službenim TPC pravilima. Za arhitektonsku odluku vrijede ponajprije kao pokazatelj da promjena vrste opterećenja može promijeniti poredak.

Mogućnosti sustava i operativni rizik

PostgreSQL-ova matrica mogućnosti dokumentira paralelno izvršavanje upita, materijalizirane poglede, particioniranje i različite oblike replikacije. Te mogućnosti mogu biti važne ako aplikacija na istoj bazi obrađuje složenije upite ili treba poseban način organizacije podataka. Njihova dostupnost sama po sebi ne jamči kraće izvršavanje konkretnog izvještaja: presudni ostaju podaci, upit i način na koji se izvršava.

Dokumentacija MySQL-a navodi transakcijske pogone za pohranu, grupiranje i agregacije te naredbu EXPLAIN za uvid u plan upita. Stoga razlika između sustava nije podjela na bazu koja može i bazu koja ne može obraditi složeniji SQL. Pitanje je zadovoljavaju li dostupne mogućnosti, odziv i način održavanja potrebe određene aplikacije.

Operativno iskustvo tima mijenja cijenu izbora. Postojeći postupci za nadzor, sigurnosne kopije, oporavak i podešavanje mogu smanjiti rizik kod sustava koji tim već poznaje. Kad su razlike u odzivu na vlastitim upitima male, ta pouzdanost može biti važnija od prednosti iz tuđeg testa. Kad su zahtjevni izvještaji ili povezane transakcije središnji dio proizvoda, njihovo ponašanje zaslužuje veću težinu od poznatosti alata.

Odluka prema profilu aplikacije

Ako većinu prometa čine kratka čitanja i pisanja uz predvidljiv pristup zapisima, MySQL je razuman početni izbor. Ako ključni postupci obuhvaćaju više povezanih promjena ili ista baza mora brzo završavati složene izvještaje, PostgreSQL ima jači argument u promatranom testu. Mješovita aplikacija traži procjenu udjela tih poslova: rijedak analitički upit i stalni analitički promet ne stvaraju isti pritisak na sustav.

Konačna usporedba treba odražavati stvarne upite, sličnu količinu i raspodjelu podataka te očekivanu istodobnost korisnika. Uz protok valja promatrati vrijeme odziva sporijih zahtjeva i cjelovitih poslovnih postupaka. Tako se vidi je li prednost povezana s vrstom baze ili s indeksom, planom upita, dodijeljenom memorijom i postavkama koje će tim morati održavati.

Pročitajte i:

• Trello ili Asana: besplatni plan puca na veličini ili složenosti tima
• Hootsuite ili Sprout Social: analitika dolazi uz skupo sjedalo
• Qdrant ili Milvus: mali test i veliki klaster ne daju istog pobjednika