Redis est une base de données de type clé-valeur, sous licence BSD. On peut voir Redis comme une sorte de Memcached boosté aux stéroïdes.
La version 2.2.0 est sortie la semaine dernière, très rapidement suivie de la version 2.2.1. Cette version apporte principalement des optimisations par rapport à Redis 2.0 :
- importante diminution de la consommation mémoire (à ce sujet, je vous conseille la lecture des astuces pour optimiser la mémoire) ;
- réplication non-bloquante ;
- la commande Watch pour faire du check and set ;
- l'Algorithme LRU pour l'éviction des données quand la mémoire consommée par Redis est limitée ;
- nouvelles commandes : SETBIT, GETBIT, SETRANGE et GETRANGE permettant d'accéder à des valeurs de type « chaînes de caractères », comme s'il s'agissait de tableaux.
Pour la suite, antirez (le principal développeur) souhaite se concentrer sur la prise en charge des grappes de serveurs (clusters) et sur diskstore (un stockage sur disque des données pour les instances où tout faire tenir en mémoire n'est pas une option).
Aller plus loin
- Nouveau site officiel de Redis (345 clics)
- Release notes de la version 2.2 (23 clics)
- Le code de redis sur github (20 clics)
- Try Redis, un tutoriel interactif en ligne (81 clics)
- DLFP : sortie de Redis 2.0 (65 clics)
- DLFP : LinuxFr.org utilise Redis (114 clics)
- Des ressources sur Redis (89 clics)
# Et les perfs?
Posté par zaurus (site web personnel) . Évalué à 2.
Salut,
Ca vaut quoi par rapport a une bonne vielle appli en C utilisant BerkeleyDB?
A+, F.
[^] # Re: Et les perfs?
Posté par jraf . Évalué à 1.
ca depends
----> [] ok, elle était facile.
[^] # Re: Et les perfs?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
bekerleyDB est aux bases key/value ce que sqlite est aux bases SQL : c'est de l'embarqué.
Redis est un serveur, que tu peux répliquer sur plusieurs machines. tu as de plus beaucoup plus de fonctionnalités pour manipuler les valeurs (pas seulement des chaines). Et je crois que ça stocke uniquement en mémoire, pas de fichiers, comme memcached.
[^] # Re: Et les perfs?
Posté par Alex G. . Évalué à 1.
Ça peut stocker dans des fichiers mais en mode normal, le fichier n'est pas synchronisé à chaque écriture mais toutes les N écritures (ou N secondes) ce qui fait que sur un crash tu peux perdre des données.
# empreinte mémoire ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je voix qu'il y a des études pour gagner de la place mémoire. Est-ce qu'il y a des hack qui utilise des algorithmes de compression ? Il m'avait semblé que des algo comme LZO avait été fait pour ça (gagner de l'espace RAM sans que cela coute trop chère en CPU).
"La première sécurité est la liberté"
[^] # Re: empreinte mémoire ?
Posté par steph1978 . Évalué à 1.
La compression c'est efficace quand le message a une certaine taille. Une taille certaine même.
Dans une base orientée clé / valeur, il est difficile de faire cette hypothèse; du coup, il faudrait laisser l'application choisir d'activer la compression, ou l'activer au cas par cas sur une base.
C'est plus pertinent sur une base de données orientée document.
[^] # Re: empreinte mémoire ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Il est possible aussi de compresser un sous-ensemble de clef-valeur et de faire un décodage de la clef en 2 temps.
Il faut savoir que Linux compresse une partie des pages en mémoires et les garde en RAM, avant d'aller écrire le swap sur disque. L'idée est que la latence de décodage sera toujours plus rapide qu'un "seek" de disque.
"La première sécurité est la liberté"
# Performances ?
Posté par sunse8 . Évalué à 1.
Quid des performances ? Redis versus Memcached ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.