Manapság egyre jobban terjednek az úgynevezett NoSql adatbázisok. Több adatbázis gyártó cég különböző technikákat és technológiát alkalmaz. Érdemes azonban tudni, hogy a leginkább használható megoldásokra mind alkalmazható az úgynevezett CAP megközelítés. Ez három angol szó kezdőbetűjéből eredő mozaikszó. Nézzük meg mit is jelentenek:

• Consistency – Konzisztencia
  Az elosztott rendszereket képviselő minden egyes egységen (node) ugyanaz az adat érhető el
• Availability – Elérhetőség
  Minden egyes kérés feldolgozásra kerül és választ küld a rendszer
• Partition tolerance – Partíció tolerancia
  A rendszer működőképes marad, ha üzenetek vagy részegységek elérhetetlenné válnak

A fent említett funkciók közül általában kettőt szoktak kiválasztani a gyártók és azokat részesítik előnybe és így ezek határozzák meg, hogy az adott implementáció mire használható, miben igazán erős és mik lesznek a hátrányai. Ilyen jellegű dokumentációk elég jól kidolgozottak és könnyen hozzáférhetők. A NoSQL adatmodellezés kevésbé dokumentált, ezért itt egy kis alap feladatot oldunk meg. Kiválasztottam az egyik legnépszerűbb key-value (kulcs-érték) adatbázis a Redist. Nézzük meg, hogy hogyan állítunk össze egy adatbázist egy web alkalmazás támogatására. Feladat, hogy tároljuk a felhasználókat és az összes klikkelésüket.

1. Definiáljuk az objektumokat

Az első lépében azonosítanunk kell a fő objektumokat. A relációs adatmodellezésben ezek entitások, később táblák lesznek. Redisben más technikai objektumok vannak: sztringek, hashek, listák, stb. Mindenesetre a fizikai megvalósítástól függetlenül nevezzük el őket USER and CLICK objektumoknak. Elnevezési konvenciónk az lesz, hogy ezt fogjuk, minden hozzátartozó fizikai elem nevébe tenni.

2. Azonosítók

Mivel Redis egy key-value (kulcs-érték) adatbázis, ezért szükségünk van arra, hogy kijelöljük a kulcsokat. Ezek alapján fogjuk tárolni a hozzájuk tartozó értékeket. Demó feladatunk lényege, hogy tudjuk azonosítani a felhasználókat és hogy ki klikkelt. Tehát a két objektumunk között ez a kapcsolat. Azt az információt kaptuk a rendszer tervezőjétől, hogy a felhasználóknak az egyedi azonosítója a LOGIN_ID. Tehát ezt az információt a következő módon fogjuk tárolni:
USER:<LOGIN_ID>
Példa adattal szemléltetve: USER:100AB.
Ez eddig könnyű volt. Nézzük meg, hogy a CLICK objektumunkra milyen lehetőségeink vannak.

3. Elemezzük az összetett kulcsokat

A CLICK objektumunk alapvető feladata az lesz, hogy a tárolt adatokból pontosan meg tudjuk mondani, hogy ki, mire és hányszor kattintott. Ahhoz, hogy ezt az igényt ki tudjuk elégíteni a következő adat struktúrát kell alkalmazni.

CLICK:<LOGIN_ID>:<ELEMENT_ID>  
Példa adattal szemléltetve: CLICK:100AB:Button_Submit

4. Válasszuk ki a megfelelő struktúrát

Ahhoz, hogy ténylegesen tudjunk adatot tárolni az objektumainkban, ki kell választanunk a megfelelő implementációt. Jelen esetben a Redisben használható lehetőségek közül válasszuk az következőket: USER : hash (egy adott hash kulcshoz tároljuk egy vagy több értéket)

CLICK: string (egy kulcshoz egy szöveges értéket tárolunk)

Más adatbázis implementációknál, más lehet a fizikai választás. Hiszen más lehet az adatbázis erőssége, megoldásai.

5. Készítsünk egy működő modellt

Hozzuk létre a fent megtervezett két objektumot. HMSET paranccsal adunk értéket a USER objektumnak:

HMSET USER:100AB Name “John Doe” Email “john@doe.com” LastLogin “2015-05-05 05:05:05”

SET utasítással adunk értéket a CLICK objektumnak:

SET CLICK: 100AB:Button_Submit 1

Ahhoz, hogy tudjuk számolni a klikkeket, csak növelnünk kell a adott elem értékét a következő paranccsal:

INCR CLICK: 100AB:Button_Submit

NoSQL adatbázisoknak nem erőssége az aggregáció és egyéb statisztikai lekérdezések támogatása. Redis erre külön készült és nagyon könnyen meg lehet mondani, hogy például mi a 10 leggyakoribb klikk. Nézzünk néhány példát:

Top 10 klikkelt elem felhasználónkként:

Adat tárolása: ZINCRBY CLICK: 100AB 1 Button_Submit
Adat lekérdezése: ZREVRANGE CLICK: 100AB 0 9 WITHSCORES

Top 10 legtöbbet klikkelő felhasználó:

Adat tárolása: ZINCRBY CLICK:ActiveUsers 1 USER:100AB
Adat lekérdezése: ZREVRANGE CLICK:ActiveUsers 0 9 ->
                    HGET <result> Name -> “John Doe”

Itt látható az előrelátó tervezésünk, hogy milyen könnyen visszakapjuk a felhasználó nevét vagy egyéb tulajdonságát.

Úgy gondolom, hogy a NoSQL adatbázisok tervezésénél is a legfontosabb kezdő lépés, hogy elemezzük a követelményeket és ezeket átfordítsuk az adatbázis nyelvére. Utána jön a használandó adatbázis részleteinek a speciális ismerete. Mint összetett kulcsok, sharding, partíciók, fault tolerance, indexing, stb.

 További érdekes témák hírlevelünkben. Iratkozz fel!