Memcached contre Redis?
Nous utilisons une application web Ruby avec un serveur Redis pour la mise en cache. Y at-il un point à tester Memcached à la place?
Qu'est-ce qui nous donnera une meilleure performance? Des avantages ou des inconvénients entre Redis et Memcached?
Points à considérer:
- Vitesse de lecture/écriture.
- Utilisation de la mémoire.
- Dumping I/O disque.
- Mise à l'échelle.
Résumé (TL; DR)
Mis à jour le 3 juin 2017
Redis est plus puissant, plus populaire et mieux supporté que memcached. Memcached ne peut faire qu'une petite fraction de ce que Redis peut faire. Redis est meilleur même lorsque leurs caractéristiques se chevauchent.
Pour tout ce qui est nouveau, utilisez Redis.
Memcached contre Redis: Comparaison directe
Les deux outils sont des magasins de données puissants, rapides et en mémoire qui sont utiles en tant que cache. Les deux peuvent contribuer à accélérer votre application en mettant en cache les résultats de la base de données, les fragments HTML ou tout autre élément susceptible d'être coûteux à générer.
Points à considérer
Quand ils sont utilisés pour la même chose, voici comment ils comparent en utilisant les "Points à prendre en compte" de la question initiale:
- Vitesse de lecture/écriture : les deux sont extrêmement rapides. Les points de repère varient en fonction de la charge de travail, des versions et de nombreux autres facteurs, mais montrent généralement que redis est aussi rapide ou presque aussi rapide que memcached. Je recommande redis, mais pas parce que memcached est lent. Ce n'est pas.
- Utilisation de la mémoire : Redis est meilleur.
- memcached: vous spécifiez la taille du cache et au fur et à mesure que vous insérez des éléments, le démon augmente rapidement pour atteindre un peu plus que cette taille. Il n'y a jamais vraiment moyen de récupérer tout cet espace, à moins de redémarrer memcached. Toutes vos clés pourraient être expirées, vous pourriez vider la base de données et utiliser le bloc complet de RAM avec lequel vous l'avez configuré.
- redis: Vous définissez une taille maximale. Redis n'en utilisera jamais plus que nécessaire et vous redonnera de la mémoire qu'il n'utilise plus.
- J'ai stocké 100 000 ~ 2 Ko de chaînes (~ 200 Mo) de phrases aléatoires dans les deux. L'utilisation de Memcached RAM est passée à ~ 225 Mo. L’utilisation de Redis RAM est passée à environ 228 Mo. Après avoir nettoyé les deux, Redis est tombé à ~ 29 Mo et le nombre de membres restés à ~ 225 Mo Ils stockent les données avec la même efficacité, mais un seul est capable de les récupérer.
- Vidage des E/S du disque : Un gain évident pour redis car il le fait par défaut et a une persistance très configurable. Memcached ne dispose d'aucun mécanisme permettant de basculer sur le disque sans outils tiers.
- Mise à l'échelle : les deux vous offrent une marge de sécurité considérable avant que vous ayez besoin de plus d'une instance en tant que cache. Redis inclut des outils pour vous aider à aller au-delà de ce que memcached ne fait pas.
memcached
Memcached est un simple serveur de cache volatile. Il vous permet de stocker des paires clé/valeur dans lesquelles la valeur est limitée à une chaîne pouvant atteindre 1 Mo.
C'est bon pour ça, mais c'est tout ce que ça fait. Vous pouvez accéder à ces valeurs avec leur clé à une vitesse extrêmement élevée, saturant souvent le réseau disponible ou même la bande passante mémoire.
Lorsque vous redémarrez memcached, vos données ont disparu. C'est bon pour une cache. Vous ne devriez rien y conserver d’important.
Si vous avez besoin de performances élevées ou d'une haute disponibilité, des outils, produits et services tiers sont disponibles.
redis
Redis peut faire le même travail que memcached et peut mieux le faire.
Redis peut faire office de cache également. Il peut également stocker des paires clé/valeur. Dans Redis, ils peuvent même atteindre 512Mo.
Vous pouvez désactiver la persistance et il perdra également vos données au redémarrage. Si vous voulez que votre cache survive aux redémarrages, cela vous permet également de le faire. En fait, c'est le défaut.
C'est très rapide aussi, souvent limité par la bande passante réseau ou mémoire.
Si une instance de redis/memcached n’est pas assez performante pour votre charge de travail, redis est le choix évident. Redis inclut prise en charge de cluster et est livré avec des outils de haute disponibilité ( redis-sentinel ) à droite "dans la boîte". Au cours des dernières années, Redis s'est également imposé comme le leader incontesté de l'outillage tiers. Des entreprises telles que Redis Labs, Amazon et d’autres offrent de nombreux outils et services redis utiles. L’écosystème autour de Redis est beaucoup plus vaste. Le nombre de déploiements à grande échelle est maintenant probablement supérieur à celui de memcached.
Le super-ensemble de Redis
Redis est plus qu'un cache. C'est un serveur de structure de données en mémoire. Vous trouverez ci-dessous un aperçu rapide de ce que Redis peut faire au-delà d’un simple cache clé/valeur comme memcached. La plupart des fonctionnalités de redis sont des choses que memcached ne peut pas faire.
Documentation
Redis est mieux documenté que memcached. Bien que cela puisse être subjectif, cela semble être de plus en plus vrai tout le temps.
redis.io est une fantastique ressource facilement navigable. Il vous laisse essayez redis dans le navigateur et vous donne même des exemples interactifs en direct avec chaque commande de la documentation.
Il y a maintenant 2 fois autant de résultats de stackoverflow pour redis que pour memcached. 2x autant de résultats Google. Des exemples plus facilement accessibles dans plus de langues. Développement plus actif. Développement client plus actif. Ces mesures ne signifient peut-être pas grand-chose individuellement, mais combinées, elles donnent une idée claire du fait que le support et la documentation de redis sont meilleurs et beaucoup plus à jour.
persistance
Par défaut, Redis conserve vos données sur le disque en utilisant un mécanisme appelé capture instantanée. Si vous disposez de suffisamment de RAM, il est en mesure d'écrire toutes vos données sur le disque sans dégradation des performances. C'est presque gratuit!
En mode Snapshot, il est possible qu'un crash soudain entraîne une petite quantité de données perdues. Si vous avez absolument besoin de vous assurer qu'aucune donnée n'est jamais perdue, ne vous inquiétez pas, redis vous soutient également en mode AOF (Ajout d'un fichier seulement). Dans ce mode de persistance, les données peuvent être synchronisées sur le disque au moment de son écriture. Cela peut réduire le débit d’écriture maximum, quelle que soit la vitesse d’écriture de votre disque, mais devrait néanmoins être assez rapide.
Il existe de nombreuses options de configuration pour ajuster la persistance si nécessaire, mais les valeurs par défaut sont très judicieuses. Ces options facilitent la configuration de redis en tant qu’emplacement sécurisé et redondant pour le stockage des données. C'est une base de données réelle .
Beaucoup de types de données
Memcached est limité à des chaînes, mais Redis est un serveur de structure de données qui peut servir de nombreux types de données. Il fournit également les commandes dont vous avez besoin pour tirer le meilleur parti de ces types de données.
Chaînes ( commandes )
Texte simple ou valeurs binaires pouvant atteindre 512 Mo en taille. C'est le seul type de données redis et memcached share, bien que les chaînes memcached soient limitées à 1 Mo.
Redis vous donne plus d'outils pour exploiter ce type de données en proposant des commandes pour les opérations sur les bits, la manipulation au niveau des bits, la prise en charge de l'incrément/décrémentation en virgule flottante, les requêtes de plage et les opérations multi-clés. Memcached ne supporte rien de tout ça.
Les chaînes sont utiles pour toutes sortes de cas d'utilisation, c'est pourquoi memcached est plutôt utile avec ce type de données uniquement.
Hashs ( commandes )
Les hachages sont un peu comme un magasin de valeurs de clés dans un magasin de valeurs de clés. Ils mappent entre les champs de chaîne et les valeurs de chaîne. Les cartes de champ> valeur utilisant un hachage sont légèrement plus efficaces en termes d'espace que les cartes clé-> valeur utilisant des chaînes ordinaires.
Les hachages sont utiles en tant qu'espace de noms ou lorsque vous souhaitez grouper logiquement plusieurs clés. Avec un hachage, vous pouvez saisir efficacement tous les membres, faire expirer tous les membres ensemble, supprimer tous les membres ensemble, etc. Idéal pour tous les cas d'utilisation dans lesquels plusieurs paires clé/valeur doivent être regroupées.
Un exemple d'utilisation d'un hachage est de stocker des profils d'utilisateurs entre des applications. Une redishash stockée avec l'ID utilisateur en tant que clé vous permettra de stocker autant de bits de données sur un utilisateur que nécessaire tout en les conservant sous une clé unique. L'avantage d'utiliser un hachage au lieu de sérialiser le profil dans une chaîne est que vous pouvez avoir différentes applications lire/écrire différents champs dans le profil utilisateur sans avoir à vous soucier des modifications apportées par une autre application (ce qui peut arriver si vous sérialisez périmé Les données).
Listes ( commandes )
Les listes Redis sont des collections ordonnées de chaînes. Ils sont optimisés pour l'insertion, la lecture ou la suppression de valeurs en haut ou en bas de la liste.
Redis propose de nombreuses commandes pour tirer parti des listes, notamment des commandes pour les éléments Push/Pop, Push/Pop entre les listes, les listes tronquées, les requêtes de plage, etc.
Les listes créent de grandes files d'attente, atomiques et durables. Celles-ci fonctionnent très bien pour les files d'attente, les journaux, les mémoires tampons et de nombreux autres cas d'utilisation.
Ensembles ( commandes )
Les ensembles sont des collections non ordonnées de valeurs uniques. Ils sont optimisés pour vous permettre de vérifier rapidement si une valeur est dans le jeu, d'ajouter/de supprimer rapidement des valeurs et de mesurer le chevauchement avec d'autres jeux.
Celles-ci sont idéales pour des choses comme les listes de contrôle d'accès, les suivis de visiteurs uniques et bien d'autres choses. La plupart des langages de programmation ont quelque chose de similaire (généralement appelé un ensemble). C'est comme ça, seulement distribué.
Redis fournit plusieurs commandes pour gérer les ensembles. Celles évidentes telles que l'ajout, la suppression et la vérification de l'ensemble sont présentes. Il en va de même pour les commandes moins évidentes telles que sauter/lire un élément aléatoire et les commandes permettant de réaliser des unions et des intersections avec d'autres ensembles.
Ensembles triés ( commandes )
Les ensembles triés sont également des collections de valeurs uniques. Ceux-ci, comme leur nom l'indique, sont ordonnés. Ils sont classés par score, puis lexicographiquement.
Ce type de données est optimisé pour les recherches rapides par score. Obtenir les valeurs les plus hautes, les plus basses ou toutes les valeurs intermédiaires est extrêmement rapide.
Si vous ajoutez des utilisateurs à un ensemble trié avec leur meilleur score, vous avez un tableau de bord parfait. Au fur et à mesure que de nouveaux meilleurs scores entrent, ajoutez-les simplement à l'ensemble avec leur meilleur score et il réorganisera votre classement. Idéal également pour garder la trace de la dernière fois que les utilisateurs ont visité et qui est actif dans votre application.
Le stockage de valeurs avec le même score entraîne leur classement lexicographique (pensez par ordre alphabétique). Cela peut être utile pour des choses comme les fonctionnalités de saisie semi-automatique.
La plupart des ensembles triés commandes sont similaires aux commandes des ensembles, parfois avec un paramètre de score supplémentaire. Des commandes pour la gestion des partitions et l'interrogation par partition sont également incluses.
Géo
Redis a plusieurs commandes pour stocker, récupérer et mesurer des données géographiques. Cela inclut les requêtes de rayon et les distances de mesure entre les points.
Techniquement, les données géographiques dans redis sont stockées dans des ensembles triés. Il ne s'agit donc pas d'un type de données vraiment séparé. Il s’agit plus d’une extension par-dessus des ensembles triés.
Bitmap et HyperLogLog
Comme geo, ces types de données ne sont pas complètement séparés. Ce sont des commandes qui vous permettent de traiter les données de chaîne comme s’il s’agissait d’un bitmap ou d’un hyperloglog.
Les bitmaps correspondent aux opérateurs de niveau binaire que j'ai référencés sous Strings. Ce type de données était la pierre angulaire du récent projet d'art collaboratif de reddit: r/Place .
HyperLogLog vous permet d'utiliser une quantité d'espace extrêmement constante pour compter des valeurs uniques presque illimitées avec une précision choquante. En utilisant seulement ~ 16 Ko, vous pouvez compter efficacement le nombre de visiteurs uniques sur votre site, même si ce nombre se chiffre en millions.
Transactions et Atomicité
Les commandes dans redis sont atomiques, ce qui signifie que vous pouvez être sûr que dès que vous écrivez une valeur dans redis, cette valeur est visible par tous les clients connectés à redis. Il n'y a pas d'attente pour que cette valeur se propage. Techniquement, memcached est également atomique, mais avec l’ajout de toutes ces fonctionnalités au-delà de memcached, il est intéressant de noter et plutôt impressionnant que tous ces types de données et fonctionnalités supplémentaires sont également atomiques.
Bien que différent des transactions dans les bases de données relationnelles, redis a également transactions qui utilise le "verrouillage optimiste" ( WATCH / MULTI / EXEC ).
Pipelining
Redis fournit une fonctionnalité appelée ' pipelining '. Si vous souhaitez exécuter plusieurs commandes redis, vous pouvez utiliser le traitement en pipeline pour les envoyer à redis tout-en-une fois au lieu de une à la fois.
Normalement, lorsque vous exécutez une commande avec redis ou avec memcached, chaque commande constitue un cycle requête/réponse distinct. Avec le traitement en pipeline, redis peut mettre en tampon plusieurs commandes et les exécuter toutes en même temps, en répondant avec toutes les réponses à toutes vos commandes en une seule réponse.
Cela peut vous permettre d’obtenir un débit encore plus élevé lors d’importations en bloc ou lors d’autres actions impliquant de nombreuses commandes.
Pub/Sub
Redis a commandes dédié à fonctionnalité pub/sub , ce qui permet à Redis de jouer le rôle de diffuseur de messages à haute vitesse. Cela permet à un seul client de publier des messages sur de nombreux autres clients connectés à un canal.
Redis fait des pub/sub ainsi que presque n'importe quel outil. Des courtiers de messages dédiés tels que RabbitMQ peuvent présenter des avantages dans certains domaines, mais le fait que le même serveur puisse également générer des files d'attente durables persistantes et d'autres structures de données dont votre charge de travail pub/sous a probablement besoin, Redis se révélera souvent utile. être l'outil le meilleur et le plus simple pour le travail.
Lua Scripting
Vous pouvez en quelque sorte penser à scripts lua comme le propre SQL ou les procédures stockées de Redis. C'est à la fois plus et moins que cela, mais l'analogie fonctionne généralement.
Peut-être avez-vous des calculs complexes que vous souhaitez que Redis effectue. Vous ne pouvez peut-être pas vous permettre de réduire vos transactions et avez besoin de garanties chaque étape d'un processus complexe se déroulera de manière atomique. Ces problèmes et beaucoup d’autres peuvent être résolus avec les scripts Lua.
Le script entier est exécuté de manière atomique. Par conséquent, si vous pouvez adapter votre logique à un script Lua, vous pouvez souvent éviter de jouer avec des transactions de verrouillage optimistes.
Mise à l'échelle
Comme mentionné ci-dessus, redis inclut un support intégré pour la mise en cluster et est fourni avec son propre outil de haute disponibilité appelé redis-sentinel.
Conclusion
Sans hésiter, je recommanderais redis over memcached pour tout nouveau projet ou pour les projets existants qui n'utilisent pas déjà memcached.
Cela peut sembler comme si je n'aimais pas memcached. Au contraire: c’est un outil puissant, simple, stable, mature et durci. Il y a même des cas d'utilisation où c'est un peu plus rapide que redis. J'aime memcached. Je ne pense tout simplement pas que cela ait beaucoup de sens pour le développement futur.
Redis fait tout ce que memcached fait, souvent mieux. Tout avantage en termes de performances pour memcached est mineur et spécifique à la charge de travail. Il existe également des charges de travail pour lesquelles redis sera plus rapide, et de nombreuses charges de travail que redis peut faire que memcached ne peut tout simplement pas faire. Les différences de performances minimes semblent mineures face au gouffre de fonctionnalités et au fait que les deux outils sont si rapides et efficaces qu'ils pourraient bien être le dernier élément de votre infrastructure que vous aurez à vous soucier de la mise à l'échelle.
Il n'y a qu'un seul scénario où memcached est plus logique: où memcached est déjà utilisé comme cache. Si vous avez déjà mis en cache avec memcached, continuez à l’utiliser, si cela répond à vos besoins. Passer à Redis ne vaut probablement pas la peine. Si vous comptez utiliser Redis uniquement pour la mise en cache, il se peut que vous n'ayez pas suffisamment d'avantages pour valoir votre temps. Si memcached ne répond pas à vos besoins, vous devriez probablement passer à redis. Cela est vrai que vous ayez besoin d'une évolutivité au-delà de memcached ou de fonctionnalités supplémentaires.
Utilisez Redis si
Vous avez besoin de supprimer/expirer de manière sélective des éléments dans le cache. (Tu en as besoin)
Vous avez besoin de la possibilité d'interroger des clés d'un type particulier. éq. 'blog1: posts: *', 'blog2: catégories: xyz: posts: *'. Oh oui! c'est très important. Utilisez cette option pour invalider certains types d’éléments mis en cache de manière sélective. Vous pouvez également l'utiliser pour invalider le cache de fragments, le cache de pages, uniquement les objets AR d'un type donné, etc.
Persistance (vous en aurez aussi besoin, à moins que votre cache ne soit obligé de se réchauffer après chaque redémarrage. Très essentiel pour les objets qui changent rarement)
Utilisez memcached si
- Memcached vous donne la tête!
- euh ... clustering? meh. si vous voulez aller aussi loin, utilisez Varnish et Redis pour mettre en cache des fragments et des objets AR.
D'après mon expérience, la stabilité avec Redis est bien meilleure que celle de Memcached
Memcached est multithread et rapide.
Redis a beaucoup de fonctionnalités et est très rapide, mais complètement limité à un seul cœur car il est basé sur une boucle d’événement.
Nous utilisons les deux. Memcached est utilisé pour mettre en cache des objets, réduisant principalement la charge de lecture sur les bases de données. Redis est utilisé pour des tâches telles que les ensembles triés, ce qui est pratique pour la compilation de données chronologiques.
Ceci est trop long pour être posté en tant que commentaire à une réponse déjà acceptée, je le mets donc en tant que réponse séparée
Vous devez également déterminer si vous pensez avoir une limite de mémoire supérieure stricte sur votre instance de cache.
Puisque redis est une base de données nosql avec une multitude de fonctionnalités et que la mise en cache n’est qu’une des options pour lesquelles elle peut être utilisée, elle alloue de la mémoire selon ses besoins - plus vous insérez d’objets, plus elle utilise de mémoire. L'option maxmemory n'applique pas strictement l'utilisation de la limite de mémoire supérieure. Lorsque vous travaillez avec le cache, les clés sont expulsées et expirées. Il est fort probable que vos clés n’ont pas toutes la même taille, ce qui entraîne une fragmentation de la mémoire interne.
Par défaut, redis utilise jemalloc allocateur de mémoire, qui tente de son mieux d’être à la fois compacte et rapide en mémoire, mais c’est un allocateur de mémoire à usage général qui ne peut pas faire face à de nombreuses affectations et purges d’objets se produisant un taux élevé. De ce fait, sur certains modèles de charge, le processus redis peut apparemment perdre de la mémoire en raison de la fragmentation interne. Par exemple, si vous avez un serveur avec 7 Gb RAM et que vous souhaitez utiliser redis en tant que cache LRU non persistant, vous pouvez constater que le processus Redis avec maxmemory défini sur 5 Gb au fil du temps utiliserait de plus en plus de mémoire, atteignant finalement la limite totale RAM jusqu'à ce que le tueur insuffisant de la mémoire interfère.
memcached correspond mieux au scénario décrit ci-dessus, car il gère sa mémoire d'une manière complètement différente. memcached alloue un gros bloc de mémoire - tout ce dont il aura besoin - et gère ensuite cette mémoire elle-même, en utilisant sa propre implémentation slab allocator . En outre, memcached s'efforce de limiter la fragmentation interne, car elle utilise tilise l'algorithme LRU par dalle lorsque les expulsions de LRU sont effectuées en tenant compte de la taille de l'objet.
Cela dit, memcached occupe toujours une position importante dans les environnements où l’utilisation de la mémoire doit être imposée et/ou prévisible. Nous avons essayé d'utiliser la dernière version stable de Redis (2.8.19) comme solution de remplacement sans mémoire basée sur des LRU non persistantes dans une charge de travail de 10-15k op/s, ce qui a entraîné une perte de mémoire importante; la même charge de travail bloquait les instances ElastiCache redis d'Amazon en un jour ou deux pour les mêmes raisons.
Memcached est bon pour être un simple magasin de clé/valeur et pour faire clé => STRING. Cela le rend vraiment bon pour le stockage de session.
Redis sait bien faire la clé => SOME_OBJECT.
Cela dépend vraiment de ce que vous allez mettre là-bas. D'après ce que j'ai compris, leurs performances sont plutôt égales.
Aussi, bonne chance pour trouver des repères objectifs, si vous en trouvez, envoyez-les moi gentiment.
Si vous ne craignez pas un style d'écriture grossier, Redis vs Memcached sur le blog Systoilet mérite une lecture du point de vue de la convivialité, mais assurez-vous de lire le texte dans les commentaires avant de tirer des conclusions. sur la performance; il y a quelques problèmes méthodologiques (tests de boucle occupée à un seul thread), et Redis a également apporté des améliorations depuis la rédaction de cet article.
Et aucun lien de référence n'est complet sans confondre un peu les choses, alors jetez également un coup d'œil à certains repères contradictoires sur LiveJournal de Dormondo et le blog Web Antirez .
Edit - comme le souligne Antirez, l'analyse de Systoilet est plutôt mal conçue. Même au-delà du manque de thread unique, une grande partie de la disparité des performances entre ces tests de performance peut être attribuée aux bibliothèques clientes plutôt qu'au débit du serveur. Les repères sur le blog Antirez présentent en effet une comparaison beaucoup plus nette de pommes à pommes (avec la même bouche).
J'ai eu l'occasion d'utiliser memcached et redis ensemble dans le proxy de mise en cache sur lequel j'ai travaillé, laissez-moi vous dire où exactement j'ai utilisé quoi et raison derrière la même ....
Redis>
1) Utilisé pour l'indexation du contenu du cache, sur le cluster. J'ai plus d'un milliard de clés réparties sur des clusters redis, les temps de réponse de redis sont nettement inférieurs et stables.
2) En gros, c’est un magasin de clé/valeur, de sorte que partout dans votre application vous avez quelque chose de similaire, on peut utiliser redis avec beaucoup de peine.
3) La persistance, le basculement et la sauvegarde (AOF) de Redis faciliteront votre tâche.
Memcache>
1) oui, une mémoire optimisée pouvant être utilisée en cache. Je l'ai utilisé pour stocker du contenu en cache auquel on accède très fréquemment (avec 50 hits/seconde) avec une taille inférieure à 1 Mo.
2) Je n'ai alloué que 2 Go sur 16 Go à memcached lorsque la taille de mon contenu était> 1 Mo.
3) Lorsque le contenu se rapproche des limites, j'ai parfois observé des temps de réponse plus élevés dans les statistiques (pas le cas de redis).
Si vous demandez une expérience globale, Redis est beaucoup plus écologique car facile à configurer, beaucoup plus flexible avec des fonctionnalités robustes et stables.
En outre, il existe un résultat de référence disponible sur ce lien , ci-dessous quelques points saillants de la même chose,
J'espère que cela t'aides!!
Un autre avantage est que le comportement de memcache dans un scénario de mise en cache peut être très clair, alors que redis est généralement utilisé comme magasin de données persistant, bien qu'il puisse être configuré pour se comporter exactement comme memcache, c'est-à-dire expulser les éléments les moins récemment utilisés lorsqu'il atteint la valeur maximale. capacité.
Certaines applications sur lesquelles j'ai travaillé utilisent à la fois simplement pour préciser la manière dont nous voulons que les données se comportent - tout dans memcache, nous écrivons du code pour gérer les cas où il n'est pas là - tout dans Redis, nous comptons sur sa présence .
Autre que cela, Redis est généralement considéré comme supérieur pour la plupart des cas d'utilisation étant plus riche en fonctionnalités et donc plus flexible.
Tester. Exécutez quelques repères simples. Pendant longtemps, je me suis considéré comme un rhinocéros de la vieille école, étant donné que j’utilisais principalement le memcache et que je considérais Redis comme le nouvel enfant.
Avec ma société actuelle, Redis a été utilisé comme cache principal. Lorsque je me suis plongé dans des statistiques de performances et que j'ai tout simplement commencé à tester, Redis était, en termes de performances, comparable ou minime plus lent que MySQL.
Memcached, bien que simpliste, a fait sauter Redis de l’eau totalement. Il a beaucoup mieux évolué:
- pour des valeurs plus grandes (changement requis dans la taille de la dalle, mais travaillé)
- pour plusieurs demandes simultanées
De plus, à mon avis, la politique d’expulsion de memcached est bien mieux mise en œuvre, ce qui se traduit par un temps de réponse moyen globalement plus stable tout en traitant plus de données que le cache ne peut en gérer.
Une analyse comparative a révélé que Redis, dans notre cas, fonctionne très mal. Je pense que cela a à voir avec beaucoup de variables:
- type de matériel sur lequel vous exécutez Redis
- types de données que vous stockez
- quantité de va et vient
- comment votre application est concurrente
- avez-vous besoin d'un stockage de structure de données
Personnellement, je ne partage pas l'opinion des auteurs Redis sur la simultanéité et le multithreading.
Ce ne serait pas faux si nous disons que redis est une combinaison de (cache + structure de données) alors que memcached est juste un cache.
Une différence majeure qui n’a pas été soulignée ici est que Memcache a toujours une limite de mémoire supérieure, alors que Redis ne l’a pas par défaut (mais peut être configuré pour). Si vous souhaitez toujours stocker une clé/valeur pendant un certain temps (et ne jamais l'expulser en raison d'une mémoire insuffisante), vous souhaitez utiliser Redis. Bien sûr, vous risquez également de manquer de mémoire ...
Un test très simple pour définir et obtenir 100 000 clés et valeurs uniques contre redis-2.2.2 et memcached. Les deux s'exécutent sur une machine virtuelle Linux (CentOS) et mon code client (collé ci-dessous) s'exécute sur le bureau Windows.
Redis
Le temps nécessaire pour stocker 100 000 valeurs est = 18954ms
Le temps nécessaire pour charger 100 000 valeurs est = 18328ms
Memcached
Le temps nécessaire pour stocker 100 000 valeurs est = 797ms
Le temps nécessaire pour récupérer 100000 valeurs est = 38984ms
Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");
startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");
Nous avons pensé à Redis comme une charge utile pour notre projet au travail. Nous pensions qu'en utilisant un module dans nginx appelé HttpRedis2Module ou quelque chose de similaire, nous aurions une vitesse impressionnante, mais lorsque nous avons testé AB-test, nous nous sommes trompés.
Le module était peut-être mauvais ou notre présentation, mais c'était une tâche très simple et il était encore plus rapide de prendre des données avec php, puis de les fourrer dans MongoDB. Nous utilisons APC comme système de cache et avec php et MongoDB. C'était beaucoup plus rapide que le module nginx Redis.
Mon conseil est de le tester vous-même, le faire vous montrera les résultats pour votre environnement. Nous avons décidé que l’utilisation de Redis n’était pas nécessaire dans notre projet car cela n’aurait aucun sens.
La plus grande raison qui reste est la spécialisation.
Redis peut faire beaucoup de choses différentes et un effet secondaire de cela est que les développeurs peuvent commencer à utiliser beaucoup de ces différents ensembles de fonctionnalités sur la même instance. Si vous utilisez la fonction LRU de Redis pour une mémoire cache qui n'est PAS une LRU, il est tout à fait possible de manquer de mémoire.
Si vous souhaitez configurer une instance Redis dédiée à utiliser UNIQUEMENT en tant qu'instance LRU afin d'éviter ce scénario particulier, il n'existe aucune raison impérieuse d'utiliser Redis sur Memcached.
Si vous avez besoin d'un cache LRU fiable "ne tombe jamais en panne" ... Memcached fera l'affaire, car il est impossible qu'il manque de mémoire par conception et la fonctionnalité de spécialisation empêche les développeurs d'essayer de le transformer en quelque chose qui pourrait mettre cela en danger. Séparation simple des préoccupations.
Memcached sera plus rapide si les performances vous intéressent, même parce que Redis implique la mise en réseau (appels TCP). Memcache est également plus rapide en interne.
Redis a plus de fonctionnalités que cela a été mentionné par d'autres réponses.
Redis est meilleur.
Les avantages de Redis sont,
- Il a beaucoup d'options de stockage de données telles que chaîne, ensembles, ensembles triés, hachages, bitmaps
- Persistance du disque des enregistrements
- Procédure stockée (
LUAscripting) supporté - Peut agir en tant que courtier de messages à l'aide de PUB/SUB
Alors que Memcache est un système de type cache de valeur de clé en mémoire.
- Pas de support pour divers stockages de types de données tels que des listes, des ensembles comme dans redis.
- Le principal inconvénient est que Memcache n'a pas de persistance sur le disque.
Ici est le très bon article/différences fourni par Amazon
Redis est un gagnant clair comparant à memcached.
Un seul point positif pour Memcached est multithread et rapide. Redis a beaucoup de fonctionnalités intéressantes et est très rapide, mais limité à un noyau.
Eh bien, j'ai surtout utilisé les deux avec mes applications, Memcache pour mettre en cache les sessions et redis pour les objets doctrine/orm. En termes de performance, les deux sont presque identiques.