ݺߣ

ݺߣShare a Scribd company logo

A Redis lehetőségei

•
•
V
vvinston
1 of 40
Download to read offline
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 ● 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ő
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) ● 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.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á 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 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 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.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"]
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 1 true > HSET colorvalues green 3 true > HINCRBY colorvalues green -1 2 > 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 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/
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! Github Craigslist (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érdések? A prezentáció elérhető: http://dl.dropbox.com/u/115357/redis.pdf

More Related Content

A Redis lehetőségei

  • 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érdések? A prezentáció elérhető: http://dl.dropbox.com/u/115357/redis.pdf