A Szabad Szoftver Konferencián előadott prezentációm célja a Redis nevű, memória alapú key-value adatbázis lehetőségeinek bemutatása volt. Számos hasonló projekt létezik, melyekkel összehasonlítani nem fért bele sem ennek a blogbejegyzésnek, sem az előadásom kereteibe, mindazonáltal megpróbálok egy képet adni arról is, hogy milyen egyéb lehetőségek vannak.
Frissítés #1: Íme az előadásom fóliái (kicsit más infókat tartalmaznak, mint az alábbi írás, például azt is, hogy milyen lehetőségek lesznek az 1.1-es, illetve jövőbeli Redisekben:
Először a key-value adatbázisokról lesz szó, majd arról beszélek, hogy milyen gondolatiság van ennek a filozófiának az újbóli fellángolása mögött, és miért is aktuális ez a téma manapság, miért célszerű megismernünk minél több lehetőséget ezirányban. A bejegyzés másik felében pedig a Redis lehetőségeit mutatom be a funkcióitól a backupolási lehetőségekig, s szó lesz majd egy esettanulmány jellegű rész keretében arról is, hogy milyen gondolkodásmóddal tudjuk hatékony módon kihasználni a Redis, illetve a hasonló projektek lehetőségeit.
NoSQL, key-value adatbázisok
Egyre divatosabbnak számít manapság adatbázisok oly módon történő megvalósítása, ahol az SQL lekérdezőnyelv nem játszik szerepet. A NoSQL “mozgalom” mögött az a gondolatiság rejtőzik, hogy minél egyszerűbb eszközökkel, minél terhelhetőbb, skálázható, illetve stabil adattárolást valósítsunk meg. A relációs adatbázisok ugyan nagyon sok problémára választ kínálnak, de ez bonyolultságot hoz, s ebből adódóan vesztik el rugalmasságukat, illetve ez az, ami sebességük kárára is válik. Azzal együtt, hogy a bonyolultságból visszavéve, egyszerű adatbázis sémákkal dolgozva gyors megoldások építhetőek relációs modellben is, vannak olyan céleszközök, melyeket nem lehet csak egy kézlegyintéssel elintézni.
Az igényt a nagy látogatottságú, terhelt webes szolgáltatások, a “cloud” témaköre hozta, ebből az irányból származnak azok az elvárások, melyek például a MySQL egyszerűsítését zászlajára tűző Drizzle projekt születését is lehetővé tették, illetve hoztak képbe, tesznek populárissá olyan technológiákat, melyeknek már régóta birtokában vagyunk, de kevésbé használtuk őket szélesebb körben.
A key-value adatbázis fogalma nem mai találmány, sőt, az egyik legegyszerűbb adatmodellről van szó, melyet az összes programozó ismerhet. A legtöbb modern programozási nyelvben jelen levő hashek, asszociatív tömbök, szótárak ezt az adattárolást valósítják meg. A key-value adattárolás lényege, hogy az adatbázis tartalma úgynevezett kulcsok segítségével hozzáférhető, a kulcsokhoz jellemzően egyszerű adatstruktúrával rendelkező értékeket párosítva. Az adatbázis tartalma semmilyen más módon nem kérdezhető le, alap esetben nem tudunk szűrni, rendezni adatokat, csak és kizárólag a kulcsok jelentik a hozzáférési pontot, melyek segítségével viszont nagyon gyorsan férhetünk hozzá a hozzárendelt információhoz. A képet persze árnyalja, hogy egyes megvalósítások – így az előadásom témáját adó Redis is – ezt kiegészíti különböző irányokban, ezáltal bizonyos feladatokra, problémákra hatékony megoldást kínálva a több szereplőhöz képest.
A key-value reneszánszát könnyű lenne elintézni úgy, hogy csak egy újabb hype-ról van szó, de alapvetően inkább egy tudatosabb, céleszközökkel dolgozó, a nagyobb látogatottságot hatékonyabban kiszolgálni akaró, illetve olyan funkciók megvalósítását lehetővé tenni akaró internet korszakába léptünk, melyekre jó választ ad ez a technológia (többek között). A key-value megoldást használó szerverek pedig gombamódra válnak nyílt forráskódú projektek keretében elérhetővé, így rendkívül olcsó és jól használható megoldást adva a webfejlesztők, szolgáltatás fejlesztők kezébe – azzal együtt, hogy bőven van még mindig olyan terület, ahol a hagyományos relációs modell sokkal jobb, hatékonyabb megoldást kínál.
Redis
Az előadásom címében a Redist memcached gyilkosnak neveztem, mivel számos tekintetben többet nyújt annál úgy, hogy megtartja annak előnyeit is.
A Redis egy key-value adattárolást megvalósító, az adatokat memóriában tároló, de perzisztensen háttértárra írni képes, az értékek tekintetében nem csak egyszerű sztringeket, de összetettebb listákat, halmazokat atomi műveletekkel is támogatottan megvalósító adatbázis, mely replikációra is képes.
Rendkívül dinamikusan fejlődő projektről van szó, mely pár hónap alatt jutott el az 1.0-s kiadásig úgy, hogy már korábban is stabilan használható megoldást kínált. Hamarosan várható az 1.1-es kiadás is, mely további újdonságokkal, lehetőségekkel szolgál. A projekt igen jól dokumentált, számos programozási nyelven érhető el kliens szoftver hozzá.
A key-value adattárolás mivoltát az előzőekben már tisztáztam, de nézzük, hogy a többi funkció mit is jelent. A Redis a memóriában tárolja az összes adatot, amiből egyenesen következik az is, hogy maximum annyi információt tudunk segítségével letárolni, amennyi belefér a szerver memóriájába. Mivel járulékos információk is letárolásra kerülnek, ezért figyelembe kell venni, hogy 1 GB memóriába nem tudunk 1 GB-nyi adatot letárolni, csak kevesebbet. A pontos overhead jelentősen függ attól, hogy milyen adatokkal dolgozunk, a Redis FAQ-jában olvasható példa szerint rossz esetben akár 84%-os veszteséget is jelenthetnek a különböző indexek (ez egy elég elrettentő szám, ennél sokkal jobb százalékok is kihozhatóak, mivel duplikált értékeket képes felismerni a Redis, illetve az értékeket tömöríteni is tudja), persze ez korántsem a jellemző arány, sokkal inkább a 10-20% overhead a jelemző.
A Redis az adatokat képes a háttértárra is kiírni, ezáltal perzisztens adattárolást megvalósítva. Az adatok kiírásának folyamata jól hangolható, megadhatunk intervallumot (pl. 5 percenként), írások számát (pl. minden 10.000 írás) is, de mindezeket vegyesen is be lehet állítani. Adat kiírást kezdeményezni lehet menet közben is bármikor. Az adatok kiírása közben a szerver kiszolgálja a kéréseket, nem áll meg, de a háttértárra kiírt adathalmaz konzisztens marad, s a kiírás kezdeti pillanatának állapotát tartalmazza.
Az összetett adattárolást illetően nem csak sztringek tárolhatóak el a Redis adatbázisában értékként, hanem támogatva vannak a listák és a halmazok is. Ez azt jelenti, hogy listákhoz, halmazokhoz különböző műveletek segítségével atomi módon tudunk például hozzáadni vagy lekérdezni elemeket, s ezekhez különböző parancsokat is kapunk (lásd később). További adatszerkezetek is tervbe vannak véve a Redis következő verziójának megjelenésével.
Ami a replikációt illeti, a Redis több szerver között is fenn tud tartani konzisztens adat állapotot. A replikációhoz szükséges szinkronizálást önállóan, beavatkozás nélkül képes beindítani, illetve fenntartani.
A Redis ezeket a funkciókat nagyon gyorsan képes kivitelezni, másodpercenként százezer feletti írásműveletet, illetve százezerhez közeli olvasási műveletet lehet megvalósítani a segítségével egy átlagos szerveren. Ami a konfigurálást, telepítést illeti, nagyon gyorsan, szinte nulla konfigurációval üzembe állítható a szerver szinte fapados módon, és egyből tesztelhető, kipróbálható. A parancsai egyszerűek, s gyorsan tanulhatóak, s egy kiváló, stabil eszközt ismerhetünk meg egy rövid ismerkedés során.
Hasonló projektek
Ami a memcached-del történő összehasonlítást illeti, az eddig leírtakból talán látható, hogy miben nyújt a Redis többet a Memcached szolgáltatásainál. Legfőképpen az összetett adatszerkezetek, illetve a perzisztens adattárolás lehetnek azok a funkciók, melyek miatt érdemes lehet váltani, de persze az igényektől függ, hogy ez szükséges-e. A Memcached-del szemben a Redis segítségével nem csak cache megoldásokat, hanem akár “igazi” adattárolást is megvalósíthatunk, mely egészen más felhasználási módokat is lehetővé tesz, a Memcached lehetőségeinek megtartása mellett.
Létezik egy MemcacheDB nevű projekt is, mely valójában csak nevében és protokolljában rokon a Memcacheddel, hiszen a netes interfész megvalósítását annak protokolljával kompatibilisen valósították meg, az adattárolása azonban nem a memóriában történik, hanem a BerkleyDB projektet használja erre a célra. Tekintettel arra, hogy írás műveleteknél itt minden alkalommal háttértárra írási művelet valósul meg (az mondjuk nagyon gyorsan), illetve hogy a BDB is csak egyszerű adatszerkezeteket támogat, ezért a Redis ezzel a projekttel szemben is előnyösebb választás lehet.
Támogatott nyelvek
A Redishez rövid pályafutása alatt a közösség jóvoltából (illetve a jól dokumentált protokolljának köszönhetően) számos programozási nyelven készült kliens, illetve további nyelvekhez viszonylag egyszerűen implementálható kliens megvalósítás. Ruby, Python, PHP, Erlang, Tcl, Perl, Lua, Java és Scala nyelvek alkotják a hivatalos listát, az egyetlen hiányzó ismertebb nyelvcsalád a .Net vonal. Egyes nyelvek alá (Ruby, Perl…) nem csak a parancsokat megvalósító, de komplexebb rutinkönyvtárak is rendelkezésre állnak.
Parancsok
A Redis parancsait négy csoportba sorolnám, vannak az alap-, a lista és a halmaz műveleteket megvalósítóak, továbbá az egyéb, legfőképpen adminisztrációs célúak. Persze ez elég önkényes besorolás, a projekt wiki oldalán specifikusabb kategorizálással találkozhatunk. Íme a fontosabb műveletek.
Az alapműveletek közé a következőket sorolnám:
SET kulcs érték: beállít egy új értéket a kulcs kulcshoz
GET kulcs, MGET kulcs1, kulcs2, kulcs3...: egy, illetve több kulcs értéke kérdezhető le
EXISTS kulcs: definiált-e adott kulcsú elem?
INCR kulcs, DECR kulcs: az adott kulcs numerikus értékének növelése, illetve csökkentése 1-gyel
INCRBY kulcs érték, DECRBY kulcs érték: mint az előző, de konkrét értékkel növelés, illetve csökkentés
DEL kulcs: adott kulcsú elem törlése az adatbázisból
KEYS minta: a “minta” mintával kezdődő kulcsok nevének lekérdezése
RANDOMKEY: egy véletlenszerű elem értékének lekérdezése
RENAME régikulcs újkulcs: kulcs átnevezése
EXPIRE kulcs másodperc: az adott kulcshoz lejárati idő társítás
A SET, GET, INCR/DECR műveletek sztring értékű kulcsok esetében használhatóak. Értékadás jellegű műveleteknél, ha egy kulcshoz eddig nem volt érték letárolva, akkor a Redis nem reklamál, hanem létrehozza az adott kulcsot, ez a tapasztalatok alapján így praktikus művelet.
Az EXPIRE művelet viszonylag egyedi módon megvalósított, ugyanis amennyiben egy adott kulcshoz lejárati időt társítunk, legközelebbi olvasást és írást is tartalmazó műveletkor (például INCR) a korábbi érték megsemmisül, avagy hiába nem járt még le a kulcs, de nulla értékről indul ezeknél a műveleteknél. Ez a replikáció konzisztensen tartása miatt működik így.
A listaműveletek közé az alábbiak sorolhatóak:
RPUSH kulcs érték, LPUSH kulcs érték: az adott kulcsú listába új elemet szúr érték értékkel, jobb oldalra, illetve bal oldalra
LLEN kulcs: lista hosszának lekérdezése
LRANGE kulcs kezdet vég: lista egy adott szakaszának lekérdezése
LTRIM kulcs kezdet vég: lista csonkolása csak a megadott szakasz megtartásával
LINDEX kulcs index: adott indexű elem lekérdezése a listából
LSET kulcs index: adott indexű elem értékének módosítása a listában
LREM kulcs darab érték: adott értékű, maximum “darab” darab elem eltávolítása a listából
LPOP kulcs, RPOP kulcs: listából egy elem kiemelése bal, illetve jobb oldalról
A lista pozíciók (kezdet, vég) megadásakor negatív számok is használhatóak, a “-2” érték hátulról a második elemet jelöli.
A halmaz műveletek igen érdekes felhasználási lehetőségeket rejtenek:
SADD kulcs érték, SREM kulcs érték: adott értékű elem halmazhoz adása, törlése
SPOP kulcs: egy véletlenszerű elem kivétele a listából
SMEMBERS kulcs: halmaz elemeinek a lekérdezése
SMOVE kulcs1 kulcs2 érték: az adott érték egyik halmazból a másikba történő mozgatása
SCARD kulcs: adott halmaz tagjainak száma
SISMEMBER kulcs érték: adott érték eleme a halmaznak?
SINTER kulcs1 kulcs2 kulcs3...: halmazok metszetének lekérdezése
SINTERSTORE célkulcs kulcs1 kulcs2 kulcs3...: halmazok metszetének lekérdezése, és letárolása a “célkulcs”-ú halmazba
SUNION kulcs1 kulcs2 kulcs3...: halmazok összegének lekérdezése
SUNIONSTORE célkulcs kulcs1 kulcs2 kulcs3...: halmazok összegének lekérdezése, és letárolása a “célkulcs”-ú halmazba
SDIFF kulcs1 kulcs2 kulcs3...: halmazok különbségének lekérdezése
SDIFFSTORE célkulcs kulcs1 kulcs2 kulcs3...: halmazok különbségének lekérdezése, és letárolása a “célkulcs”-ú halmazba
Egy halmazban egy adott érték csak egyszer szerepelhet, ha megpróbálunk hozzáadni egy már szereplő értékű elemet a halmazhoz, akkor a művelet “sikertelen” lesz (hozzáadáskor válaszul megkapjuk az információt, hogy mennyi elem lett sikeresen hozzáadva a halmazhoz).
Egy elég összetett lehetőségeket kínáló, a rendezés gondolatára felépített művelet is elérhető, mely listákkal és halmazokkal is működik:
SORT kulcs
SORT kulcs DESC
SORT kulcs LIMIT 0 10 ALPHA DESC
SORT kulcs BY suly_*
SORT kulcs BY suly_* GET object_*
A művelet adott kulcs elemeit képes rendezni (növekvő, csökkenő sorrendbe, numerikusan és alfanumerikusan), s limitálható az eredményhalmaz is a LIMIT kifejezés hozzáadásával. A BY kulcsszó segítségével bár a kulcs elemei lesznek rendezve, de nem a saját értékük szerint, hanem a BY által megadott prefixhez hozzáfűzött értékük szerinti kulcs értékét véve. Ha a GET kulcsszót is megadjuk, akkor válaszként nem az adott kulcs elemeit fogjuk visszakapni, hanem a GET által megadott prefixhez hozzáfűzött értékük szerinti kulcsok értékét.
A SORT funkció nem tud csodát művelni ami a sebességet illeti, gyorsrendezés az algoritmusa. Alfanumerikus rendezéskor a LC_COLLATE környezeti változó értékét veszi figyelembe.
További érdekesebb műveletek:
DBSIZE: adatbáziselemek számának lekérdezése
TYPE kulcs: kulcs típusának (sztring, lista, halmaz) lekérdezése
SAVE, BGSAVE, LASTSAVE: háttértárra mentéssel kapcsolatos műveletek
Nem az összes műveletet mutattam be, de a Redis által biztosított lehetőségek talán jól láthatóak ezen felsorolás után. Egy átgondolt, biztos alapokon álló fejlesztésről van szó, mindegy parancs esetén use-case indokolja meglétét, illetve csak olyan parancsok állnak rendelkezésre melyek legtöbb esetben gyorsak, vagy melyek nem feltétlenül gyorsak, de a funkcionalitáshoz sokat hozzátesznek.
Nem vettem bele a felsorolásba, de a Redis több adatbázist is támogat, melyeket sorszámokkal lehet elérni, s alapból 16 áll rendelkezésre. Ezek leginkább névtérként működnek, ezek között a névterek között is lehet kulcsokat mozgatni igény szerint. Használatuk helyett inkább több Redis szerver indítása (különböző portokon) lehet javasolt, tekintettel arra, hogy így az adatbázis mentések is elkülönülnek, hogy többprocesszoros szerveren a Redis egyszálas futtatási környezete így jobban megoszlik a processzorok között, egy esetleges blokkoló művelet csak egy adott Redis szervert tart fel, s mert talán egyszerűbb a nyilvántartása egy portnak, mint egy Redis adatbázis sorszámnak.
Backup
A Redis perzisztens módon háttértárra, konkrétan egy darab fájlba írja adatbázisának tartalmát a konfigurációban meghatározott időpontokban, események bekövetkeztekor. Ez a fájl a memória tartalom egy speciális, gyorsan kiírható, illetve gyorsan beolvasható lenyomata, más célokra nem használható – nem valami egyszerű fájlformátum, hanem tömény bináris fájl.
A kimentett tartalom backupolása igen egyszerű: csak le kell másolni a fájlt. Ez akár menet közben is történhet, a szerver leállítása nélkül, még akkor is, ha éppen egy háttértárra mentési folyamat fut éppen. A Redis egy átmeneti fájlt hoz létre, és a rename nevű parancs segítségével írja felül a korábbi fájlt, így biztosítva azt, hogy az átnevezés csak akkor történik meg, ha a fájlba írás véget ért, és sikeres volt. A művelet atominak számít, tehát vagy sikeresen megtörténik a régebbi fájl felülírása, vagy sikertelen lesz a művelet, s a korábbi fájl nem sérül.
Backupolni ezen kívül egy master-slave replikáció beállításával is lehet, egy slave adatbázison, így még az I/O műveletekkel sem terhelve a fő szervert.
Replikáció
A Redis replikációja egy elég egyszerűen konfigurálható, master-slave felállású replikáció, mely lehetővé teszi több slave használatát is, illetve a slave-ek láncként felfűzve (a slave is masterként viselkedik, hozzá további slave csatlakozik) gráfot is alkothatnak.
Replikáció közben a master szerver nem áll le, így egy slave kiesésekor vagy beállásakor (szinkronizáció esetén) a master továbbra is kiszolgálja a kéréseket. Ezzel szemben a slave oldalán a replikáció beindítása, a master állapotának felvétele közben nem végez műveleteket, ezzel is biztosítva az adatok konzisztenciáját.
Ha az adatbázis nem fér be a memóriába
Az adatbázisnak a Redis esetén be kell férnie a memóriába. Ennek megkerüléséhez a Redisnek nem célja segítséget adni, bár már felmerült egy olyan jövőbeni fejlesztési irány a levelezőlistán (egészen más okokból), hogy a Redis adattárolását megvalósító layer esetlegesen cserélhető lesz. Mindenesetre ha az adatbázisunk nem fér el a memóriában, akkor vagy nem tudjuk a Redist használni, vagy valamilyen adattárolási stratégiát bevezetve meg kell kerülnünk a kérdést.
Egy lehetőség, hogy a Redist csak cache-ként használjuk azokhoz az adatokhoz, melyekről tudjuk, hogy jelentős memóriát igényelnének. Ekkor ezekhez az információkhoz lejárati időt rendelünk az EXPIRE segítségével, így ha fogyóban a memória, a Redis fel fogja ezeket a területeket szabadítani, illetve maguktól is felszabadulnak egy idő után. Az írást mind a Redisbe, mind pedig a nagyobb kapacitású másik adatbázisba elvégezzük, s először megpróbáljuk a Redisből kiolvasni az információt, ha ott nem létezik, akkor fordulunk a másik háttértárhoz. Ezt a felállás mi sikeresen használjuk.
Esettanulmány: egy Twitter klón
A Redishez szinte az indulása óta elérhető egy PHP-ben írt Twitter klón forrása, mely nagyon egyszerű forráskódjával, illetve az alkalmazott stratégiákkal jól szemlélteti a Redis lehetőségeit, illetve azt a gondolkodásmódot, melyet el kell sajátítanunk, ha key-value adatbázist szeretnénk használni fejlesztéseinkhez.
Erre a gondolkodásmódra SQL múlttal nem is olyan egyszerű átállni, mert ellentmond minden ott megtanult metodikának, többek között a normalizálás szabályainak. Mindazonáltal ha végiggondoljuk hogy mi történik egy relációs adatbázisban a háttérben: látni fogjuk, hogy gyakorlatilag kevés a különbség ami a letárolt adatokat illeti, az indexek létrehozásával és redundáns tárolásával egy relációs adatbázis is hasonlóképpen működik mint amire szükség van key-value adatbázisok esetén.
A Redis wikiben található kis tutorialt érdemes végigolvasni, mivel olyan alapokkal kezd, hogy mi is jelent a key-value adattárolás a gyakorlatban, illetve mik azok az atomi műveleteket. Ebből a tutorialból emeltem ki pár gondolatot, melyek megmutatják, hogy hogyan lehet felépíteni egy összetett adatbázist.
A Twitter klón nem csak üzenetek küldését teszi lehetővé, hanem egy teljes(ebb) klónról van szó, mely a regisztrációt, a felhasználók személyes oldalát, ismerőseinek kezelését is tartalmazza.
A felhasználókat számmal azonosítja, melynek előállításához egy “global:nextUserId” kulcsú elemet használ. Új felhasználó létrehozásakor a következő parancsokat futtatja le a rendszer:
INCR global:nextUserId (ezáltal visszakapunk egy számot, pl: 1000)
SET uid:1000:username felhasznalonev
SET uid:1000:password jelszo
Ebből a három sorból már rengeteget lehet tanulni. A kulcsok kapcsán mint látható, speciális elnevezéseket célszerű használni, “névtereket” létrehozva a kettőspontok használatával. Míg egy key-value adatbázis alapvetően nem struktúrált, ezzel a trükkel hierarchiát vezethetünk be. A felhasználó azonosító legyártásához szükséges változót a globális névtérbe, a felhasználó azonosítójához köthető információkat az “uid” névtérbe helyeztük.
Vegyük észre a párhuzamot az adatbázis táblákkal is, hasonló a helyzet, mintha egy “uid” táblában két oszlopot hoznánk létre, az 1000-es id-jú felhasználónak két oszlopa: a “username” és “password” állnak rendelkezésre. Most egy fontos design patternt tanultunk meg a key-value adatbázisokat illetően.
Mivel csak kulcs szerint érhetőek el az adatbázisunk értékei, jelenleg nem tudjuk lekérdezni azt, hogy a “felhasznalonev” felhasználóhoz milyen azonosító, milyen jelszó kapcsolódik, bejelentkezéskor, illetve a felhasználó saját oldalának kiszolgálásakor azonban erre az információra szükségünk van. Mint látható, az adatbázis tervezését jóval alaposabban végig kell gondolnunk mint egy relációs adatbázis esetén, legfőképpen azt megvizsgálva, hogy milyen módon szeretnénk a későbbiekben hozzáférni az adatbázisban szereplő információkhoz.
A felhasználónévből felhasználói azonosító létrehozását egy új kulcs létrehozásával tudjuk megtenni, relációs adatbázisok esetén erre egy index szolgált volna:
SET username:felhasznalonev:uid 1000
A Twitternél minden felhasználónak vannak követői, illetve követik is felhasználók. Itt is hasonló stratégiát kell alkalmaznunk, mint az előbb, ugyanis mind a két irányból szeretnénk lekérdezni az információt a szolgáltatás működtetésekor (kiket követ, kik követik a felhasználót), ezért két kulcsot fogunk használni felhasználónként erre a célra. Amit az adatszerkezetet illeti, a halmazok tökéletes választást jelentenek majd:
uid:1000:followers
uid:1000:following
Egy nagyon fontos adatstruktúra még hátra van, a felhasználó legfrissebb hozzászólásait szeretnénk megjeleníteni az oldalán, mondjuk visszanézhetően maximum mondjuk ezret. A hozzászólásokat egy globális névtérben fogjuk eltárolni, s a felhasználókhoz hasonlóan azonosítókkal látjuk el, s hogy lekérdezhető legyen, hogy egy adott felhasználónak milyen hozzászólásai voltak, egy listát vetünk be:
uid:1000:posts
Amikor a felhasználó hozzászól, akkor a globális lista adminisztrációja mellett ebbe a listába is felvesszük a hozzászólás azonosítóját (LPUSH), majd a listát az ezredik elem után csonkoljuk (LTRIM), hogy ne nőjön a végtelenségig. A lista “lapozhatóan” az LRANGE parancs segítségével érhető el.
A Twitter klónt bemutató wiki oldalon ennél sokkal több gondolat olvasható, de ezzel a kivonattal talán sikerült megmutatnom pár design patternt, melyek jól használhatóvá teszik a key-value adatbázisokat, illetve megmutatják azon gyengeségeit, melyek erősségként is felfoghatóak.
Összefoglalás
A fentebb írtakból talán kiderül: egy nagyon jól használható adatbázis szervert ismerhetünk meg a Redis személyében ha úgy döntünk kipróbáljuk mit tud. Gyorsan tanulható, egyszerűen használható megoldást kínál sok problémára, melyek webes alkalmazásfejlesztéskor kifejezetten hasznosak tudnak lenni.
Mi a Miner.hu projektünk keretében, illetve iWiW alkalmazásokhoz használjuk háttéradatbázisként a Redist. Az előbbihez nagyrészt cache megoldásként, a friss bejegyzések memóriában tárolására, tematikus rovatainknál pedig a friss bejegyzéseket listákban tartjuk nyilván. Eddigi tapasztalataink azt mutatják, hogy egy terhelhető, stabil, jól használható eszközt vezettünk be, melyet másnak is szívesen ajánlunk.
Fotó: 
Jópár évnek kell eltelnie, mire a HTML 5 és a CSS 3 többségét használni fogjuk majd tudni, de sok olyan részlet van, melyeket már ma is tudunk használni, vagy mert a “gracefully degradation” jegyében a felhasználó egy tökéletesen működő, csak fapadosabb megoldással találkozik az azokat nem támogató böngészőkben, vagy pedig azért, mert JavaScript vagy más megoldásokkal azokban a böngészőkben is működőképesek lehetnek, melyek alapvetően nem támogatják még azokat. Ahol ez a helyzet, s ahol ebből nem származik komoly hátrány, ott mindenképpen javaslom az újdonságok használatát, hiszen ezzel kényelmesebbé tehető a modern böngészőket használók élete, és látványos megoldásokat lehet kihozni a dologból.
Utolsó megjegyzések