PostgreSQL vagy MySQL: a terhelés típusa többet számít a ranglistánál

|Szerző: A QUASA szerkesztősége|5 perc olvasás
PostgreSQL vagy MySQL: a terhelés típusa többet számít a ranglistánál

Új alkalmazáshoz az egyszerű, előre ismert webes lekérdezéseknél a MySQL jó első jelölt; változatos JSON-keresésnél, összetett tranzakcióknál és analitikánál a PostgreSQL-t érdemes először megvizsgálni. Ez kiindulópont, nem általános sebességi sorrend: a döntést az adatmodell, a szükséges indexek és a várható terhelés együtt határozza meg.

Mindkét rendszer képes hagyományos relációs alkalmazást kiszolgálni. Ha a funkciók alapján mindkettő megfelel, a csapat üzemeltetési tapasztalata is számít: a mentés, a frissítés és a hibakeresés ismert folyamata többet érhet egy más feladatra mért előnynél. A benchmark akkor segít, ha a lekérdezések és a párhuzamos műveletek hasonlítanak a készülő alkalmazáséhoz.

Az indexet a lekérdezés alakja határozza meg

Egyszerű webes CRUD-rendszernél először a gyakori WHERE-feltételeket, rendezéseket és táblakapcsolásokat érdemes azonosítani. A MySQL indexelési leírása szerint a szokásos elsődleges, egyedi és általános indexek többnyire B-tree szerkezetűek, a többoszlopos indexnek pedig a balról kezdődő oszlopkombinációi használhatók keresésre. Ha például egy feltételezett rendelési alkalmazás állapot és létrehozási idő szerint listáz, a két mező sorrendje az összetett indexben a lekérdezésektől függ. Ez az indexelési lehetőség önmagában nem bizonyít MySQL-előnyt a PostgreSQL-lel szemben.

A PostgreSQL is kínál B-tree indexet, emellett más hozzáférési módszereket és célzottabb indexdefiníciókat. A CREATE INDEX dokumentációja a GIN és BRIN módszert, a kifejezésre épülő indexet és a csak a feltételnek megfelelő sorokat tartalmazó részleges indexet is leírja. Utóbbi akkor lehet hasznos, ha egy ritka állapotú sorcsoportot gyakran keresnek; az indexnek nem kell a tábla minden sorát lefednie. Az előny a szűrési mintától függ, ezért nem következik pusztán abból, hogy az adott indexfajta elérhető.

Az indexeknek írási és tárolási költségük is van: az érintett bejegyzéseket módosításkor karban kell tartani. Sok rövid írást végző rendszerben ezért más indexkészlet lehet célszerű, mint egy olyanban, ahol a ritkább módosítások mellett sokféle olvasási feltételt kell gyorsítani. A választás alapja a ténylegesen fontos lekérdezések és az ezekhez szükséges indexek együttese.

JSON-nál a keresett mezők változékonysága számít

A PostgreSQL jsonb GIN-indexe és a MySQL kinyert JSON-értékre épülő indexe eltérő keresésekhez illeszkedik.

Ha az alkalmazás rendszeresen eltérő kulcsokra, beágyazott értékekre vagy dokumentumrészletekre keres, a PostgreSQL jsonb típusa és GIN-indexe rugalmas kiindulópont. A jsonb indexelési dokumentációja szerint az alapértelmezett operátorosztály támogatja a kulcs létezését, a tartalmazást és a megfelelő jsonpath-feltételeket vizsgáló műveleteket. A jsonb_path_ops kevesebb operátort kezel: kulcslétezési keresésre nem használható, tartalmazási és támogatott jsonpath-kereséseknél viszont általában kisebb, célzottabb indexet ad.

Az is lényeges, hogy a lekérdezés milyen mélységben keres. A jsonb kulcslétezési operátora a vizsgált érték legfelső szintjén keres; beágyazott részstruktúránál más kifejezésre vagy tartalmazási feltételre lehet szükség. Az index tehát nem váltja ki a lekérdezési minta pontos meghatározását. Egy rugalmas dokumentummodell akkor előny, ha a változó szerkezet valóban része az alkalmazás működésének.

Néhány előre ismert JSON-útvonal esetén a MySQL is kínál indexelhető megoldást. A MySQL JSON-leírása szerint a dokumentumból kinyert skalárérték generált oszlopon keresztül indexelhető, az InnoDB pedig JSON-tömbökhöz többértékű indexet is támogat. Ha a rendszer mindig ugyanarra a kevés mezőre szűr, ez elegendő lehet. Ha az üzleti szűrők állandóak és fontosak, külön relációs oszlopokkal az indexelés és az adatmodell is könnyebben áttekinthető.

Mit mutat az azonos hardveren végzett mérés?

A közzétett TPC-C- és TPC-H-mérésben a PostgreSQL és a MySQL eredménye eltér az egyszerű OLTP-terhelés sorrendjétől.

A terhelés típusa egy közzétett összehasonlításban megváltoztatta a sorrendet: az egyszerű SysBench OLTP-feladatban a MySQL ért el nagyobb csúcsteljesítményt, míg az összetettebb TPC-C és az analitikai TPC-H feladatban a PostgreSQL szerepelt jobban. A 2025 októberében közölt vizsgálatban PostgreSQL 16.0 és MySQL 8.0.34 futott ugyanazon fizikai szerveren, külön virtuális környezetben; a TPC-C terhelésnél 128 párhuzamos felhasználó mellett másodpercenként 1850, illetve 1620 tranzakciót mértek, a TPC-H lekérdezéssorozat pedig 1245, illetve 3890 másodpercig tartott.

A SysBench egyszerű olvasási és írási műveleteket, a TPC-C több táblát érintő tranzakciókat, a TPC-H hosszabb analitikai lekérdezéseket terhelt. Az azonos fizikai gép fontos közös feltétel, de a rendszerek külön virtuális gépeken, saját hangolt beállításokkal futottak. A módszertani leírás ráadásul az egyszerű OLTP-adatok és a rendelkezésre álló memória viszonyáról egymással össze nem illő állításokat tartalmaz. Az eredmények ezért a feladattípusok közötti különbséget szemléltetik; a közölt időket és áteresztőképességet nem lehet egy új alkalmazás várható értékeiként átvenni.

Döntési fa új alkalmazáshoz

A kiinduló kérdés az, hogy mely műveletek határozzák meg a rendszer működését. A domináns lekérdezéstípus megmutatja, melyik jelöltet érdemes előbb kipróbálni; a funkcionális igények és a csapat tapasztalata eldöntheti, szükség van-e egyáltalán váltásra. A választást a saját adatmodellre készített indexekkel és a várható párhuzamossággal végzett próba zárhatja le.

  • Egyszerű webes CRUD: ha a kérések többnyire ismert kulcsokon keresnek, rövid listákat adnak vissza és kiszámítható módon módosítanak sorokat, a MySQL ésszerű első jelölt. A PostgreSQL-t ismerő csapatnak azonban az ilyen terhelés önmagában nem indok a MySQL-re váltásra. Itt a gyakori keresések és módosítások válaszideje a döntő.
  • Nagy konkurenciájú, összetett tranzakciók: több táblát érintő, egyidejű módosításoknál a PostgreSQL legyen az elsőként vizsgált jelölt. A TPC-C eredménye ebbe az irányba mutat, de a saját alkalmazásban a zárolási konfliktusok, a tranzakciók hossza és a lassabb kérések késleltetése határozza meg a felhasználói következményt.
  • JSON-központú rendszer: változó kulcsokra és beágyazott részstruktúrákra irányuló keresésnél a PostgreSQL jsonb GIN-indexei kínálnak kézenfekvő tervet. Néhány állandó útvonalhoz a MySQL kinyert értékekre épülő indexe is megfelelhet. A döntő különbség az, hogy a keresések mennyire előre rögzítettek.
  • Analitika: sok sort érintő kapcsolásoknál, csoportosításnál és összesítésnél a PostgreSQL indokolt első jelölt a vizsgált TPC-H-terhelés alapján. A saját jelentések futási ideje különösen akkor fontos, ha ugyanaz az adatbázis szolgálja ki a napi tranzakciókat is.

Ha a két jelölt továbbra is versenyben van, azonos adatokkal, a szükséges indexekkel és hasonló erőforráskerettel érdemes mérni őket. Az áteresztőképesség mellett a lassabb kérések késleltetése is számít: egy rendszer több műveletet végezhet el összesen, miközben egyes felhasználói kérések tovább várnak. Így a választás alapja az alkalmazás terhelése lesz, amelyre az adatbázist használni fogják.

Olvassa el ezt is:

Megosztás:

Kapcsolódó cikkek

Iratkozzon fel hírlevelünkre

A legfrissebb Web3-, MI- és kriptohírek egyenesen a postafiókjába.

0