Les principales caractéristiques de Redis sont :
- Les performances impressionnantes (de quelques dizaines à une centaine de milliers d'opérations à la seconde) ;
- La persistance, via des copies régulières de la mémoire vers le disque ou écriture à chaque modification (mais c'est plus coûteux) ;
- Réplication de type maître/esclave ;
- Typage des valeurs, avec au choix, chaînes de caractères, listes, ensembles, ensembles triés et hashs ;
- Des opérations avancées sur ces types (exemple : calculer l'intersection de plusieurs ensembles) ;
- L'exécution de plusieurs commandes de manière atomique ;
- Un mécanisme pub/sub ;
- Des bibliothèques pour de nombreux langages de programmation ;
- La simplicité à installer et à gérer, la portabilité, etc.
Le principal développeur de Redis, Salvatore Sanfilippo, a été embauché par VMWare pour travailler à plein temps sur Redis. Cela a conduit à la récente sortie de la version 2.0 dont quelques nouveautés seront mises en avant dans la seconde partie de la dépêche.
Exemple d'utilisation de Redis en Ruby
require 'redis' # On charge la bibliothèque redis
r = Redis.new # On se connecte à Redis (par défaut sur le port 6379 de localhost)
r.del 'logs' # On supprime la clé logs
# On ajoute 4 messages de logs dans la liste 'logs'
# Redis devine tout seul que 'logs' est une liste car on lui envoie une commande, rpush, de type liste
r.rpush 'logs', 'some log message'
r.rpush 'logs', 'another log message'
r.rpush 'logs', 'yet another log message'
r.rpush 'logs', 'also another log message'
# On affiche toute la liste,
# en fait, tous les éléments dont l'indice est entre 0, le premier, et -1, la fin
puts r.lrange('logs', 0, -1)
# On ne garde que les deux derniers éléments
r.ltrim('logs', -2, -1)
# On n'affiche à nouveau toute la liste et on peut constater qu'il ne reste que deux éléments
puts r.lrange('logs', 0, -1)
# On crée un ensemble avec 3 éléments
r.sadd 'foo-tags', 'un'
r.sadd 'foo-tags', 'deux'
r.sadd 'foo-tags', 'trois'
# Et un autre ensemble avec 3 éléments
r.sadd 'bar-tags', 'trois'
r.sadd 'bar-tags', 'quatre'
r.sadd 'bar-tags', 'cinq'
# On affiche l'intersection de ces ensembles,
# c'est-à-dire les éléments qui appartient aux deux ensembles
puts r.sinter('foo-tags', 'bar-tags')
Les nouveautés de la version 2.0.0
Les hashs, un nouveau type de données
Les hashs sont un nouveau type de données, particulièrement bien adaptés pour stocker des objets. Par exemple, enregistrer un utilisateur peut se faire de la manière suivante :
HSET user/1 nickname NoNo -> enregistre le champ nickname de l'utilisateur n°1
HSET user/1 homepage http://linuxfr.org/ --> même chose pour le champ homepage
HGETALL user/1 --> retourne tous les champs et valeurs associés de l'utilisateur : {nickname: "NoNo", homepage: "http://linuxfr.org"}
En savoir plus sur les hashs.
Les POP bloquants
Il est possible dans Redis de retirer un élément en début ou fin de liste et de le récupérer dans la même opération (ce sont les commandes LPOP et RPOP). Dans Redis 2.0, une variante de ces commandes a été introduite pour ne pas retourner tout de suite quand une liste est vide, mais d'attendre qu'un élément soit ajouté à la liste (dans la limite du temps indiqué) : ce sont BLPOP et BRPOP.
En savoir plus sur les BLPOP et BRPOP.
Les transactions Redis
Les commandes MULTI et EXEC permettent d'exécuter plusieurs commandes dans une seule transaction. Cela signifie qu'une requête d'un autre client ne peut pas être exécutée au milieu de cette transaction et que l'ensemble des commandes réussiront ou échoueront ensemble.
En savoir plus sur les transactions.
Publish/Subscribe
Redis est désormais une plateforme de messages pub/sub. Les clients peuvent s'inscrire à des chans (canaux) et recevront ainsi tous les messages postés sur ces chans par les autres clients. Il est même possible de s'inscrire à des motifs de chans pour recevoir tous les messages envoyés sur des chans dont le nom correspond au motif.
En savoir plus sur Publish/Subscribe.
La mémoire virtuelle
Redis devait garder l'intégralité de ses données en mémoire, ce qui pouvait poser problème dans certains cas. Redis est maintenant capable de transférer une partie des valeurs sur le disque dur (mais pas les clés) pour économiser de la mémoire.
En savoir plus sur la mémoire virtuelle.
Aller plus loin
- Site officiel de Redis (57 clics)
- Le code de Redis sur github (11 clics)
- Le changelog de la version 2.0 (3 clics)
- Try Redis, un tutoriel interactif en ligne (27 clics)
- En savoir plus sur Redis (151 clics)
# Défaut(s) ?
Posté par claudex . Évalué à 10.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Défaut(s) ?
Posté par Dring . Évalué à 8.
(...) une requête d'un autre client ne peut pas être exécutée au milieu de cette transaction (...)
J'ai l'impression qu'il n'y a pas de notion de vérou par ligne/par clé, ce qui fait que soit on a aucune isolation, soit on verrouille tout, ce qui est un sérieux critère au moment de choisir entre du SQL ou une alternative (nosql, Reids ou autre).
J'ai aussi envie de réagir à ça :
# Redis devine tout seul que 'logs' est une liste car on lui envoie une commande, rpush, de type liste
Ben non, il ne devine rien, puisqu'on lui dit de façon explicite avec l'utilisation de "rpush". C'est pas un reproche sur le produit, hein, mais juste que je ne vois rien de magique là-dedans.
Et une précision, car ça ne ressort pas dans la dépêche : Redis semble être codé en c pur. Le code a d'ailleurs l'air d'être particulièrement propre et plutôt bien commenté - je parle pour la partie serveur, j'ai pas été voir pour chaque librairie cliente.
[^] # Re: Défaut(s) ?
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Il n'y a effectivement pas de verrou par clé. En pratique, cela ne m'a jamais manqué car les opérations proposées sont riches fonctionnellement (et bien entendu atomiques). Par exemple, il est possible d'incrémenter une valeur et récupérer la nouvelle valeur en seule commande (INCR).
> Ben non, il ne devine rien, puisqu'on lui dit de façon explicite avec l'utilisation de "rpush". C'est pas un reproche sur le produit, hein, mais juste que je ne vois rien de magique là-dedans.
Il n'y a effectivement rien de magique. Je voulais juste montrer qu'il n'y a pas besoin de déclarer le type d'une valeur avant de l'utiliser.
[^] # Re: Défaut(s) ?
Posté par Dring . Évalué à -1.
(...) une requête d'un autre client ne peut pas être exécutée au milieu de cette transaction (...)
J'ai l'impression qu'il n'y a pas de notion de vérou par ligne/par clé, ce qui fait que soit on a aucune isolation, soit on verrouille tout, ce qui est un sérieux critère au moment de choisir entre du SQL ou une alternative (nosql, Reids ou autre).
J'ai aussi envie de réagir à ça :
# Redis devine tout seul que 'logs' est une liste car on lui envoie une commande, rpush, de type liste
Ben non, il ne devine rien, puisqu'on lui dit de façon explicite avec l'utilisation de "rpush". C'est pas un reproche sur le produit, hein, mais juste que je ne vois rien de magique là-dedans.
Et une précision, car ça ne ressort pas dans la dépêche : Redis semble être codé en c pur. Le code a d'ailleurs l'air d'être particulièrement propre et plutôt bien commenté - je parle pour la partie serveur, j'ai pas été voir pour chaque librairie cliente.
[^] # Re: Défaut(s) ?
Posté par usbplug . Évalué à 3.
À noter aussi l'existence de projets liés :
- JRedis [http://code.google.com/p/jredis/] , une version en Java de Redis qui est aujourd'hui compatible avec Redis 2.0.
- Pincaster [http://github.com/jedisct1/Pincaster], un projet qui reprend l'architecture de Redis mais avec d'autres structures de données, en particulier pour les applications utilisant de la géolocalisation.
- Redis Tools [http://github.com/antirez/redis-tools], des outils pour superviser et optimiser Redis.
[^] # Re: Défaut(s) ?
Posté par usbplug . Évalué à 1.
Il existe des clients pour bien d'autres langages, mais ils ne sont pas forcément tous très complets ou à jour.
En particulier, le vieux protocole "ASCII" de Redis est encore supporté par Redis 2.0 mais n'existe plus dans la version en cours de développement. Et tous les clients ne supportent pas le protocole binaire. Le client Ruby supporte parfaitement le nouveau protocole mais les autres n'arrivent pas à se connecter à Redis > 2.0.
[^] # Re: Défaut(s) ?
Posté par usbplug . Évalué à 1.
# prout
Posté par yastupin . Évalué à -10.
[^] # Re: prout
Posté par Bruno Michel (site web personnel) . Évalué à 8.
[^] # Re: prout
Posté par Psychofox (Mastodon) . Évalué à 5.
Maintenant si tu préfères du garbage en tout genre, du prosélytisme religieux, de la mauvaise foi, du mauvais goût, du racisme, du troll et du vendredi je pense que tu t'es tromper de section et que tu pourras les trouver ici : https://linuxfr.org/journal/
# "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Comment on peut appelé cela une base de donné ?
Une base de donné garanti que l'information stoqué est soit la valeur actuel soit la valeur précédente et rien entre les 2. Avec un simple mmap(), on ne garanti rien du tout. En cas de coupure de courant au mauvais moment, le fichier peut être complètement corrompu.
Est-ce que j'ai réellement bien compris le système de "persistance" ?
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
SQL light a tendance à faire plein de fsync().
Oracle attaque directement en RAW et gère sont propres caches.
Je ne sais pas ce que font MySQL et PostregrSQL mais je suis persuadé qu'ils ont un système pour gérer cela (log ou fsync ou... ).
Une base de donné doit garantir son intégrité sinon quel intérêt par rapport à une structure de donné classique en mémoire, avec un gros mmap() fait de temps en temps ? en performance, cela serait imbattable !
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Utiliser une base de données SQL, c'est souhaiter disposer de certaines fonctionnalités te permettant de décrire l'intégrité des données, dans un langage initialement standardisé. Mais l'intégrité ne fait pas tout, il y a aussi les performances et les fonctionnalités qui entrent en jeu dans le choix d'une technologie.
Parfois, la rapidité d'obtention d'une donnée est plus importante que sa fiabilité ou son exactitude. L'exemple des nombres float et des décimaux est un exemple très parlant.
Bref, c'est une question de compromis.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne vois pas non plus ce que viens faire les histoires de code flottant la dedans.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Quasiment toutes les bases de données NoSQL garantissent l'atomicité, mais j'ai l'impression que ce tu recherches est la durabilité (en gros, la capacité de résister aux coupures de courant). Et là, les bases de données NoSQL ont des approches très différentes. Certaines garantissent la durabilité et d'autres non.
Un cas intéressant est celui de MongoDB. Par défaut, il ne garantit pas la durabilité. En pratique, c'est rarement un problème. Si tu as un seul serveur, ton plus gros risque n'est pas les pannes de courant mais les disques durs qui lâchent. Et là, durabilité ou pas, ta seule protection est d'avoir des sauvegardes régulières. Et si perdre des données n'est pas acceptable, alors il faut passer avoir plusieurs serveurs, et autant que possible dans plusieurs datacenters.
[^] # Re: "base de données" ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Tu as du mal à comprendre parce que tu n'as jamais dû avoir de cas concret à gérer. On ne peut rien garantir avec un logiciel. Par contre, avec une infrastructure et en mesurant ayant consciences des concessions que l'on fait, on peut assurer une certaine fiabilité et qualité de service.
Je ne parlait pas de code flottant. Je parlait des nombres float. Ces nombres sont des représentations de nombres réels. Ils en sont la plupart du temps une approximation. Cette approximation introduit une imprécision dans les calculs sur ces nombres. Lorsque cette imprécision n'est pas gênante, on peut utiliser des FPU performant (pour calculer le rendu d'une scène 3D par exemple). Par contre, stocker un montant financier dans un float est une erreur de débutant très répandue, qui rend les comptes faux. On aurait dû privilégier le type de données décimal, qui est lent mais fiable, sur le type float, rapide mais imprécis.
On peut appliquer ce raisonnement aux nombreux choix que l'on doit faire lorsqu'il s'agit de déployer une solution informatique : quels niveaux de rapidité et de fiabilité, pour quel coût ?
MongoDB prétend garantir l'atomicité sur certaines opérations.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Concernant tes maths financières, sans aller jusqu'à utiliser des nombre décimal, un entier 64 bits qui compte des centimes, c'est déjà pas mal.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par Jux (site web personnel) . Évalué à 2.
En utilisant la sauvegarde sur disque à chaque modification de Redis, tu arrives au même résultat. Comme il n'y a pas de clé étrangères ou autres relations sur Redis, le problème de la consistance est nettement plus simple à résoudre qu'en SQL. Y'a rien à résoudre en fait, si un enregistrement est écrit de manière atomique...
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Et puis les crash disque et les pannes de courant ne sont pas des événements que peuvent gérer des logiciels. C'est pour qu'on fait en sorte que ça n'arrive jamais (NAS, RAID, onduleurs redondés, etc).
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Sinon, un bon mmap() sur une structure de donné du langage natif doit être absolument imbattable.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Mais surtout, le disque dur peut dire que la donnée être écrite alors que c'est faux. Tout les disques durs ont une mémoire tampon, qui leur permet d'optimiser les IO. Si le disque dur dit à l'OS qu'il a écrit, l'OS n'a aucun moyen de s'assurer que c'est vrai.
mmap est simplement un appel système. Il ne peut aller au delà des limitations et fonctionnalités de l'OS, du matériel et des pilotes.
La morale c'est que si on veut garantir la fiabilité absolue, il faut répliquer et garantir la continuité du courant. C'est possible, à 100%. Mais comme toujours, c'est une question de prix.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais surtout, le disque dur peut dire que la donnée être écrite alors que c'est faux.
Bien sûr, je sais qu'il ont même tendance à ne pas respecter le "write barrier" SATA, mais c'est lors de la relecture que tu te rend compte du problème.
Je comprends surtout que de toute façon, on ne peut rien face à un crash disque complet et qu'il faut pouvoir aussi gérer ce cas là.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par Kangs . Évalué à 2.
Oracle attaque un FS (les Raw Devices seront obsolètes en 12), la garantie d'écriture est faite avec les redo.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par Kangs . Évalué à 2.
[^] # Re: "base de données" ?
Posté par CrEv (site web personnel) . Évalué à 4.
(désolé ;) )
[^] # Re: "base de données" ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Redis propose deux modes. Dans le premier, il recopie de temps en temps tout ce qu'il a en mémoire vers le disque dur. Cela convient bien pour une utilisation de type 'cache' (si on perd les données entre deux écritures, ce n'est pas grave).
Dans le second mode, il va aller faire une écriture sur le disque systématiquement, et cette écriture se fait en mode append-only pour éviter tout risque de corruption du fichier. Cette technique est donc beaucoup plus fiable que la précédente, mais les performances sont nettement moindres.
J'aurais tendance à recommander Redis pour de nombreux usages, mais pas pour des données sensibles comme des informations bancaires.
[^] # Re: "base de données" ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A cause de l'absence de gestion de la persistance ?
Et si on rajoute un système par dessus Redis qui lancent des écriture dans plusieurs bases ?
"La première sécurité est la liberté"
[^] # Re: "base de données" ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Surtout parce que Redis est encore un produit assez jeune et que la réplication vient juste d'apparaître dans la version 2.0.
[^] # Re: "base de données" ?
Posté par Carl Chenet (site web personnel) . Évalué à 2.
Non, elle était déjà disponible.
[^] # Re: "base de données" ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
# Publish/Subscribe
Posté par Stéphane Gully (site web personnel) . Évalué à 2.
Je cherche en fait un remplaçant de ActiveMQ qui aurait de meilleurs performances (disque et CPU) sur des volumes de données de l'ordre de 10 millions de messages échangés par jours.
[^] # Re: Publish/Subscribe
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.