A Redis lehetőségei




     Simon Bence
   Duodecad, 2010-08-03
Miről is lesz itt ma szó?
Webalkalmazások felépítése
             ●   Hagyományosan 2
                 Tier
                 ●   Application layer
 ...
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á...
Bottleneck
    ●   Relational Database Management
        Systems
    ●   Megoldáskísérlet: denormalizálás
    ●   Skálázá...
Olyan adattároló kell, ami...
●   ... gyorsan működik
●   ... célnak megfelelő adatstruktúrában tud tárolni
●   ... skáláz...
Tehát akkor a Redis
●   REmote DIctionary
    Server
●   Salvatore Sanfilippo
●   “Advenced key-value
    store”
●   Open ...
Ez egy olyan adattároló, ami...
                                            ●   ... gyors: memóriában
                    ...
Eszik vagy isszák?
●   NoSql hullám egyik tagja
●   2009 elejétől (első commit: 2009-03-22)
●   Jelenleg: 1.2.6 stabil, 2....
Ez akkor egy újabb Memcache?




Key-value store !== Data structures server
Támogatott adatstruktúrák
●   String-ek
●   Listák (list)
●   Halmazok (set)
●   Rendezett listák (sorted set, 1.1-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
   ...
String operációk
●   SET, GET, GETSET, MGET, SETNX, SETEX,
    MSET, MSETNT
●   INCR, INCRBY, DECR, DECRBY
●   APPEND, SUB...
String példa

> GET post.1
null
> SET post.1 foo
OK
> GET post.1
“foo”
> SET counter 1
OK
> INCRBY counter 3
4
Listák (List)
       ●   Láncolt lista
           implementáció
           (Linked list)
       ●   Ez nagyon gyorssá
    ...
Lista operációk
●   RPUSH, LPUSH, LLEN, LRANGE, LTRIM,
    LINDEX
●   LSET, LREM
●   LPOP, RPOP, RPOPLPUSH
●   BLPOP, BRPO...
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"]
Halmazok (Set)
●   String elemek
    rendezetlen
    gyűjteménye
●   Halmazelméleti
    műveletek
    végezhetőek el rajta...
Halmaz operációk
●   SADD, SREM, SPOP, SMOVE, SCARD,
    SISMEMBER
●   SINTER, SINTERSTORE, SUNION,
    SUNIONSTORE, SDIFF...
Halmaz példa
> SCARD user.1.colors
0
> SADD user.1.colors red
true
> SADD user.1.colors blue
true
> SMEMBERS user.1.colors...
Rendezett halmazok (Sorted set)
                ●   Hasonló a Set
                    adattípushoz, azzal a
              ...
Rendezett halmaz operációk
●   ZADD, ZREM
●   ZINCRBY
●   ZRANK, ZREVRANK (1.3.4-től)
●   ZRANGE, ZREVRANGE, ZRANGEBYSCORE...
Hash-ek
●   Nem rendezett kulcs-érték párok “map”-ja
●   Van lehetőség hozzáadni, törölni, tesztelni, stb.
●   A hatékonya...
Hash operációk
●   HSET, HGET, HSETNX, HMSET, HMGET
●   HINCRBY, HEXISTS
●   HDEL, HLEN, HKEYS, HVALS
●   HGETALL
HASH példa

> HSET colorvalues red 1
true
> HSET colorvalues green 3
true
> HINCRBY colorvalues green -1
2
> HGETALL color...
Use Case-k
●   Néhány felhasználási lehetőség bemutatása:
    ●   Search engine
    ●   Message queue
    ●   API access l...
Search engine: az ötlet
●   Indexelés
    ●   Szavakhoz tartozó set-ek
    ●   Tagjai az elemek azonosítói
●   Homályos in...
Search engine: a bemutatás
●   A szó: word, a double Metaphone eredmények: art és frt
●   Indexelés:
    SADD word 1
    S...
Message queue: az ötlet
●   Alapvetően egy FIFO jellegű tároló
●   Erre pont megfelel egy List adatszerkezet
●   Feladat k...
Message queue: a bemutatás
●   Feladat kiosztása
    ●   INCR jobid (ez a számláló adja vissza a jobid-t)
    ●   SET job....
API access logger: az ötlet
●   Jellemzően sok kérés
    ●   Egyesével SQL-be írni túlzottan “heavy weight”
●   Átmeneti t...
API access logger: a bemutatás 1
●   Adatok beszúrása
    ●   Sorted set
    ●   ZINCRBY api.requests.2010-08-03 1 api_act...
API access logger: a bemutatás 2
●   Ezeket a napokat kell feldolgozi
    ●   SMEMBERS api.requests.dates
●   Feleslegessé...
Stb...



Hagyományos cache-réteg, Session kezelő, Who
is online, Click és stat kezelés, közös használatú
       notepad, ...
Konklúziók
●   Kisebb-közepesebb, adott felépítésű adatok
    halmazának kezelésére ideális
●   A fix szerkezetű RDBMS-ekh...
Nem elég a példa? Ők is használják!



                 Github
          Craigslist (Alexa 32.)
        The Guardian (Alex...
Háttéranyag




Projekt oldala: http://code.google.com/p/redis/
     How-to-k: http://rediscookbook.org/
    Online konzol...
A NoSql család


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

 Memcache, Cassandra, MongoDB, CouchDB,
Keyspace (Magyar!), Ch...
Köszönöm!




                        Kérdések?
A prezentáció elérhető: http://dl.dropbox.com/u/115357/redis.pdf
Upcoming SlideShare
Loading in …5
×

A Redis lehetőségei

1,904 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,904
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

A Redis lehetőségei

  1. 1. A Redis lehetőségei Simon Bence Duodecad, 2010-08-03
  2. 2. Miről is lesz itt ma szó?
  3. 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. 4. 3 Tier megoldások ● Presentation layer ● Business layer ● Data(base) layer
  5. 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. 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. 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. 8. Tehát akkor a Redis ● REmote DIctionary Server ● Salvatore Sanfilippo ● “Advenced key-value store” ● Open source!
  9. 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. 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. 11. Ez akkor egy újabb Memcache? Key-value store !== Data structures server
  12. 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. 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. 14. String operációk ● SET, GET, GETSET, MGET, SETNX, SETEX, MSET, MSETNT ● INCR, INCRBY, DECR, DECRBY ● APPEND, SUBSTR
  15. 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. 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. 17. Lista operációk ● RPUSH, LPUSH, LLEN, LRANGE, LTRIM, LINDEX ● LSET, LREM ● LPOP, RPOP, RPOPLPUSH ● BLPOP, BRPOP (1.3.1-tól)
  18. 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. 19. Halmazok (Set) ● String elemek rendezetlen gyűjteménye ● Halmazelméleti műveletek végezhetőek el rajta gyorsan
  20. 20. Halmaz operációk ● SADD, SREM, SPOP, SMOVE, SCARD, SISMEMBER ● SINTER, SINTERSTORE, SUNION, SUNIONSTORE, SDIFF, SDIFFSTRE ● SMEMBERS, SRANDMEMBER, SORT
  21. 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. 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. 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. 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. 25. Hash operációk ● HSET, HGET, HSETNX, HMSET, HMGET ● HINCRBY, HEXISTS ● HDEL, HLEN, HKEYS, HVALS ● HGETALL
  26. 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. 27. Use Case-k ● Néhány felhasználási lehetőség bemutatása: ● Search engine ● Message queue ● API access logger
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 40. Köszönöm! Kérdések? A prezentáció elérhető: http://dl.dropbox.com/u/115357/redis.pdf

×