Ha olvasod a blogom korábbi bejegyzéseit, tudhatod, hogy nem vagyok híve a vegyünk minden hónapban egy erősebb szervert, ha valami webes szolgáltatás kezd kifogyni az erőforrásokból. Ahogy sokszor hangoztatom azt is, hogy nem a PHP lassú, hanem az, ami kiszolgálja: a legtöbb esetben az adatbázis válaszideje.
Aki ismer, tudja hogy jelenleg 2 nagyobb projekten dolgozom, amiből az egyik egy gyorsétterem lánc számára készült szolgáltatás. Ebben jelenleg minden magyarországi étterem benne van, ami elég sok kérést intéz az adatbázis felé, ami szépen meg is hízott már. Igen, tudom, az ilyenre már nem való a MySQL/MariaDB, erre már minimum a PostgreSQL kell(ene). De ez utóbbit nem tudom magabiztosan használni és a projektek sem engedik meg időben a gyakorlást.
A nagy mennyiségű adat miatt a hagyományos SELECT * FROM kérések már az első pillanattól nem jöhettek szóba. Most már elért oda az egész jól megválasztott indexekkel, hogy konstans 40-60% load van nyitvatartási időkben, ami előrevetítette azt, hogy pár hónapon belül elfogy a $15-os VPS. Ilyenkor a legtöbb fejlesztő – főleg a prok – azonnal kér sokkal nagyobb gépet és probléma megoldva. Mivel én nem vagyok ilyen és nem vagyok a saját zsebem ellensége sem (ugyanis én adom alá a szervert és a hálózatot is), ezért az „álmatlan éjszaka” akció keretében túl kellett lépni a saját határaimat és úgy látszik, hogy a MySQL/MariaDB határait is: materializált view-ra volt szükség.
Pontosabban olyan táblákra, amiben mindig friss adatok vannak, de csakis azok, amiket a legtöbbet kérdezek le. Tipikusan ilyen az appok change pollingja, amikor csak azt nézik, hogy változik-e valami a szerveren, szükség van-e szinkronizációra, van-e app frissítés, miegymás. Igen, pontosan erre találták ki a materializált view-t, mondják azok, akik MSSQL, PGSQL, ORACLE, … adatbázisokkal dolgoznak. Na, a webesek 99%-a viszont MySQL/MariaDB-t használ. Per pillanat a MySQL 8.0.x a MariaDB 10.4.x (ami MySQL 5.7.x) stabil verziónál tart, mindkettő weblapján ott van, hogy nem támogatják az ilyen típusú view-kat.
Amíg hírportálok motorjait írtam, addig ez nem volt gond, mert a MySQL nagyon jól cacheli a view-k eredményeit, meg kellett emelni a cache méretet és a többit a látogatók megoldották. Hisz’ a hírportálokon csak pár óránként van változás, de konstans 50-500 látogató kattintgat. Sokan elé tesznek valami cache megoldást, amit az admin felületben a cikk mentése gomb frissít be, vagy statikus fájl cache-t csinálnak.
A megoldást az lett, hogy csinálok egy MEMORY táblát cache-nek, és a 3 triggerrel (INSERT, UPDATE, DELETE) befrissítem. Kiegésztve azzal, hogy mivel ügye SELECT-re nincs trigger – , de a MEMORY tábla tartalma elvész szerver restartkor – a PHP-s API backend nézi meg, hogy szerepel-e a cacheben a bejegyzés. Ha nem, akkor feltölti a cache-t és visszaadja amit kell.
A végeredmény pedig:
