Redis - (nosqlfr meetup #2)

Redis.

Redis est plus lent que Memcache (ça, c’est fait).

Redis est plus gourmand que Memcache (de 2 à 10 fois plus).

Redis n’est pas Memcache Ni un MemcacheDB Flared http://labs.gree.jp/Top/OpenSource/Flare-en.html Elliptics Network http://www.ioremap.net/projects/elliptics

Getting started

Getting started http://code.google.com/ Ne nécessite aucune p/redis/ dépendance Licence BSD Ne nécessite quasiment pas de conﬁguration Fonctionne sur quasiment n’importe Sait se faire tout petit quel système Unix (il (exécutable : 150 ko, existe aussi un début de mémoire : 2 Mo, cpu: portage Windows) 0,00%)

Back in time... Un Memcache avec persistance.

Les snapshots Clef 1 Clef 2 Clef 3 Valeur 1 Valeur 2 Valeur 3

Les snapshots Clef 1 Clef 2 Clef 3 Valeur 1 Valeur 2 Valeur 3 Disque Le ﬁchier est renommé à la ﬁn.

Les snapshots Clef 1 Clef 2 Clef 3 Valeur 1 Valeur 2 Valeur 3 Disque

Les snapshots Clef 3’ Clef 1 Clef 2 Clef 3 Valeur 3’ Valeur 1 Valeur 2 Valeur 3 COW Disque Compression LZF

Les snapshots Redis Clef 3’ Clef 1 Clef 2 Bgsave Clef 3 Important : vm.overcommit_memory=1

Conﬁguration des snapshots # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed save 900 1 save 300 10 save 60 10000

Warning! Il faut disposer de sufﬁsamment de mémoire pour stocker les copies pendant la sauvegarde. Au besoin, répartir les données sur plusieurs instances (et plusieurs disques).

Append-Only File Journal des commandes Pendant l’écriture d’un qui modiﬁent les nouveau journal, les données. écritures continuent à être écrites dans Toute la base peut être l’ancien. reconstruite d’après ce journal. Les commandes manquantes sont BGREWRITEAOF: réécrit concaténées au un journal optimisé. nouveau. Done.

Append-Only File fsync() après chaque commande, chaque seconde ou jamais. On contrôle le moment où l’on souhaite réécrire le journal. Format future-proof et plus résistant aux corruptions que les snapshots.

Avantages Les sauvegardes ne bloquent jamais la lecture ni l’écriture. Habituellement, les bases de données ont du mal à suivre lorsqu’il y a un grand nombre d’écritures. (même les bases nosql, lorsque les données sont persistantes...) Les accès aléatoires ne sont pas bien plus coûteux que les accès séquentiels.

La persistance : pourquoi ? Pour pouvoir redémarrer avec un cache qui n’est pas vide. Pour éventuellement ne pas avoir besoin d’une autre base de données.

Les namespaces SELECT MOVE FLUSHDB FLUSHALL

Les chaînes clef (chaîne) -> valeur (chaîne) 2^32-1 clefs d’1 Go max (2^64-1 clefs en interne) GET / SET / EXISTS DEL (multiple, atomique) MGET / MSET (multiple, atomique) INCR / DECR / INCRBY / DECRBY / APPEND

Les chaînes SETNX user:1:_lock 1 ... SETNX DEL user:1:_lock MSETNX MSETNX peuvent se combiner user:1:name -> bob avec EXPIRE pour user:1:zipcode -> 46310 éviter les deadlocks user:1:_lock -> 1 ... DEL user:1:_lock

Les chaînes KEYS * RENAME KEYS pref* RENAMEMX KEYS pr[eo]f EXPIRE KEYS p?f EXPIREAT KEYS p*f TTL

Redis RANDOMKEY Retourne une clef au hasard O(1)

MySQL... SELECT * FROM table ORDER BY RAND() LIMIT 1 SELECT * FROM table WHERE id >= (SELECT FLOOR(MAX(id) * RAND()) FROM table) ORDER BY id LIMIT 1;

MySQL... If there are some holes in the table you can ﬁx it by: SELECT (SELECT myTable2.id from myTable myTable2 where myTable2.id>=b.num LIMIT 1) c FROM (SELECT FLOOR(RAND() * (SELECT count(*) FROM myTable)) num ,@num:=@num+1 from (SELECT @num:=0) a , myTable LIMIT X) b ;

MySQL... To improve performance you can combine this solution with a left join: SELECT IF(c.id is null, (SELECT c2.id FROM myTable c2 WHERE c2.id > b.num LIMIT 1), c.id) d FROM (SELECT FLOOR(RAND() * (SELECT count(*) FROM myTable)) num ,@num:=@num+1 FROM (SELECT @num:=0) a , myTable LIMIT X) b LEFT JOIN myTable c ON( c.id=b.num);

MySQL... «The solution to account for gaps produces results weighted toward id values that follow gaps.» Oops!

MySQL... «On ajoute un champ avec des nombres aléatoires et à chaque lecture, on permute celui qu’on vient de lire avec celui d’une autre ligne au hasard !» Wow.

TYPE Retourne le type d’une clef Le type ??!?!?!

Les types de clefs String List Set Zset (Hash)

Les listes Compactes - 64 Mo Jusqu’à 2^32-1 pour une liste d’1 million éléments par liste. d’éléments. N’ayez pas Tout comme les clefs de peur ! type «string», les clefs de Mais moins que du ce type peuvent expirer, JSON / Igbinary / Thrift / être effacées en groupe, Protobuf... renomées et extraites aléatoirement.

Les listes LPUSH / RPUSH LPOP / RPOP LLEN LINDEX / LRANGE LSET (index précis) / LREM (élements) LTRIM

Les listes todo processing Tâche 1 Tâche 2 Tâche 3 RPOPLPUSH todo processing Worker

Les listes todo processing Tâche 1 Tâche 2 Tâche 3 RPOPLPUSH todo processing Retourne Tâche 3 Worker

Les listes todo processing Tâche 1 Tâche 2 Tâche 3 RPOPLPUSH processing todo Nettoyeur (n’oubliez pas le lock !)

Les listes : BLPOP/BRPOP Retourne et efface le dernier élément S’il n’y en a pas, attend (max 10 sec) qu’il y en BRPOP queue 10 ait un Deux clients n’obtiendront jamais le même élément.

Les listes : BLPOP/BRPOP Tente d’obtenir un élément de queue1 BRPOP Sinon, tente dans queue1 queue2 queue3 queue2, puis queue3. 10 Génial pour gérer des listes de tâches avec des priorités

Les listes : BLPOP/BRPOP BLPOP : devinez :) BRPOPPUSH : dans la TODO list pour la v1.4

SORT Retourne une copie triée des éléments d’une liste, d’un ensemble ou d’un zset. Mais pas seulement !

SORT : Warning! users = [ joe, robert, john ] SORT users 1. robert 2. joe 3. john

SORT users = [ joe, robert, john ] SORT users ALPHA 1. joe 2. john 3. robert

SORT users = [ joe, robert, john ] SORT users ALPHA DESC LIMIT 0 2 1. robert 2. john

SORT users = [ joe, robert, john ] DEL stcache SORT users ALPHA DESC LIMIT 0 2 STORE stcache EXPIRE stcache 30 LRANGE stcache 0 50

SORT SORT ... BY ... : tri par une autre clef Hein ?

SORT users = [ 1, 2, 3 ] SORT users BY user:*:age user:1:name frank user:1:age 30 3 user:2:name robert 1 user:2:age 42 2 user:3:name anais user:3:age 3 (si les préﬁxes sont longs, pensez à à sharedobjects)

SORT SORT users user:1:name frank BY user:*:age user:1:age 30 GET user:*:name user:2:name robert user:2:age 42 anais user:3:name anais frank user:3:age 3 robert

SORT SORT users BY user:*:age user:1:name frank GET # user:1:age 30 GET user:*:name user:2:name robert GET user:*:age user:2:age 42 user:3:name anais 3 anais 3 user:3:age 3 1 frank 30 2 robert 42

SORT : astuces Récupère tous les éléments d’une liste, sans tri : SORT list BY none Récupère tous les utilisateurs, triés par identiﬁants : SORT users GET # GET user:*:name GET user:*:age Récupère tous les utilisateurs, sans tri : combinez les deux :)

Les ensembles (sets) Listes d’éléments distincts Jusqu’à 2^32-1 éléments par ensemble 74 Mo pour une clef avec 1 million d’éléments «clef primaire» ou «liste des membres de...» L’ordre n’est pas garanti lors d’un SORT BY xyz RANDOMKEY, EXPIRE, RENAME, ...

Les ensembles (sets) SADD, SREM, SCARD SISMEMBER, SMEMBERS SMOVE

Les ensembles (sets) SRANDMEMBER SPOP : déplace de façon atomique un élément aléatoire dans un autre ensemble.

Les ensembles (sets) Users user:1:name 1 user:1:age user:1:follows 7 3 9 4 2 3

Les ensembles : SINTER iphone = [ 1, 5, 8, 10 ] tags ruby = [ 2, 4, 5, 10 ] recherches avec des SINTER iphone ruby critères booléens [ 10, 5 ]

Les ensembles : SUNION iphone = [ 1, 5, 8, 10 ] union des ensembles, ruby = [ 2, 4, 5, 10 ] mais le résultat reste un SET : il ne contient donc que des valeurs SUNION iphone ruby uniques. [ 4, 5, 8, 10, 1, 2 ]

Les ensembles (sets) 16/02/2010 1 8 12 23 15/02/2010 2 10 19 14/02/2010 2 7 11 19 24 SUNION / SINTER : Visiteurs uniques ou qui reviennent d’un jour sur l’autre

Les ensembles (sets) 1 3 4 6 7 9 A C 2 3 5 6 8 9 B C 4 7 B SDIFF 1 A C

Les ensembles (sets) SINTERSTORE SUNIONSTORE SDIFFSTORE (évidemment, on peut ajouter une expiration)

Les ensembles (sets) 20h30 : [ 1, 4, 6, 9, 10, 15, 17, 25 ] 20h29 : [ 1, 6, 9, 10, 15, 17, 25 ] 20h28 : [ 4, 6, 9, 10, 13, 15, 25 ] 20h27 : [ 1, 4, 6, 9, 10, 13, 18, 25 ] 20h26 : [ 1, 4, 6, 9, 10, 18, 20 ] UNION : [ 10, 1, 20, 4, 13, 15, 6, 25, 17, 18, 9 ]

Les ensembles (sets) 20h30 : [ 1, 4, 6, 9, 10, 15, 17, 25 ] 20h29 : [ 1, 6, 9, 10, 15, 17, 25 ] 20h28 : [ 4, 6, 9, 10, 13, 15, 25 ] 20h27 : [ 1, 4, 6, 9, 10, 13, 18, 25 ] 20h26 : [ 1, 4, 6, 9, 10, 18, 20 ] UNION : [ 10, 1, 20, 4, 13, 15, 6, 25, 17, 18, 9 ] amis : [ 13, 15, 27 ] INTER : [ 13, 15 ]

Les ensembles (sets) 20h30 : [ 1, 4, 6, 9, 10, 15, 17, 25 ] 20h29 : [ 1, 6, 9, 10, 15, 17, 25 ] 20h28 : [ 4, 6, 9, 10, 13, 15, 25 ] 20h27 : [ 1, 4, 6, 9, 10, 13, 18, 25 ] 20h26 : [ 1, 4, 6, 9, 10, 18, 20 ] SUNIONSTORE online:new SDIFFSTORE ofﬂine online:current online:new RENAME online:new online:current

Les ensembles triés (Zsets) Liste d’éléments uniques À chaque élément est associé un «score» (double) L’ensemble est toujours pré-trié selon le score.

Les ensembles triés (Zsets) Ensemble users_nb_visits : Roberta 2372323 Roberti Roberto 1358912 1332837 Robertu 1301239 Insertion : O(log(N)) Skip lists + hashes

Les ensembles triés (Zsets) ZADD / ZREM : ajoute / retire un élément ZCARD : retourne le nombre d’éléments ZINCRBY : ajoute / retire un nombre au score précédent ZSCORE : change le score d’un élément

Les ensembles triés (Zsets) ZRANGE 0 -1 : retourne tous les éléments, classés par score ZRANGE 0 9 : retourne ceux qui ont les 10 plus petits scores ZRANGE 10 19 : pour la pagination

Les ensembles triés (Zsets) ZREVRANGE 0 -1 : retourne tous les éléments, classés par scores décroissants ZREVRANGE 0 9 : retourne ceux qui ont les 10 meilleurs scores ZREVRANGE 10 19 : pour la pagination

Les ensembles triés (Zsets) ZRANGEBYSCORE 2 200000 : retourne tous les éléments dont le score est entre 2 et 200000 ZRANGEBYSCORE supporte aussi la pagination (LIMIT offset count) et peut retourner les scores en plus des éléments (WITHSCORE) ZCOUNT : compte le nombre d’éléments dont le score est situé dans un intervalle Bornes ouvertes ou fermées : (2 200000 : 2 est exclu.

Les ensembles triés (Zsets) Classements en temps réel, y compris avec des millions de données Tris avec des critères sur mesure Implémentations d’autres structures de données (ex: trie) Bientôt : ZPREV / ZNEXT (x éléments précédant / suivant un élément de référence), ZRANK (rang d’un élément), INTER et UNION.

Les blocs d’opérations atomiques (pas tout à fait des transactions, mais presque)

Un bloc atomique : MULTI DEL clef EXPIRE clef 10 SET clef 42 GET clef2 LPUSH liste element LTRIM liste 0 100 EXEC => [0, 0, "OK", nil, "OK", "OK"]

La mémoire virtuelle Redis 2.0

La mémoire virtuelle La RAM, ça va vite Les disques (même SSD) beaucoup moins L’OS attribue aux applications des pages de mémoire, qui peuvent être de la mémoire physique ou sur disque.

La mémoire virtuelle Les pages dont on a (à vue de nez) besoin immédiatement : l’OS essaye de les placer / déplacer en mémoire physique Les pages dont on n’a (à vue de nez) pas besoin dans l’immédiat : l’OS essaye de les déplacer sur disque Tout espace réellement disponible en RAM peut être utilisé comme cache disque

La mémoire virtuelle La mémoire virtuelle permet aussi aux applications d’utiliser une plus grande quantité de mémoire que la mémoire physique disponible. Pourquoi ne pas s’en servir pour que Redis puisse stocker plus de données que ce que la mémoire peut contenir ? Le pire c’est que... ça fonctionne.

Mais ça raaaaaaaaaaaaame.

La mémoire virtuelle L’OS n’a aucune idée de la structure des données applicatives La taille d’une page mémoire est généralement entre 4 Ko et 16 Ko Dans Redis, une valeur occupe plusieurs blocs de mémoire non consécutifs Les structures de données sont optimisées pour une recherche en RAM

La mémoire virtuelle On peut écrire les données de façon beaucoup plus simple sur disque et surtout beaucoup plus compacte. Moins d’espace de stockage => moins d’I/O Redis a sa propre gestion de la mémoire virtuelle

La mémoire virtuelle Espace de stockage divisé en pages, mais la taille des pages peut être librement choisie Toutes les clefs sont en RAM Les valeurs peuvent être en disque ou en RAM Redis sait toujours quelles clefs sont sur disque, leur taille et leur position exacte.

La mémoire virtuelle Redis peut être conﬁguré pour conserver les valeurs uniquement sur disque : si 1 million de clefs prennent 200 Mo, il n’y aura toujours que 200 Mo d’utilisé quelque soit ce que les clefs contiennent.

La mémoire virtuelle Une quantité maximale de RAM à utiliser peut être conﬁgurée. Les valeurs sont transférées sur disque en fonction de leur «swappabilité» : = temps écoulé depuis la dernière utilisation * taille Gestion threadée des copies de/vers le disque.

Redis dans votre réseau ?

Modèle Redis vs Memcache Architecture «traditionnelle» : tout est sur disque et on stocke les lectures les plus récentes dans memcache Redis : un «cache» qui stocke éventuellement les données les moins utiles sur disque

Modèle Redis vs Memcache Architecture (hélas) classique : on met à jour une base SQL, puis on met à jour memcache. Si la base SQL se traîne, tout traîne. Et les incohérences entre les caches et les bases arrivent vite. Redis : on ne met à jour que Redis, qui s’occupe aussi de la durabilité sans bloquer les accès clients, qui s’effectuent en mémoire. Scale en lecture mais aussi en écriture.

Architecture intermédiaire Memcache SQL Client Worker Queue SQL

Architecture intermédiaire Sécurité (persistance) SQL Client Worker Queue SQL

Architecture intermédiaire Sécurité (persistance) Redis SQL Client Worker Queue SQL

Architecture intermédiaire sécurité (persistance) Redis SQL Client Worker SQL sets (éléments uniques)

Architecture intermédiaire sécurité (persistance) Redis SQL Client Worker Redis SQL sets (éléments uniques)

La réplication

La réplication Réplication Master -> Slaves Reconﬁgurable à chaud Asynchrone EXPIRE transformé en EXPIREAT COW comme pour les snapshots

La réplication Le slave n’a pas besoin d’avoir des données de départ Le master effectue un dump en tâche de fond Le slave attend la fin du dump puis le charge Le master transmet au slave la liste des modifications effectuées pendant le dump ainsi que les modifications suivantes La réplication ne bloque jamais le master

Redis-Cluster Ce sera pour la version 2.2 !

Redis-Tools L’offre commerciale

Redis Load

Redis Stat

Redis Stat + Outils d’exportation en CSV et MySQL Opensource Entre $ 200 et $ 350

Les clients

Le protocole Authentiﬁcation simple (mot de passe) Protocole binary-safe Pipelining TCP uniquement, mais l’attente de la réponse du serveur n’est pas obligatoire. L’UDP est dans la TODO-list.

Les bibliothèques clientes Actionscript 3 Groovy C (Credis) Haskell Clojure Java Common Lisp LUA Erlang .NET Go NodeJS

Les bibliothèques clientes Perl et sûrement d’autres ! PHP Python Ruby Scala TCL

:( Sharding uniquement supporté en Ruby (redis-rb), PHP (Redisent, Rediska, Predis) et Scala. Il est possible de grouper des clefs sur un shard en respectant certaines conventions pour le nom de ces clefs. Ce n’est que du sharding, il n’y a aucune redondance ni reconﬁguration. Pas de Spymemcached ni de Moxi.

Quelques outils... Redis-CLI (fourni) Redis-Textsearch RediSH RRBayes RESTMQ Redis-Admin Resque Redweb Celery Retwis-Rb Torque Redis Ajax Chat

Hints... vm.overcommit_memory=1 net.ipv4.tcp_tw_reuse=1 Sous OSX : net.inet.tcp.msl=1000 NedMalloc

Have fun. -Frank.

http://5.freshminutes.it	1355
http://wiki	30
http://www.slideshare.net	18
http://www.linkedin.com	5
http://translate.googleusercontent.com	2
http://www.lmodules.com	1
http://www.taaza.com	1
http://webcache.googleusercontent.com	1
http://trunk.ly	1
http://209.85.229.132	1

Redis - (nosqlfr meetup #2)

by Frank Denis

Accessibility

Categories

Upload Details

Usage Rights

10 Embeds 1,415

Statistics

Redis - (nosqlfr meetup #2) Presentation Transcript