1. A Redis lehetőségei
Simon Bence
Duodecad, 2010-08-03

2. Miről is lesz itt ma szó?

3. Webalkalmazások felépítése
● Hagyományosan 2
Tier
● Application layer
● Data(base) layer
● Probléma
● Az adatréteg szűk
keresztmetszet

4. 3 Tier megoldások
● Presentation layer
● Business layer
● Data(base) layer

5. 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

6. 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

7. 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!

8. Tehát akkor a Redis
● REmote DIctionary
Server
● Salvatore Sanfilippo
● “Advenced key-value
store”
● Open source!

9. 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

10. 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ő

11. Ez akkor egy újabb Memcache?
Key-value store !== Data structures server

12. 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)

13. 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

14. String operációk
● SET, GET, GETSET, MGET, SETNX, SETEX,
MSET, MSETNT
● INCR, INCRBY, DECR, DECRBY
● APPEND, SUBSTR

15. String példa
> GET post.1
null
> SET post.1 foo
OK
> GET post.1
“foo”
> SET counter 1
OK
> INCRBY counter 3
4

16. 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)

17. Lista operációk
● RPUSH, LPUSH, LLEN, LRANGE, LTRIM,
LINDEX
● LSET, LREM
● LPOP, RPOP, RPOPLPUSH
● BLPOP, BRPOP (1.3.1-tól)

18. Lista példa
> RPUSH statuses.user.1 43
1
> LPUSH statuses.user.1 67
2
> LLEN
2
> LRANGE statuses.user.1 0 2
["67","43"]

19. Halmazok (Set)
● String elemek
rendezetlen
gyűjteménye
● Halmazelméleti
műveletek
végezhetőek el rajta
gyorsan

20. Halmaz operációk
● SADD, SREM, SPOP, SMOVE, SCARD,
SISMEMBER
● SINTER, SINTERSTORE, SUNION,
SUNIONSTORE, SDIFF, SDIFFSTRE
● SMEMBERS, SRANDMEMBER, SORT

21. Halmaz példa
> SCARD user.1.colors
0
> SADD user.1.colors red
true
> SADD user.1.colors blue
true
> SMEMBERS user.1.colors
["red", "blue"]
> SADD user.2.colors green
true
> SUNION user.1.colors user.2.colors
["red","blue","green"]

22. 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

23. 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

24. 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ő

25. Hash operációk
● HSET, HGET, HSETNX, HMSET, HMGET
● HINCRBY, HEXISTS
● HDEL, HLEN, HKEYS, HVALS
● HGETALL

26. HASH példa
> HSET colorvalues red 1
true
> HSET colorvalues green 3
true
> HINCRBY colorvalues green -1
2
> HGETALL colorvalues
{"red":"1","green":"2"}

27. Use Case-k
● Néhány felhasználási lehetőség bemutatása:
● Search engine
● Message queue
● API access logger

28. 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

29. Search engine: a bemutatás
● A szó: word, a double Metaphone eredmények: art és frt
● Indexelés:
SADD word 1
SADD word 4
SADD word 9
● Keresés:
SMEMBERS word;
SUNION word, art, frt
SINTER word, art, frt
● Forrás:
http://playnice.ly/blog/2010/05/05/a-fast-fuzzy-full-text-index-using-redis/

30. 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

31. 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

32. 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

33. 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}

34. 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/

35. 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

36. 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

37. Nem elég a példa? Ők is használják!
Github
Craigslist (Alexa 32.)
The Guardian (Alexa 209.)
(2010-08-02. adatok)

38. Háttéranyag
Projekt oldala: http://code.google.com/p/redis/
How-to-k: http://rediscookbook.org/
Online konzol: http://try.redis-db.com/

39. 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...

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