Mik is ezek az újdonságok:

• Data Pipelinening
• továbbfejlesztett OpenSocial Templating
• OSML - OpenSocial Markup Language

Nézzünk is pár példát, hogy miben egyszerűsödik az életünk:

Proxied Content

Sokan nem szerették, hogy a gadget.xml hordozza magában az alkalmazás alap megjelenését (különböző view-k html fragmentjét). Mostantól azonban lehetőség van arra, hogy az OpenSocial konténert egyszerűen, proxy megoldással emelje be ezeket a tartalmakat is:

1
2

<Content view="canvas" href="http://myserver/canvas">
</Content>

Itt annyi történik, hogy a CANVAS nézet meghívásakor a gadget szerver a http://myserver/canvas címen található html-t tölti be, ami természetesen továbbra is keresztül megy a gadget szerver rewrite/cache/stb. mechanizmusain. Ezzel még sokat nem nyertünk, egyedül a fejlesztésünk hatékonyságán javítottunk kicsit. Azonban csavarjunk a dolgon egy kicsit:

1
2

<Content view="canvas" href="http://myserver/canvas" authz="signed">
</Content>

Ezzel a kóddal egy apró csavart raktunk a kiszolgálási mechanizmusba, miszerint a http://myserver/canvas meghívása SignedRequest módon történik, tehát a saját kódunk már pontos információkkal rendelkezik az @owner és @viewer azonosítóiról.
Természetesen itt egy dologra figyelnünk kell, ahogy SignedRequest módba váltunk kiütjük az OpenSocial container cache megoldásait, tehát itt már bírnunk kell szerveroldalon a felhasználók által jövő lekérdezéseket!

Data Pipelinening
Az OpenSocial két féle lehetőséget biztosít nekünk az adott konténer social api-jának elérésére, az egyik a felhasználók böngészőjén keresztül egyszeráen elérhető rpc protokol, a másik pedig a szerveroldali restful interfész (utóbbi az iWiW-en belül egyelőre nem hozzáférhető). A böngészőben futó rpc hívásoknak sok hátránya van, sok esetben a felhasználónak az akár elég lassú internetkapcsolatán keresztül kell nagy adatokat megmozgatni a gadget betöltődése után. Azonban mostantól lehetőség van arra, hogy a felhasználó a renderelt gadgetet már a social adatokkal együtt kaphassa meg.

Nézzük is a példát:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
        <ModulePrefs title="OpenSocial 0.9 Teszt"
                title_url="http://myserver"
                author="Bányai Zsolt [bazso]"
                author_email="banyai.zsolt@virgo.hu"
                description="Teszteljük az ópenszósölt!">
                <Require feature="opensocial-0.9" />
                <Require feature="opensocial-data"/>
        </ModulePrefs>
        <Content type="html" view="canvas"><![CDATA[
           <script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data">
              <os:PeopleRequest key="vf" userId="@viewer" groupId="@friends"/>
              <os:ViewerRequest key="viewer"/>
           </script>
        ]]></Content>
</Module>

Mi történt itt? Először is a <Require feature=”opensocial-data”/> sorral jeleztük, hogy használni szeretnénk az OpenSocial Data Pipelining megoldását. A Gadget szerver a renderelési fázisban látja, hogy két adatlekérdezést is szeretnénk (viewer ismerőseinek lekérdezése, valamint magának a viewernek a lekérdezése), ezeket megfuttatja az API szervereken és az eredmény elérhetővé válik a renderelt gadget html kódjában:

1

<script type="text/javascript">opensocial.data.DataContext.putDataSet("viewer",{"hasApp":true,"thumbnailUrl":"http://approval.iwiw.hu/rest/person/HkVD909RD.jpg","name":{"formatted":"Bányai Zsolt","givenName":"Zsolt","familyName":"Bányai"},"profileUrl":"http://approval.iwiw.hu/rest/person/HkVD909RD.html","isOwner":true,"id":"approval.iwiw.hu:HkVD909RD","isViewer":true,"displayName":"Bányai Zsolt"});opensocial.data.DataContext.putDataSet("vf",{"list":[{"hasApp":true,"thumbnailUrl":"http://approval.iwiw.hu/rest/person/m8VhWkg8.jpg","name":{"formatted":"iWiW Root User","givenName":"User","familyName":"iWiW Root"},"profileUrl":"http://approval.iwiw.hu/rest/person/m8VhWkg8.html","id":"approval.iwiw.hu:m8VhWkg8","displayName":"iWiW Root User"},{"hasApp":false,"thumbnailUrl":"http://approval.iwiw.hu/rest/person/4pVS21R42.jpg","name":{"formatted":"Elfogadó Dezső","givenName":"Dezső","familyName":"Elfogadó"},"profileUrl":"http://approval.iwiw.hu/rest/person/4pVS21R42.html","id":"approval.iwiw.hu:4pVS21R42","displayName":"Elfogadó Dezső"}],"startIndex":0,"totalResults":2});</script>

Elsőre ugye nem szép, azonban felettébb hasznos megoldás, hiszen nincs szükségünk már kliens oldali hívásokra, ezek az információk azonna elérhetőek JavaScript segítségével:

1
2

var viewer = opensocial.data.getContext().getDataSet('viewer');
var viewerFriends = opensocial.data.getContext().getDataSet('vf');

OpenSocial Templating
Az előző példa elég meggyőző, azonban a fejlesztő még mindig nem szabadulhat a JavaScript mágiától. Ebben segítség az OpenSocal Templating, amely szerver és kliens oldalon egyaránt futtatható template lehetőséget biztosít, akár saját magunk által definiált template-ekkel.

Kicsit egészítsük ki az előző példát, és rögtön megvilágosodhatunk:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
        <ModulePrefs title="OpenSocial 0.9 Teszt"
                title_url="http://myserver"
                author="Bányai Zsolt [bazso]"
                author_email="banyai.zsolt@virgo.hu"
                description="Teszteljük az ópenszósölt!">
                <Require feature="opensocial-0.9" />
                <Require feature="opensocial-data"/>
                <Require feature="opensocial-templates"/>
        </ModulePrefs>
        <Content type="html" view="canvas"><![CDATA[
           <script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data">
              <os:PeopleRequest key="vf" userId="@viewer" groupId="@friends"/>
              <os:ViewerRequest key="viewer"/>
           </script>
           <script type="text/os-template">
               <strong>${viewer.name.formatted} ismerősei:</strong>
               <ul>
                  <li repeat="${vf}">${name.formatted}</li>
               </ul>
           </script>
        ]]></Content>
</Module>

A példában nem tettünk mást, mint a gadget szerverrel szerver oldalon futtattatunk egy egyszerű template-et, amely segítségével a már előzőekben elérhető adatokat JavaScript mutyizás nélkül szépen html formában megjeleníthetjük, a következő eredményt kapva a renderelt gadgetünkben:

1
2
3
4
5

<strong>Bányai Zsolt ismerősei:</strong>
<ul>
   <li>iWiW Root User</li>
   <li>Elfogadó Dezső</li>
</ul>

Egy kis nyalánkság
Bár eddig csak ízelítőt kaphattunk az újdonságokból, azért egy dolgot még körbejárunk. Sokszor előfordul, hogy a felhasználónak a kapcsolati hálója alapján szűrve szeretnénk tartalmat visszaadni, de körülményes dolog megjáratni az adatokat a böngésző és a szerverek között. Ehhez a fenti példákat kicsit összemixelve kapunk egy nagyon hasznos megoldást. Csapjunk rögtön a lovak közé:

1
2
3

<Content view="canvas" href="http://myserver/canvas" authz="signed"  xmlns:os="http://ns.opensocial.org/2008/markup">
   <os:PeopleRequest key="vf" userId="@viewer" groupId="@friends" />
</Content>

No, lássuk mire megyünk ezzel a bűvészkedéssel. Külön-külön már tudjuk értelmezni ezeket a sorokat, azaz látjuk, hogy egyszer a gadget szerver SignedRequest alkalmazásával bekéri saját szerverünktől a gadget html tartalmát, valamint az is tudjuk, hogy az os:PeopleRequest előkészíti nekünk a @viewer ismerőseit. De hogy ér össze a kettő, merül fel a kérdés… Jelen esetben a sorrend megfordul, a gadget szerver lekérdezi a @viewer ismerőseit, majd az eredményt POST-olja a canvas nézet megjelenítéséért felelős oldalunknak, ráadásul úgy, hogy közben megbizonyosodhatunk a SignedRequest segítségével arról is, hogy valóban az iWiW-től érkezett a kérés. Íme az egyszerű szerveroldali php kód - a SignedRequest feldolgozása nélkül -, amely segítségével már dolgozhatjuk is fel az adatokat:

1
2
3
4
5

$data = file_get_contents("php://input");
 $my = json_decode($data);
 foreach ($my[0]->data->list as $d) {
        print $d->name->formatted."<br />";
 }

Konklúzió
Látszódik, hogy az OpenSocial szabvány keresi azokat az utakat, amelyek segítségével a fejlesztők számára kényelmesebbé és JavaScript-függetlenebbé válhat a fejlesztés, ezzel igyekezve felzárkózni a Facebook sokak által kényelmesebbnek ítélt platformja mögé.
Aki a fentiekről bővebben akar tájékozódni, az olvasgassa a http://opensocial.org oldalain található dokumentációkat, aki pedig arra kíváncsi, hogy az újdonságok mikor és milyen formában lesznek az iWiW-en is elérhetőek, az kövesse @iwiwdevet, valamint kísérje figyelemmel az iWiW Fejlesztői Blogot.

Idén a kliens oldali fejlesztés megkönnyítéséhez sikerült két ilyen összetevőt találni. Ezekből az egyik a Haml, amely egy indentáláson alapuló HTML és XML kód generálására használható nyelv. A másik pedig ennek a párja a Sass, amely hasonlóan CSS kód generálására használható. Mindkettőnek egyik nagy előnye a sima HTML/CSS illetve a HTML-hez Ruby világban hagyományosan használt ERB-vel szemben, hogy sokkal kevesebb a kódban a sallang és az ismétlődés (DRY). Emelett persze sok további előnnyel rendelkeznek. Haml esetében a szép kimenetet és a filterekkel való kiterjeszthetőséget emelném ki, Sass esetében pedig a konstansok és egyszerű műveletek használatát, illetve a css mixineket.

A Sass oldalhoz még a Compass keretrendszert is bevetettük, ami sok hasznos mixint definiál nekünk előre illetve a népszerűbb CSS frameworkökhöz (YUI, Blueprint, stb.) is ad rugalmasan használható Sass átiratot.

Próbáljátok ki, nekünk bevált! Ha esetleg mélyebben érdekelnek az előnyök, és hogy mi hogyan működik, akkor ajánlom figyelmedbe a bevezetés előtt tartott belső traininghez készült előadás slidejaimat:

Backend elérés

A backend oldallal való kommunikációra a gadgets.io.makeRequest függvény ad lehetőséget. Ez alapvetően egy proxyzott cross-domain ajax requestként működik, ahol kérhetjük azt is, hogy a kérés alá legyen írva. A nem aláírt esetben sok különlegességet ne várjunk szerver oldalon, szinte teljesen ugyanolyan, mint egy átlagos ajax request. Arra viszont érdemes figyelni, hogy a sessionkezelés nem fog működni utánajárás nélkül. Emiatt a Rails beépített CSRF védelme sem fog működni, de mint látni fogjuk, ez nem is probléma, hiszen a signed requestek megfelelő védelmet nyújtanak.

Aláírt lekérésre kétféle lehetőségünk van. Az egyik a signed request használata. Ebben az esetben a OpenSocial konténer a request paraméterekből egy privát kulcs vagy megosztott titok segítségével képez egy ellenőrző összeget. Ez alapján a távoli szerver tudni fogja, hogy valóban a várt helyről érkezik a kérés. Az aláírt paraméterek között szerepel az alkalmazás azonosító, és a viewer és az owner felhasználó azonosítója is. A lekérés a kulcs ismerete nélkül nem hamisítható, így biztosak lehetünk benne, hogy a kérést valóban az OpenSocial konténer küldte és a megadott adatok valódiak. Ebből már látható, hogy ez megfelelő CSRF védelmet nyújt, ezért ajánlatos minden nem GET requestnél a signed requestek használata.

A másik lehetőség az oauth használata, ahol az aláírás ugyanígy működik, de a request folyamat bonyolultabb, mert egy autentikációs lépést is tartalmaz. Ezt akkor érdemes használni, ha egy OpenSocial profilt össze akarunk kötni egy backend oldalon autentikációt igénylő saját felhasználónkkal. Erről a témáról bővebben majd egy későbbi bejegyzésben lesz szó.

Signed requestek ellenőrzése

A signed requestekről már volt szó az iWiW fejlesztői blogon, ott érdemes esetleg utánaolvasni a kliens oldali részleteknek. A fejlesztői blog bejegyzésének kommentjeiben előkerült egy rubys probléma is, ami a signed requestek ellenőrzésekor jön elő.

A signed requestek ellenőrzéséhez Rubyban az oauth gemre lesz szükség. A gem jelenlegi verziójában van egy bug, ami miatt a request paraméterek túl sokszor lesznek escape-elve az ellenőrző kód számításakor, és emiatt az ellenőrző kód hibás lesz. Hivatalos javítás még nincs, de már többen is megoldották a problémát a GitHubos forkokban. A javítás a gem általam forkolt verzióban is elérhető, és ez a verzió tartalmaz egy Rails Edge kompatibilitás fixet is. Ajánlom, hogy innen telepítsétek a gemet, amíg az új verzióval ki nem jön a hivatalos javítás. (Pull request ment, és úgy tűnik most kezd feléledni a fejlesztői lista, úgyhogy van remény.)

A githubról telepítéshez segédlet:

$ git clone git://github.com/lackac/oauth.git
$ cd oauth
$ rake gem
$ sudo gem install pkg/oauth-0.2.7.gem

Introducing gadgeteer

Az ellenőrzési folyamat és gadget backend fejlesztés megkönnyítésére házon belül készítettünk egy Rails plugint, ami igyekszik minél több terhet levenni a fejlesztő válláról. A plugin neve gadgeteer, és MIT licensz alatt elérhető a GitHub-on.

Telepítés:

$ script/plugin install git://github.com/virgo/gadgeteer.git

A plugin három dologban nyújt jelenleg segítséget. A kulcsokat teszi könnyen konfigurálhatóvá, a bejövő kérések ellenőrzését teszi egyszerűvé, és a konténertől kapott OpenSocial specifikus paramétereket teszi könnyen elérhetővé.

Kulcsok

A kulcsokat kétféleképpen lehet tárolni. A config könyvtár alatt, vagy valamelyik kontrollerben (célszerűen az ApplicationController-ben) konfigurálva.

Publikus kulcsok esetében a config/certs könyvtár alá kell berakni .cert kiterjesztésű fájlokat, vagy a kontrollerben a public_keys hash-be kell felvenni a megfelelő kulcsot a OpenSSL::PKey::RSA osztály egy példányaként. A gadgeteer a megfelelő kulcsot a xoauth_signature_publickey request paraméter alapján választja ki (iWiW esetében ennek értéke ‘iwiw.hu’).

Megosztott titok esetében a consumer_key/consumer_secret párosokat a config/oauth_secrets.yml fájlban lehet megadni, vagy közvetlenül a kontrollerben az oauth_secrets hash-be kell felvenni.

Ellenőrzés

A bejövő lekérések ellenőrzését a verify_signature metódussal végezhetjük. Ezt akár közvetlenül megadhatjuk egy before_filter-ben is. Az implementáció gondoskodik a megfelelő kulcs kiválasztásáról, és a megfelelő metódus segítségével ellenőrzi az aláírást.

OpenSocial paraméterek elérése

Signed request esetében kapunk pár hasznos paramétert, amiket a konténer ‘opensocial_’ előtaggal lát el. Ezeket persze el tudjuk érni a params metódus segítségével is, de a gadgeteer plugin ad erre egy kézenfekvőbb metódust, aminek open_social a neve. Így például a viewer azonosítója open_social[:viewer_id], az alkalmazás azonosítója pedig open_social[:app_id] lesz. Ezen túl bekerülnek még az ‘os_’ kezdetű paraméterek is, hogy lehetőség legyen a kliens oldal által további OpenSocial specifikus paramétereket is ide csoportosítani. (Például kliens oldalon lekérhetünk további adatokat a viewer-ről és továbbadhatjuk a backend-nek ‘os_viewer_*’ paraméterekben.)

A projekt README-ben található példakódok még világosabbá teszik a fentieket.

További tervek

A plugint szeretnénk tovább bővíteni hasznos dolgokkal, amelyek a kisalkalmazások fejlesztése közben előjönnek. Nyitottak vagyunk további javaslatok felé is, de nem ígérhetjük, hogy minden felmerülő ötletet megvalósítunk. Örömmel fogadjuk viszont, ha GitHubon keresztül küldtök pull requestet azokról a dolgokról, amelyekkel ti bővítitek a plugint.

Ilyen esetekben jöhet szóba valamiféle sharding megoldás, más néven horizontális particionálás. Az ilyen megoldások lényege, hogy az adatokat fizikailag külön adatbázisban tároljuk. A szükséges adatokat az egyes shardokról külön-külön visszanyerjük, majd elvégezzük az esetleges utófeldolgozást (pl.: a különböző shard-okról származó adatok rendezése). Itt rögtön meg is mutatkozik, hogy mikor nem jó a sharding technológia: ha az utófeldolgozás túl költséges.

A sharding-ot legtöbbször alkalmazás szinten valósítjuk meg, bár vannak alacsonyabb szintű kezdeményezések is, például a MySQL Proxy-n alapuló HScale. Ezektől most tekintsünk el, és nézzük, milyen lehetőségeink vannak alkalmazás oldalon. A környezet, amiben dolgozunk: Java 1.5, JPA, Hibernate, MySQL. Hibernate-hez van egy „dobozolt” sharding megoldás, a Hibernate Shards. Ez még béta állapotban van, de nagyon ígéretes. Azért érdemes elolvasni a „Limitations” fejezetet, és figyelni arra, hogy csak akkor lehet eredményesen használni, ha már a tervezésnél figyelembe vesszük, hogy shard-olt adatbázissal fogunk dolgozni. A Shards ugyan rengeteg dolgot megold utófeldolgozással, de ez legtöbbször performancia okokból nem vállalható. Az egyetlen járható út, ha már a tervezés során úgy építjük fel az alkalmazásunkat, hogy elkerüljük a költséges utófeldolgozások szükségességét!

Amiért nem a Shards-ot választottuk, annak két fő oka volt:

• Shard-onként külön SessionFactory-t használ, ami elég nagy erőforrást emészt fel, ráadásul kényelmetlenné teszi a konfigurálást. (A Google saját bevallása szerint körülbelül 10 shard-ig eredményes.)
• Mi JPA-n keresztül szeretnénk használni a Hibernate-et, míg a Shards leginkább a Criteria API-ra van kihegyezve

A mi ötletünk lényege az volt, hogy a SessionFactory-nál mélyebb szinten, a ConnectionProvider interfészen keresztül avatkozunk be. A Hibernate ezen az interfészen keresztül kér el a JDBC connection-öket. Ha itt mindig a megfelelő shard-hoz tartozó connection-t adunk vissza, akkor az egyes műveletek a megfelelő adatbázisszerveren hajtódnak végre. Erőforrásban így shard-onként csak a ConnectionPool-ok többszöröződnek, ami nem kis költség, de nehezen megúszható. Másrészt a sharding miatt egy pool-ban kevesebb connection-lesz a szokásosnál, így kevesebb memóriát emészt fel, és a karbantartó szálakon is spórolhatunk.

A konfigolhatóság egyszerű lesz, hisz a Hibernate által használt ConnectionProvider-t egyszerűen megadhatjuk a szabványos hibernate.connection.provider_class tulajdonságon keresztül (ahogy a ConnectionPool-t is), az egyes shard-okhoz tartozó beállításoknál pedig megtartjuk a Hibernate-es kulcsokat, azzal a megkötéssel, hogy mindegyik elé egy virgo.shard.<SHARD-NEVE>. prefix kerül, és ezt a saját Provider-ünkben fordítjuk vissza a hibernate-nek megfelelő formába. Ezt meg lehet még spékelni default érték kezeléssel (virgo.shard.DEFAULT. prefixű paraméterek minden shard-ra igazak, ha ott nincsenek megadva), hisz shard-onként rengeteg közös paraméter lesz – általában csak a connection url más. Így shard-onként egy plusz konfig sorral elintézhető a beállítás.

Két problémát kellett megoldanunk:

1. Az alkalmazás csak olyan műveleteket hajthat végre, amik csak egyetlen shard-ra vonatkoznak. Minden más műveletet felsőbb rétegben szét kell bontani shard-onkénti műveletekre.
2. A felsőbb szinten valahogy jelezni kell, hogy melyik Shard-on is kell végrehajtani az adott műveletet.

Az 1. pont igen nagy megkötésnek tűnik, azonban éles helyzetben nem igen képzelhető el, hogy olyan lekérdezések futnak, amik több – esetleg minden – shard-ot érintenek, ekkor ugyanis nem sokat nyerünk a sharding-gal. Ebben az esetben valószínű érdemesebb más terheléselosztást választani, esetleg más szisztéma szerint shard-olni. Ha néhány ilyen helyzet mégis előfordul, akkor könnyű rá valamiféle JPA kompatibilis, újrafelhasználható megoldást írni, például QueryBuilder-ek / speciális Shard-olt Query implementációk formájában. Általános megoldás egyébként sincs, ugyanis alacsony szinten egy összetettebb lekérdezésnél igen nehéz eldönteni, hogy mit is akart a hívó. (A Hibernate Shards is korlátozott képességekkel rendelkezik ezen a téren.)

A mi esetünkben nem is volt olyan olvasó művelet, amikor több shard-hoz kellett nyúlni. Író műveletünk volt, ott egy bulk insert-et kiadó QueryBuilder-t valósítottunk meg, ami előbb memóriában összegyűjti a beszúrandó adatokat shard-onként, majd egyesével elküldi őket. Itt problémás a hibakezelés: mi van, ha az n-edik shard tranzakciója nem sikerül? Mi amellett döntöttünk, hogy a query objektum visszaadja a sikertelen rekordokat, ezek egy hibasorra kerülnek, és később újra megpróbáljuk a feldolgozást.

A 2. problémára adott megoldások igazából egy dologra épülhetnek,mivel a ConnectionProvider getConnection() metódusa nem kap paramétereket, így a hívóval csak ThreadLocal-on keresztül kommunikálhat. Arra persze már több lehetőség kínálkozik, hogy ezt a ThreadLocal-t hogyan állítjuk be. Mi egy JPA metodikába illő megoldást kerestünk, a következőt választottuk. Az EntityManager interfészt kiterjesztettük ShardedEntityManager néhány shard-kezelő metódussal, például:

Látható, hogy az egyes entity-khez tartozó shard kiválasztását (resolveShard) és az aktuális shard beállítását (setCurrentShard) külön metódusba tettük. Így lehetséges, hogy eltároljuk a shard nevét, megspórolva a resolve költségét, illetve van lehetőség iterálni az összes shard-on. Annak a leprogramozása, hogy az egyes Entity-khez milyen shard-ok tartoznak egy külön osztályba került, ezt PersistenceUnit-onként egyszer kell megtenni.

Egy statikus metóduson keresztül ­– ShardManager.extend(EntityManager em) –tetszőleges EntityManager kiterjeszthető ShardedEntityManager-ré, ezért került bevezetésre az isSharded() metódus, ami nem shard-olt esetben false-t ad vissza.

A shard-olt eset az érdekesebb, ilyenkor ugyanis nem elég, hogy a visszaadott manager a setCurrentShard metódusban átállítja a ThreadLocal értékét, hiszen ha egy szál esetleg több EntityManager-t használ felváltva, akkor függetlenül a sorrendtől az egyes manager-eknek a rajtuk beállított shard-hoz kell menniük. Ezért egy olyan EntityManager kerül visszaadásra, ami wrap-eli a kapott EntityManager-t, és az eredeti metódusok hívása előtt mindig beállítja az adott manager aktuális shard-ját a ThreadLocal-ban. Mi ezt a wrap-elést CGLib-en keresztüli proxy-zással valósítottuk meg, de meg lehet írni a wrapper osztályt kézzel is.

Megjegyzések:

1. A shard-ok szerinti connection visszaadás nem okoz gondot a 2nd level cache-ben, hisz a shard-ok diszjunktak, az id-k globálisan egyedik.
2. Nem szóltunk az id generálás problémáiról, mivel ez nem tartozik szorosan a témához, de garantálni kell, hogy globálisan egyedi id-k kerülnek kiosztásra. Erre több lehetőség kínálkozik:
   • globális szekvenciából / táblából – pool-ozva – osztjuk az id-t
   • lokálisan osztjuk, de úgy, hogy globálisan egyedi legyen (pl.: <shard-index> + N * <shardok-száma>, ahol N=1, 2, …)
   • összetett kulcs (shard + lokális id)
3. A kézi shard állítás automatizálásán is gondolkodtunk, több ötletünk is volt, de egy olyan sem, ami elég általános, és valódi haszonnal járó lett volna. Ami nekünk eszünkbe jutott:
   • ha shard-olt entity-vel hívunk persist(), merge(), stb. metódust, akkor a shard automatikusan állítódjon be.
   • findEntity(@Shard(class=Entity.class) int primaryKey)
   • A fenti üzleti metódus esetén az aktuális Shard beállítódik a class, és primaryKey által meghatározott entity-nek megfelelőre.
4. Természetesen a query-k „shard-osításán” is gondolkodtunk, de ennek általános megoldása túl nagy falat – nem is volt cél –, és performancia szempontból sem tűnik jó útnak. Egy egyszerű példa: már egy query Order By feltételének megfelelő Comparator elkészítése, amivel ugyanaz a rendezés a memóriában elvégezhető sem egyszerű. (Nem is beszélve arról, ha az oszlop, ami szerint rendezünk, nem is szerepel a visszaadott mező listában; a lokalizációs problémákról, stb.)

Először mi is meglepődtünk, mikor a Sun megkeresett minket, hogy egy BI konferencián kellene MySQL előadást tartani. Már csak azért is, mert BI és DW területen nem kifejezetten elterjedt a MySQL. Gyors telefonos egyeztetés a szervezővel. Szerinte elég aktuális a téma, ha már távközlési cégek is keresnek Magyarországon MySQL adattárház szakértőt. A BI területről jövő résztvevőknek valószínű nem lesz ismerős a MySQL, legyen szó adattárházakról és új dolgokról is, 40 percbe férjen bele. Ez volt tegnap.

A MySQL a cserélhető storage engine architektúra miatt jól testreszabható célfeladatokra egy storage engine cserével. Egy adattárházas storage engine-t onnan lehet megismerni, hogy nem sor, hanem oszlop alapon tárol. Ez elég sok optimalizációra ad lehetőséget, a legtriviálisabb az, hogy tömöríteni jobban lehet (mert egy oszlopban ugyanolyan típusú adatok vannak).

A MySQL és a Falcon engine újdonságait már valószinűleg hallotta előtte is a közönség, ha voltak Oracle 7 vagy 8 újdonságok előadáson. Ez így elsőre viccesnek hat, de ahhoz képest, hogy CRUD adatbáziskezelőnek indult, már támogat tranzakciókat, nézeteket, és triggereket.

Az előadás után többen érdeklődtek a MySQL-ről (főleg az enterpriseról) meg arról, hogy mi milyen esetben milyen adatbáziskezelőt használnánk. Szerintünk sikerült annyira jól, hogy rögtön ide is teszem a prezentációt, hogy le lehessen tölteni. ]]> http://www.virgo.hu/undercode/2008/11/mysql-eloadas-az-opensource-bi-konferencian/feed/