lworm (egy pehelysúlyú PHP ORM megoldás)

Amikor elkezdett foglalkoztatni a gondolat, hogy PHP-ban fejlesszek Google App Engine-re, az egyik legnagyobb problémának az adatbázis elérése tűnt, hiszen PHP-ból általában SQL használunk erre, ami ugye App Engine alatt nem megoldható, hiszen a datastore egy nem relációs adatbázis. Utánanéztem kicsit, hogy mások hogy oldják meg ezt, és igazából két megoldást találtam. Az egyik az App Engine által szolgáltatott JPA vagy JDO réteg használata. Itt ugye az a gond, hogy ezzel elveszítjük a rendszer hordozhatóságát, hiszen egy standard LAMP környezetben már nem állnak rendelkezésre ezek a programkönyvtárak. A másik lehetséges megoldás, hogy valamilyen SQL wrappert használunk, amin keresztül a datastore szabvány SQL adatbázisnak tűnik. Ezzel az volt a gondom, hogy feleslegesnek tűnt, hiszen az SQL réteg felett úgyis valamilyen ORM réteget használnék, és ha már így van, miért ne építsük az ORM réteget közvetlenül a datastore fölé. Így született tehát az elhatározás, hogy saját ORM réteget fejlesszek PHP-hoz, és ha már belefogtam, megpróbáltam belegyúrni az eddigi tapasztalataimat.

Az első szempont az egyszerűség volt. Minimalista megoldást akartam, ami egyszerű, de mégis hatékony. E mellett legyen transzparens, tehát az elkészült PHP alkalmazás egyaránt képes legyen futni egy általános LAMP környezetben, és az AppEngine datastore-ja felett is. Mivel annak idején a Hibernate-el volt némi nézeteltérésem, mindenképp olyan megoldást akartam, ahol az entitások memória objektumok, tehát nincsenek az adatbázishoz kötve (csúnyán mondva nem attach-oltak). Itt most nem térnék ki a részletekre, de a lényeg, hogy ennek köszönhetően az adatbázis objektumokat büntetlenül tárolhatjuk a session-ben, vagy mondjuk JSON formában mozgathatjuk őket két rendszer között. Kb. ezek voltak az előfeltételek, lássuk hát a megvalósítást.

A rendszer használatához elsőként egy YAML állományban le kell írnunk az adatbázis sémát és az entitások kapcsolatrendszerét. Ez a YAML formátum felépítésének köszönhetően nem túl bonyolult, mégis szép és átlátható. A YAML alapján a ModelGenerator osztály használatával legenerálhatjuk az entitás osztályokat. Az entitás objektumok csak egyszerű adattároló szerepet töltenek be, így felépítésük az adatbázis megvalósítástól független. Ha ezzel megvagyunk, a megfelelő Datastore factory hívásával kérhetünk a rendszertől egy datastore példányt, aminek segítségével az adatokkal kitöltött entitás az adatbázisra menthető, illetve onnan felolvasható. Ugyancsak a datastore segítségével generálhatunk lekérdezéseket, aminek segítségével egyenlőre csak szűrni és rendezni lehet az eredményeket. Ennek az az oka, hogy az alacsony szintű datastore API csak ezeket teszi lehetővé. Bár lehet, hogy ez az eszközkészlet kicsit szegényesnek tűnik, de az esetek nagy részében általában elég, vagy némi kódolással kiegészíthető. Az entitás példányok kapcsolatainak kezelésére azt találtam ki, hogy az entitás objektum minden kapcsolatához egy metódust rendeltem, ami paraméterként kapja meg az aktuális datastore-t. A metódus egy kezelő objektumot ad vissza, ami a kapcsolatnak megfelelően karbantartja a kapcsolódó objektumokat. Tehát vegyük például a User (felhasználó) és Role (szerepkör) entitásokat, melyek közt many-to-many (több-több) kapcsolat van. Ebben az esetben a User osztálynak lesz egy getRolesRelation metódusa, ami egy kezelő objektumot ad vissza. Ezen az objektumon keresztül adhatunk hozzá Role-okat az adott felhasználóhoz, ezen keresztül listázhatjuk ki a hozzárendelt szerepköröket, vagy törölhetjük azokat. Mivel ezek a Relation objektumok mindig létrehozáskor kapják meg a szükséges adatbázis kapcsolatot, az entitásnak magának nem kell az adatbázishoz kötődnie, amiről az előzőekben már írtam. Röviden tehát körülbelül ennyi.

Az eredmény tehát egy nagyon kompakt kis ORM rendszer. Jelenleg a MySQL-t és a Google App Engine Datastore-ját támogatja, de nagyon egyszerűen kiterjeszthető. Maga a kód nagyon egyszerű, áttekinthető és könnyen használható. Bár ennek a lehetőségét nem vizsgáltam meg mélyebben, de a csökkentett eszközkészletnek köszönhetően valószínűleg a datastore-on kívül más nem relációs adatbázisokra is alkalmazható lenne a rendszer, pl. MongoDB-re. A későbbiekben talán érdemes ezt az irányt is megvizsgálni. A programkönyvtár másik nagy előnye, hogy nagyon pici, így akár kódméret kritikus rendszerekben is használható lenne. A későbbiekben lehet, hogy készül Java, Python, esetleg C++ változatot, amit például mobiltelefonok programozásához lehetne használni.

A kód és néhány példa elérhető a Google Code-on a http://code.google.com/p/lworm/ címen.

gae-filestore (Írható/olvasható virtuális fájlrendszer Google AppEngine-re)

A Google AppEngine egyik elég erős megszorítása, hogy a telepített alkalmazás csak olvasni tudja a fájlrendszert. Új fájlokat nem hozhatunk létre, illetve nem módosíthatjuk a fájlokat. Bármilyen adattárolásra az AppEngine által biztosított adatbázist, a Datastore-t kell használnunk. Igazából ha jobban meggondoljuk, egy webalkalmazás többnyire valóban csak az adatbázist használja, így sokszor tényleg nincs szükség fájlrendszerre, de azért néha jól jön. Egy projektem kapcsán épp ilyesmire volt szükségem, ezért készítettem egy igazán egyszerű virtuális fájlrendszer implementációt Google AppEngine-hez. A rendszer működésének megértéséhez először írnék kicsit a Datastore-ról, annak is az alacsony szintű megvalósításáról.

Az AppEngine Datastore-ja egy BigTable alapú nem relációs adatbázis rendszer. Bár pontosan nem tudom, hogy a Google alkalmazások (GMail, Google Maps, a kereső, stb.) is ezt a megvalósítást használják-e, erről nem találtam konkrét leírást, de mindenesetre ez valami nagyon hasonló dolog kell hogy legyen. A rendszer használatára két lehetőségünk van. Egyfelől kapunk egy szabványos JPA/JDO réteget, így J2EE alkalmazásainkat változtatás nélkül, vagy kisebb változtatásokat követően futtathatjuk AppEngine-en. A másik lehetőség a low-level API használata, ami közvetlen hozzáférést biztosít a DataStore-hoz, így sokkal hatékonyabb, ugyanakkor kicsivel kényelmetlenebb is, mint a szabványos réteg. Én ez utóbbiról írnék kicsit bővebben. A Datastore adattárolásának alapja az Entity. A relációs adatbázis kezelőkhöz hasonlítva az Entity az adatbázis rekordnak felel meg, azzal a különbséggel, hogy az Entity-nek nincs fix szerkezete. Ebből a szempontból az Entity inkább olyan mint egy asszociatív tömb, vagy Java terminológiával élve Map. Egy ilyen Entity-be szabadon helyezhetünk el név-érték párokat. A másik nagyon fontos komponens a Key. A Key az entitás elsődleges azonosítója. A Key 3 féle módon épülhet fel. Generálhatjuk egy string-ből vagy long-ból, ezen felül definiálhatunk egy kulcs típust (kind), ami kb. a tábla megfelelője, és végül definiálhatjuk úgy a kulcsot, hogy ezeken felül egy szülő kulcsot is megadunk. Ez utóbbi megoldással a kulcsok és ezzel az Entity-k hierarchiába szervezhetőek. Ha összeállítottunk egy Entity-t, azt egyetlen metódussal lerakhatjuk a datastore-ra, és onnan a Key segítségével vissza is olvashatjuk. Amennyiben nem a Key alapján szeretnénk visszanyerni az entitást, úgy létre kell hoznunk egy Query-t. A Query segítségével az Entitás bármely értékére szűrhetünk az alapműveletek (kisebb, nagyobb, egyenlő, stb.) használatával. Az ilyen keresések segítésére definiálhatunk indexeket, de erre sincs feltétlenül szükség, hiszen a rendszer a lekérdezések alapján automatikusan legenerálja a szükséges indexeket. Az eredményként kapott entitás listát bármely eleme alapján rendezhetjük is, és nagyjából ennyi. Ha több entitást szeretnénk összekapcsolni (JOIN), VAGY kapcsolatot kialakítani a szűrési feltételekben, vagy bármi hasonlót tenni, amire egy relációs adatbázis amúgy önmagában képes, azt kódból kell megvalósítanunk. Cserébe viszont az egész rendszer masszívan elosztott, sémamentes, flexibilis és gyors. Most hogy megismertük a Datastore-t, lássuk a virtuális fájlrendszer működését.

A virtuális fájlrendszer legfelső szintű eleme a DataStoreFile entitás. Ezek az entitások testesítik meg az állományokat és a könyvtárakat egyaránt. Egy ilyen entitásnak 4 attribútuma van. A fájl típusa (könyvtár v. fájl), az utolsó módosítás ideje, a fájl mérete, és a fájlt tartalmazó útvonal. A fájl entitás egyedi azonosítója annak elérési útja, így ez alapján nagyon könnyen elérhetőek a fájl metaadatai. Mivel a metaadatokra sokszor szükség lehet, ezért a fájl entitás mentésekor és betöltésekor a memcache-ben is tároljuk, így annak további elérése már nagyon gyorsan megy a cache-ből. A fájl tényleges tartalmának tárolása Blob-okban történik. A Blob tulajdonképpen egy byte tömb, aminek mérete maximálisan 1 Mb lehet AppEngine esetén. Én 512 Kb méretű blokkokat használtam, amiket sorszámmal azonosít a rendszer. Az egyes blokkok a fájl entitás alatt helyezkednek el (a blokk kulcsa a fájl entitás kulcsának leszármazottja). Amikor adatokat írunk vagy olvasunk a fájlból, a rendszer a fájlmutató alapján meghatározza a blokk sorszámát ahol az adat van, majd ebben módosítja a megfelelő adatot. Egyszerű kialakítás, mégis kényelmes és hatékony.

A kód szokásos módon a Google Code-on megtalálható a http://code.google.com/p/gae-filestore/ címen.

PHP futtatása Googel App Engine-en

A GAE vagy Google App Engine a Google alkalmazás hoszting szolgáltatása. Nagy előnye, hogy segítségével alkalmazásunka a Google infrastruktúráján futtathatjuk. Nem kell olyan apróságokkal foglalkoznunk, mint a load balanceing, erőforrás allokáció, elosztott session kezelés, stb. hiszen a Google a terheléstől és a kérések helyétől függően optimálisan fogja "szétkenni" az alkalmazásunkat. Adatbázisként egy Google BigTable alapú nem relációs adatbázist kapunk, aminek klaszterezését ugyancsak a rendszer végzi automatikusan. E mellett kapunk még néhány "nyalánkságot", mint amilyen az elosztott memcache, e-mail, vagy xmpp lehetőség. Amiért azonban igazán vonzó lehet induló startup-ok számára, az az, hogy a rendszer körülbelül havi 1 000 000 lapletöltésig és 500 Gb tárhelyigényig teljesen ingyenes. Ha pedig az embernek sikerült ekkora forgalmat generálnia, akkor már jó eséllyel ki tudja termelni a plusz sávszélesség és tárhely árát is, ami néhány cent gigabájtonként, tehát igen baráti. Persze ezért a nagy kényelemért némi kompromisszumot is kénytelenek vagyunk meghozni. Az egyik ilyen korlát, ami véleményem szerint nagyban gátolja a technológia elterjedését, hogy egyenlőre csak Java és Python nyelven programozható. Az egyik talán leggyakoribb kérés szokott lenni a felhasználók felől, hogy más hoszting szolgáltatókhoz hasonlóan támogassák a PHP nyelvet is. Így megnyílna az út sok népszerű web framework, és PHP fejlesztő előtt. Ezt a dolgot viszont valamiért a Google nem annyira erőlteti. Bár a PHP hivatalosan nem támogatott, mégis viszonylag egyszerű módon futtathatunk PHP scripteket AppEngine felett.

A megoldás kulcsa a Caucho Quercus nevű Java Servlet alapú PHP implementáció, amely az App Engine-en való futtatást is támogatja. A gyakorlati megoldás sem olyan bonyolult. Töltsük le a legújabb resin verziót, és a resin.jar-t másoljuk a WEB-INF/lib könyvtárba. A web.xml-t bővítsük ki a következő bejegyzéssel:

  <servlet>
    <servlet-name>Quercus Servlet</servlet-name>
    <servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>Quercus Servlet</servlet-name>
    <url-pattern>*.php</url-pattern>
  </servlet-mapping>

Így a .php állományokat a Quercus automatikusan a QuercusServlet-nek továbbítja. Magukat a PHP állományokat a root könyvtárba helyezzük. Ezt követően az appengine-web.xml-hez adjuk hozzá a következő sorokat:

<static-files>
<exclude path="/**.php"/>
</static-files>
<resource-files>
<include path="/**.php"/>
</resource-files>

E nélkül a rendszer a php állományokat statikus fájloknak tekintené, és nem adná át a szervlet motornak. Körülbelül ennyi. Innentől kezdve már PHP-t is futtathatunk a Google App Engine-en. Ezzel a technikával elvileg sikeresen futtattak már Drupal-t, Wordpress-t, és néhány hasonló PHP keretrendszert. Persze azért a PHP alkalmazások szállítása nem olyan egyszerű, hiszen ezek többnyire MySQL-t használnak, AppEngine-en viszont ugye nincs relációs adatbázis. Tehát valamilyen szintű módosításra mindenképp szükség van, de ez talán megéri mindazokért az előnyökért cserébe, amit az AppEngine, és eleve maga a Quercus adhat (pl. egyszerű PHP-Java integráció, Java libek használata, stb.).