Upload
vvinston
View
1.617
Download
0
Embed Size (px)
Citation preview
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