Kicsit hezitáltam, hogy mivel álljak neki a blog lényegi részének, aztán úgy gondoltam, hogy belecsapok a lecsóba, aztán majd megtalálom a hangot. Az egyik dolog, ami mostanában eléggé foglalkoztat, bár a kipróbálás részét egyelőre még halogatom, az a MySQL Proxy. Röviden összefoglalva a lényegét, nem másról van szó, mint a konkrét MySQL szerver előtt egy a kérdéseket és válaszokat feldolgozni, átalakítani képes csodaeszközről.
A Weblaboron egy blogbejegyzésben (Újdonságok a MySQL háza táján) már kifejtettem, hogy körülbelül miket tud, ezek alapján gondolkodom, hogy a napi eszköztáramban vajon mire lehetne használni. Egy elvileg könnyen tanulható scriptnyelvvel, a Lua-val programozható. Az ottani listán az alábbiakban végigmegyek, de előtte pár általános gondolat megfogalmazható.
Egy új szint
A MySQL Proxy valójában nem más, mint egy új szint/layer bevezetése. Ezt a layert egy jól felépített keretrendszerrel, vagy okos tárolt eljárásokkal, triggerekkel körülbelül most is fel tudja építeni bármely webprogramozó. Vannak azonban esetek, amikor egy jól programozható layer egy kényelmesebb, ügyesebb megoldást kínálhat. Ilyen lehet, amikor nem a programozó, hanem egy db admin próbálja meg az adatbázis viselkedését, a program működését monitorozni, vagy a programozók felé valamilyen extrább lehetőséget kínálni. Ha maga az alkalmazás a Proxy jelenlétére épít, az a hordozhatóságot csökkenti, de ez akár előny is lehet, hogy valamilyen szinten kötni szeretnénk a programozót, vagy a programot a mi platformunkhoz. Lehet kiegészítés szerű funkciókat is a MySQL-hez adni, ami egy nagyvállalati környezetben kényelmes lehet, hiszen független attól, hogy valaki PHP-ből, Java-ból, Perl-ből, .Net-ből éri-e el az adatbázisunkat.
Nézzük azonban a konkrétan felsorolt lehetőségeket, és az azokkal kapcsolatos gondolataimat.
Logolás
A MySQL Proxy logolni képes a teljes forgalmat, vagy annak csak egy programból meghatározott részét. Néhány alkalmazásomnál jó lenne látni, hogy honnan, milyen kéréseket teljesít, és azokat mennyi idő alatt hajtja végre – lehet, hogy elég szépen tudnám optimalizálni a lekérdezéseket ezzel. Ezt a MySQL csak nehézkesen támogatja alapból. Persze ezt elvileg önmagában a (PHP, Perl) alkalmazásban is meg tudnám valósítani, de ha vegyes a környezet, akkor jóval egyszerűbb lehet a MySQL Proxy segítségével (és hát vegyes). Esetleg a triviális, vagy cache-elhető lekérdezéseket egyből le tudná kezelni a Proxy is konkrét lekérdezések nélkül, ami azért javíthat a teljesítményen…
Elgépelések javítása
Ez az egyik dolog, aminek nem látom értelmét mint indok a MySQL Proxy mellett (MySQL Proxy segítségével lehet ugye olyan megoldást szülni, hogy az adatbázisnak egy “SLECT” se okozzon gondot, korrigálja azt “SELECT”-re). Sőt, néhány cikk ezzel is demózza a lehetőségeket. Míg egy ilyen demóból tényleg jól tanulható lehet az, hogy hogyan kell programozni a Proxy-t, addig nem hiszem el, hogy ez valódi segítség lehet valakinek. Elég kevés alkalommal építem fel úgy a lekérdezéseimet, hogy előtte parancssorból kipróbálom azokat, viszont a végeredményben nem szeretnék elgépeléseket látni. Ez a felhasználási mód azoknak lehet hasznos, akik gyakran tesznek fel gyors kérdéseket az adatbázisnak parancssorból, de nem ismerek olyan mazochistát, aki ezt nem egy kódszínezős, vagy legalábbis valamilyen emberibb felületről tenné.
Parancsok és adattartalmak megszűrése
Nem gondolom, hogy a biztonsági feladatokat, vagyis hogy ki milyen utasításokat adhat ki, milyen válaszokat kaphat vissza, azt a MySQL Proxy-ra kellene bízni, maga a MySQL és a rajta kívül felállított policy-k szerintem egy biztonságosabb, és jobban átlátható, egyszerűbb megoldást nyújthatnak. Azt viszont látom, hogy néhány esetben előfordulhat, hogy egy bonyolult feltételrendszert melyet a MySQL maga nem támogat, egyszerűbb lehet MySQL Proxy-val leprogramozni. De ez attól még nem segítség számomra.
Válasz üzenetek megváltoztatása, extra parancsok beillesztése
Na, ez egy komoly ügyesség lehet, hiszen vannak olyan válaszok, melyeket standard SQL-lel elég nehezen lehet a MySQL-ből (de más adatbázisból is) kicsiholni. Gondolok itt arra, amikor simán szeretném hogy egy lekérdezés eredményénél az egyik oszlop az adott válasz sorszámát tartalmazná, de beszélhetünk valami komolyabbról is, mint amikor szeretnénk pár sort összevonva, különböző szempontok szerint összegezve, valamilyen irányba transzponálva látni. Ez is egy dolog, ami kliens oldalon ugyanúgy megvalósítható, sőt, akár magában a MySQL-ben különböző tárolt eljárásokkal összehozható, de a tárolt eljárásoknál egyszerűbb, a kliens oldali megoldásnál pedig általánosabb lehetőséget kínálhat a Proxy használata. A Weblaboros cikkben elég jó példát hoztam fel, pl. minden INSERT után a beszúrt autoincrementes id-t adja vissza az SQL, egy mysql_insert_id-t (vagy SQL utasításként kiadását) megspórolhatjuk, ezzel eggyel kevesebb kört futva az SQL szerver felé. Ez a példa gyakorlatilag az extra parancsok beillesztését is lefedi, de a Proxy egyik érdekes felhasználási módja lehet, hogy kényelmesen tudunk például minden adott táblát érintő lekérdezés eredményéhez egy extra sort hozzátoldani, mely egy másik táblából szerez be információkat. Erre lehetőséget teremthet a tárolt eljárás is, kivéve ha valami SQL idegen, vagy a MySQL által “csak” nem támogatott dolgot szeretnénk megvalósítani.
Teljesítmény monitorozás
Ez gyakorlatilag a logolás egy másik módja, amikor szeretnénk megtudni az egyes lekérdezéseink hatékonyságát, sebességét.
Új parancsok, SQL-en kívüli világ
Valójában ez mozgatja meg leginkább a fantáziám. SQL felé kiadott parancs segítségével e-mail küldés, egy adott INSERT hatására például jelszóemlékeztető automatikus kiküldése. Vagy például hoszting környezetben a felhasználók a már bejáratott MySQL felhasználójuk segítségével le tudják kérdezni, hogy mekkora helyet foglalnak, hozzáférnek az egyébként nem MySQL-ben levő adataikhoz, stb. Könnyen tudunk egy olyan interfészt kínálni, melyen keresztül információkat tudunk átadni bármilyen meglévő rendszerünkből. Mi az egyszerűbb? A programozóknak egy általuk ismeretlen API-t átadni, vagy megmondani nekik, hogy ha egy ilyen és ilyen lekérdezést adnak ki, ezekhez és ezekhez az adatokhoz férnek hozzá? A válasz az lehet, hogy attól függ, de például egy közös MySQL-re épülő interfész leprogramozása sokkal költséghatékonyabb lehet, mint a cégnél/ügyfeleknél előforduló két-három nyelvre megírni és ledokumentálni egy egységes API-t, bugok nélkül.
Terhelés elosztás (és hasonlók)
Ez az, ami szintén eléggé megmozgatja a fantáziámat. Egyik nagy probléma a MyISAM táblákkal, hogy nem lehet fájdalommentesen élesben manipulálni őket, hiszen addig jellemzően blokkolva vannak a sima lekérdezések is feléjük, nem beszélve a módosításokról. Össze lehet azonban hozni egy olyan scriptet, ami átmenetileg puffereli mondjuk a változtatás jellegű kéréseket, vagy a backup adatbázis felé indítja el azokat, amíg az adatbázis szerver el van foglalva a dolgával. Vagy szeretnénk x táblával csinálni valamit, és készítünk róla egy másolatot, amit átmenetileg használunk, amíg be nem fejezzük x-szel a műveleteket. A címben levő terhelés elosztás, lekérdezések véletlenszerű vagy programozott szétosztása, a módosító műveletek pedig a fő szerver felé irányítása is elég egyszerű a MySQL Proxy segítségével.
Killer
A fentiek egyikét sem gondolom egyébként killer lehetőségnek, melynél a “best practice” az lenne, hogy a Proxy-t használjuk, bár ez változhat, ahogy egyre stabilabb rendszer lesz, és egyre többen fogják használni. Valószínűleg azonban a mindennapi munkánkat segítő kis scriptek tömkelege fog elérhetővé vállni, mint például a tesztelést segítő, makrók felvételét lehetővé tevő kis Proxy script, vagy hasonlók. Hogy általánosan elfogadott, az alap környezet részévé váló eszköz lesz-e a Proxy, vagy csak a saját szerverrel rendelkezők kiváltsága, azt még nehéz megmondani. Látok benne nagy fantáziát és kiaknázásra váró lehetőségeket, ha ezek bejönnek, akkor jó dolog lesz belőle minden bizonnyal. 
Utolsó megjegyzések