Sortie de Redis 2.0.0

Posté par (page perso) . Modéré par Mouns.
Tags :
12
6
sept.
2010
Base de données
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.

Les principales caractéristiques de Redis sont :

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.
  • # Défaut(s) ?

    Posté par (page perso) . Évalué à 10.

    Quand on parle de Redis, on cite toujours une grande quantité d'avantages par rapport à Memcached, mais quels sont ses défauts ?

    « 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 . Évalué à 8.

      Tiens, d'ailleurs ce serait intéressant de creuser la partie transaction. Quand je lis :
      (...) 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 (page perso) . Évalué à 5.

        > J'ai l'impression qu'il n'y a pas de notion de vérou par ligne/par clé

        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 . Évalué à -1.

      Tiens, d'ailleurs ce serait intéressant de creuser la partie transaction. Quand je lis :
      (...) 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 . Évalué à 3.

      Le gros manque de Redis par rapport à Membase est qu'il ne dispose pour l'instant que de réplication master/slave, pas encore de mode "cluster". C'est prévu pour la version 2.2. Mais il faut dire que les structures de données supportées par Redis rendent la tâche plus complexe que le modèle simple clef=valeur de Membase.

      À 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 . Évalué à 1.

        Désolé pour la confusion : JRedis est un *client* Java, compatible depuis peu avec Redis 2.0.

        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 . Évalué à 1.

        Un autre client Java compatible Redis 2.0 : [http://github.com/xetorthio/jedis]
  • # prout

    Posté par . Évalué à -10.

    en fait tu devrais monter rubyfr.org
    • [^] # Re: prout

      Posté par (page perso) . Évalué à 8.

      Heu, le site existe déjà (c'est le site de l'association Ruby France), et je suis également actif dessus. Par exemple, j'ai écrit la dernière dépêche sur le site (celle qui parle de Ruby 1.9.2). Mais je ne vois pas ce que cela vient faire ici. Cette dépêche parle de Redis, une base de données de type clé-valeur que l'on peut utiliser avec de nombreux langages : python, php, perl, java, erlang, clojure, scala, C, C#, javascript, Lua, Go, Haskell, Io et bien sûr Ruby (plus ceux que j'ai oublié).
    • [^] # Re: prout

      Posté par . Évalué à 5.

      Personnellement, je préfère la contribution pertinente et intéressante de quelqu'un qui connait son domaine que pas de contributions du tout, ou des dépêches à côté de la plaque.

      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 . Évalué à 8.

    "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) ;"

    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 (page perso) . Évalué à 2.

      Dans ce cas, aucune base de données ne peut garantir ce que tu espère, sans avoir accès directement au disque dur. Et là encore, il y aura un gros problème de performances.
      • [^] # Re: "base de données" ?

        Posté par . Évalué à 5.

        Elles font toute cela avec plus ou moins de bonheur.

        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 (page perso) . Évalué à 2.

          Sauf que tu place la base de données ne peut pas faire de miracle. Si le système lui dit que les données sont enregistrées, elle doit l'accepter. Mais nous savons qu'en réalité ce n'est pas le cas. C'est pourquoi la base de données ne doit pas être le seul élément à considérer dans la mise en place d'un système assurant l'intégrité du systèmes. Des logiciels au matériels, en ne se contentant pas de juste considérer les serveurs, mais aussi en prenant en compte l'infrastructure, les risques physiques et les infrastructures annexes.

          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 . Évalué à 2.

            Je veux bien croire que pour un cache, on se fout de perdre de temps en temps les données, mais concernant leur intégrité sur la base d'origine, j'ai du mal à comprendre.

            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 . Évalué à 2.

              Pour aller plus loin, est-ce qu'il existe une base no-sql qui garantie l'atomicité des mises à jour ?

              "La première sécurité est la liberté"

              • [^] # Re: "base de données" ?

                Posté par (page perso) . Évalué à 2.

                > Pour aller plus loin, est-ce qu'il existe une base no-sql qui garantie l'atomicité des mises à jour ?

                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 (page perso) . Évalué à 3.

              Pour une application comme Farmville, on s'en cogne de la fiabilité des informations du jeu. Ce qui est important, c'est la réactivité du jeu, et que l'expérience soit agréable. Et pourtant, ils ont des données persistantes.

              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 . Évalué à 2.

                Sur un jeu, tu considères ok, de perdre toute la base, depuis la dernière sauvegarde.

                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 (page perso) . Évalué à 2.

                  Dans le cas du jeu, avec une base SQL tu as le même problème. Si ta base crash en plein milieu de la transaction pour sauvegarder, ben tu reviens à la dernière sauvegarde aussi. Sauf que SQL te garantit que ta dernière sauvegarde va être consistante.
                  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 . Évalué à 1.

                    Tu veux dire que si il y a une coupure de courant au court d'une écriture d'une base SQL celle-ci ne va pas se réparer toute seul au redémarrage : j'ai un gros doute !

                    "La première sécurité est la liberté"

                    • [^] # Re: "base de données" ?

                      Posté par (page perso) . Évalué à 3.

                      Comme quoi tu parles vraiment de choses que tu ne connais pas. Le principe d'une transaction, c'est de garantir qu'une transaction réussie le soit atomiquement. une base de données peut garantir qu'en cas de crash, une récupération de la base de données sera cohérente. En aucun cas une base de données peut promettre de tout récupérer en cas de crash. Et ce dans la limite des promesses de l'OS. Une base de données SQL ce n'est pas magique.

                      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 . Évalué à 2.

                        C'est là que je vois que je viens du hard :) Quand je vois un softeux qui croit que le hard peut tout faire :)

                        "La première sécurité est la liberté"

                        • [^] # Re: "base de données" ?

                          Posté par (page perso) . Évalué à 3.

                          Ah non, je n'ai pas dit que le hard peut tout. Au contraire, ce sont les limitations hardware qui font les limitations logicielles. Ceci dit, en blindant en considérant l'architecture dans l'ensemble, on peut se prémunir de la plupart des incidents. Ensuite, vouloir la fiabilité de sa base de données même sous le feu nucléaire, c'est illusoire :p
                          • [^] # Re: "base de données" ?

                            Posté par . Évalué à 2.

                            Disons qu'une coupure de courant, cela flingue le secteur de 4k en cours d'écriture sur un disque. On peut imaginer un tas de schéma qui gère cela. J'étais persuadé que c'était le cas, comme pour les FS (les système de log, de soft update, de journalisation).

                            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 (page perso) . Évalué à 3.

                              Non, une coupure de courant ne flingue rien. Et je ne comprend pas cette référence un secteur de 4k. Tout d'abord, les disques durs dont encore et toujours calibrés sur des blocs ridicule de 512ko. Il y a une nouvelle génération de disques durs avec des blocs plus gros, mais c'est tellement neuf que Linux a à peine intégré leur support il y a quelques mois.

                              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 . Évalué à 2.

                                Les disques dures fonctionnent à 4k depuis longtemps, mais il n'affiche cela que depuis très récemment. De plus, Linux aiment bien travailler avec des multiples de la taille de page, donc, je ne serais pas étonné qu'il est tendance à faire des écritures de 4ko en taille mini.

                                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 . Évalué à 2.

          >>Oracle attaque directement en RAW et gère sont propres caches.
          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 (page perso) . Évalué à 2.

      > Est-ce que j'ai réellement bien compris le système de "persistance" ?

      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 . Évalué à 2.

        J'aurais tendance à recommander Redis pour de nombreux usages, mais pas pour des données sensibles comme des informations bancaires.

        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é"

  • # Publish/Subscribe

    Posté par (page perso) . Évalué à 2.

    La fonctionnalité Publish/Subscribe monte elle à l'échelle ? (pas de jeux de mots hein :p)

    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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.