A Redis lehetőségei

Simon BenceDuodecad, 2010-08-03

Miről is lesz itt ma szó?

Webalkalmazások felépítése

● Hagyományosan 2 Tier● Application layer● Data(base) layer

● Probléma● Az adatréteg szűk

keresztmetszet

3 Tier megoldások

● Presentation layer● Business layer● Data(base) layer

Eredmények● Több load-balancer réteg

beépítése● Jobban skálázható

szolgáltatások● Az adatréteg nem

változott, az alapproblémánk marad

● Megj.: Java EE, ASP stb. világban elterjedt, a PHP-ban jellemzően sok “overhead”-el jár

Bottleneck● Relational Database Management

Systems● Megoldáskísérlet: denormalizálás● Skálázás: replikálás

● Az írást nem oldja meg● A háttértár megfoghatja● Fix adatstruktúra, véges mértékben

szabható az adott feladatra● Mivel a PHP nem folyamatos futású, és

így nem tud memóriába átmenetileg eltárolni adatot, többet fordul(hat) adatforráshoz

Olyan adattároló kell, ami...

● ... gyorsan működik● ... célnak megfelelő adatstruktúrában tud tárolni● ... skálázható● Pl.: valamely NoSql megoldás● No de ez nem csak egy egyszerű cache?

Nézzük!

Tehát akkor a Redis

● REmote DIctionary Server

● Salvatore Sanfilippo● “Advenced key-value

store”● Open source!

Ez egy olyan adattároló, ami...● ... gyors: memóriában

tárol, a háttértárra csak perzisztál*

● ... több féle adatszerkezetet támogat, amelyek különböző célokra vannak kialakítva

● ... támogatja a master-slave replikálást

Megj.: Gyári mérések szerint 110e SET/sec, és 81e GET/sec, amivel gyorsabb az általuk hasonló körülmények között mért Memcache-nél, gyakorlatban saját mérések szerint a Memcache a gyorsabb

Eszik vagy isszák?

● NoSql hullám egyik tagja● 2009 elejétől (első commit: 2009-03-22)● Jelenleg: 1.2.6 stabil, 2.0.0 RC4 fejlesztői● Gyorsan fejlődik● Szponzor: Vmware● ANSI-C-ben írva● Számos nyelvhez van illesztő

Key-value store !== Data structures server

Ez akkor egy újabb Memcache?

Támogatott adatstruktúrák

● String-ek● Listák (list)● Halmazok (set)● Rendezett listák (sorted set, 1.1-től)● Hash-ek (1.3.10-től)

String-ek

● Elemi struktúra● Használható szövegek vagy számok tárolására● Ez utóbbi esetben támogatja az elemi

értéknövelést, vagy csökkentést● Alapműveletek végezhetőek el rajta

String operációk

● SET, GET, GETSET, MGET, SETNX, SETEX, MSET, MSETNT

● INCR, INCRBY, DECR, DECRBY● APPEND, SUBSTR

String példa

> GET post.1null> SET post.1 fooOK> GET post.1“foo”> SET counter 1OK> INCRBY counter 34

Listák (List)

● Láncolt lista implementáció (Linked list)

● Ez nagyon gyorssá teszi a végekhez hozzáfűzést pl.

● Hozzáférni egy n. elemhez lassú (bejárást igényel)

Lista operációk

● RPUSH, LPUSH, LLEN, LRANGE, LTRIM, LINDEX

● LSET, LREM● LPOP, RPOP, RPOPLPUSH● BLPOP, BRPOP (1.3.1-tól)

Lista példa

> RPUSH statuses.user.1 431> LPUSH statuses.user.1 672> LLEN2> LRANGE statuses.user.1 0 2["67","43"]

Halmazok (Set)

● String elemek rendezetlen gyűjteménye

● Halmazelméleti műveletek végezhetőek el rajta gyorsan

Halmaz operációk

● SADD, SREM, SPOP, SMOVE, SCARD, SISMEMBER

● SINTER, SINTERSTORE, SUNION, SUNIONSTORE, SDIFF, SDIFFSTRE

● SMEMBERS, SRANDMEMBER, SORT

Halmaz példa

> SCARD user.1.colors0> SADD user.1.colors redtrue> SADD user.1.colors bluetrue> SMEMBERS user.1.colors["red", "blue"]> SADD user.2.colors greentrue> SUNION user.1.colors user.2.colors["red","blue","green"]

Rendezett halmazok (Sorted set)

● Hasonló a Set adattípushoz, azzal a különbséggel, hogy tartozik hozzá egy érték (“score”), ami mentén rendezve le lehet kérdezni

● Redis 1.2-től

Rendezett halmaz operációk

● ZADD, ZREM● ZINCRBY● ZRANK, ZREVRANK (1.3.4-től)● ZRANGE, ZREVRANGE, ZRANGEBYSCORE● ZCOUNT, ZREMRANGEBYRANK,

ZREMRANGEBYSCORE, ZCARD, ZSCORE● ZUNIONSTORE, ZINTERSTORE, SORT

Hash-ek

● Nem rendezett kulcs-érték párok “map”-ja● Van lehetőség hozzáadni, törölni, tesztelni, stb.● A hatékonyabb használat érdekében a Redis a

kevés elemszámú hash-re más tárolást alkalmaz, de van mód 2^32-1 elem felvitelére

● 1.3.10-ről elérhető

Hash operációk

● HSET, HGET, HSETNX, HMSET, HMGET● HINCRBY, HEXISTS● HDEL, HLEN, HKEYS, HVALS● HGETALL

HASH példa

> HSET colorvalues red 1true> HSET colorvalues green 3true> HINCRBY colorvalues green -12> HGETALL colorvalues{"red":"1","green":"2"}

Use Case-k

● Néhány felhasználási lehetőség bemutatása:● Search engine● Message queue● API access logger

Search engine: az ötlet● Indexelés

● Szavakhoz tartozó set-ek● Tagjai az elemek azonosítói

● Homályos indexelés● Elírások, ragozások végett● Fonetikus algoritmuson átfuttatva (is) elmenteni

● Algoritmus:● Soundex● Metaphone (Double Metaphone!)

● Keresés● SMEMBER● AND típusú logika: SINTER● OR típusú logika: SUNION

Search engine: a bemutatás● A szó: word, a double Metaphone eredmények: art és frt● Indexelés:

SADD word 1SADD word 4SADD word 9

● Keresés:SMEMBERS word;SUNION word, art, frtSINTER word, art, frt

● Forrás:http://playnice.ly/blog/2010/05/05/a-fast-fuzzy-full-text-index-using-redis/

Message queue: az ötlet● Alapvetően egy FIFO jellegű tároló● Erre pont megfelel egy List adatszerkezet● Feladat kiosztása

● Push-olás a feladatlistába● Feladat megkezdése

● Pop-olás a feladatlistából● Push-olás a feldolgozási listába

● Feladat lezárása● Pop-olás a feldolgozási listából

● Hibás kimenetel kezelése● Egy Shorted Set-ben tároljuk a hibás kimeneteleket, ahol a score a hibás

futások száma

Message queue: a bemutatás● Feladat kiosztása

● INCR jobid (ez a számláló adja vissza a jobid-t)● SET job.{jobid} {jobdata} ● LPUSH queue {jobid}

● Feladat megkezdése● RPOP queue (visszaadja az elemet)● GET job.{jobid}● ZADD inprogress {unix_timestamp} {jobid}

● Feladat lezárása● ZREM inprogress {jobid}

● Hibás kimenetelek kezelése● ZREMRANGEBYSCORE 0 {error_tolerance_timestamp}● RPUST queue {failed_job_id} (az elejére teszi őket vissza)

● Forrás: saját elgondolás

API access logger: az ötlet

● Jellemzően sok kérés● Egyesével SQL-be írni túlzottan “heavy weight”

● Átmeneti tár● Gyors elérés● Alapszintű aggregálás

● Feldolgozás● Adott időnként SQL-be

● Garbage collector● Átmeneti tár takarítása

API access logger: a bemutatás 1

● Adatok beszúrása● Sorted set● ZINCRBY api.requests.2010-08-03 1 api_action● ZINCRBY api.requests.2010-08-03.api_action 1 {member}● Aktuális dátum: SADD api.requests.dates 2010-08-03

● Generális lekérés● ZREVRANGE api.requests.2010-08-03 0 -1● ZSCORE api.requests.2010-08-03 api_action

● Felhasználó lekérése● Memberek: ZREVRANGE api.requests.2010-08-03.api_action 0 -1● Hit count: ZSCORE api.requests:2010-08-03.api_action {member}

API access logger: a bemutatás 2● Ezeket a napokat kell feldolgozi

● SMEMBERS api.requests.dates

● Feleslegessé vált adatok törlése● DEL api.requests.2010-08-03● DEL api.requests.2010-08-03.api_action● SREM api.requests.dates 2010-08-03sss

● Forrás● http://www.productionhacks.com/2010/07/10/redis-api-access-logger/

Stb...

Hagyományos cache-réteg, Session kezelő, Who is online, Click és stat kezelés, közös használatú

notepad, letöltésszámláló és limitáló

... és a közismert Twitter példa

Konklúziók

● Kisebb-közepesebb, adott felépítésű adatok halmazának kezelésére ideális

● A fix szerkezetű RDBMS-ekhez képest nagyobb szabadság az adatszerkezet kialakításában

● Ebben a célzott adatszerkezetek segítenek● Ugyanakkor nagyobb figyelmet igényel● Nincs adatintegritást támogató mechanizmus● A normalizálással szembemegy, az adat-

duplikáció teljesen elfogadott, sőt bevett

Nem elég a példa? Ők is használják!

GithubCraigslist (Alexa 32.)

The Guardian (Alexa 209.)(2010-08-02. adatok)

Háttéranyag

Projekt oldala: http://code.google.com/p/redis/How-to-k: http://rediscookbook.org/

Online konzol: http://try.redis-db.com/

A NoSql család

Nem az egyetlen és tökéletes. Van még:

Memcache, Cassandra, MongoDB, CouchDB, Keyspace (Magyar!), Chordless, Hbase, Google

BigTable, Amazon Dynamo, Neo4j, Riak, SimpleDb...

Köszönöm!

Kérdések?A prezentáció elérhető: http://dl.dropbox.com/u/115357/redis.pdf