Question Memcached vs. Redis?


Nous utilisons une application web Ruby avec Redis serveur pour la mise en cache. Y a-t-il un point à tester Memcached au lieu?

Qu'est-ce qui nous donnera de meilleures performances? Des avantages ou des inconvénients entre Redis et Memcached?

Points à considérer:

  • Lecture / écriture vitesse.
  • Utilisation de la mémoire.
  • Déversement d'E / S de disque.
  • Mise à l'échelle.

1136
2018-05-11 20:52


origine


Réponses:


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 partie des choses que Redis peut faire. Redis est meilleur même lorsque leurs caractéristiques se chevauchent.

Pour tout ce qui est nouveau, utilisez Redis.

Memcached vs Redis: Comparaison directe

Les deux outils sont des banques de données en mémoire puissantes, rapides et utiles en tant que cache. Les deux peuvent vous aider à 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

Lorsqu'ils sont utilisés pour la même chose, voici comment ils se comparent en utilisant les «points à considérer» de la question originale:

  • Lire / écrire vitesse: Les deux sont extrêmement rapides. Les benchmarks varient en fonction de la charge de travail, des versions et de nombreux autres facteurs, mais ils se montrent généralement aussi rapides ou presque aussi rapides que ceux de memcached. Je recommande redis, mais pas parce que memcached est lent. Ce n'est pas.
  • Utilisation de la mémoire: Redis c'est mieux.
    • memcached: Vous spécifiez la taille du cache et, au fur et à mesure que vous insérez des éléments, le démon atteint rapidement un peu plus que cette taille. Il n'y a jamais vraiment un moyen de récupérer tout cet espace, à moins de redémarrer memcached. Toutes vos clés peuvent être expirées, vous pouvez vider la base de données, et il utilisera toujours le bloc complet de RAM avec lequel vous l'avez configuré.
    • redis: Définir une taille maximale dépend de vous. Redis n'utilisera jamais plus qu'il ne le fait et vous redonnera de la mémoire qu'il n'utilise plus.
    • J'ai stocké 100 000 ~ 2KB chaînes (~ 200MB) de phrases aléatoires dans les deux. L'utilisation de la mémoire Memcached est passée à ~ 225 Mo. L'utilisation de la mémoire Redis est passée à ~ 228 Mo. Après avoir rincé les deux, redis est tombé à ~ 29 Mo et memcached est resté à ~ 225 Mo. Ils sont également efficaces dans la façon dont ils stockent les données, mais un seul est capable de les récupérer.
  • Déversement d'E / S disque: Une victoire claire pour redis car elle le fait par défaut et a une persistance très configurable. Memcached ne dispose pas de mécanismes pour le déchargement sur disque sans outils tiers.
  • Mise à l'échelle: Les deux vous donnent des tonnes de marge avant d'avoir besoin de plus d'une seule instance en cache. Redis inclut des outils pour vous aider à aller au-delà de cela, contrairement à memcached.

memcached

Memcached est un simple serveur de cache volatile. Il vous permet de stocker des paires clé / valeur où la valeur est limitée à une chaîne de 1 Mo maximum.

C'est bon, mais c'est tout ce qu'il fait. Vous pouvez accéder à ces valeurs par leur clé à très haute vitesse, saturant souvent réseau disponible ou même la bande passante mémoire.

Lorsque vous redémarrez memcached vos données ont disparu. C'est bien pour un cache. Vous ne devriez pas stocker quelque chose d'important là-bas.

Si vous avez besoin de hautes performances ou de haute disponibilité, des outils, produits et services tiers sont disponibles.

Redis

Redis peut faire les mêmes tâches que Memcached et peut mieux les faire.

Redis peut agir comme cache ainsi que. Il peut également stocker des paires clé / valeur. En redis, ils peuvent même atteindre 512 Mo.

Vous pouvez désactiver la persistance et il va heureusement perdre vos données au redémarrage aussi. Si vous voulez que votre cache survive au redémarrage, vous pouvez le faire également. En fait, c'est la valeur par défaut.

C'est aussi super rapide, souvent limité par la bande passante du réseau ou de la mémoire.

Si une instance de redis / memcached n'est pas assez performante pour votre charge de travail, redis est le bon choix. Redis comprend support de cluster et est livré avec des outils à haute disponibilité (redis-sentinelle) à droite "dans la boîte". Au cours des dernières années, redis est également devenu le leader incontesté de l'outillage de tiers. Des sociétés comme Redis Labs, Amazon et d'autres offrent de nombreux outils et services redis utiles. L'écosystème autour de Redis est beaucoup plus grand. Le nombre de déploiements à grande échelle est désormais probablement supérieur à celui de memcached.

Le Superset Redis

Redis est plus qu'un cache. C'est un serveur de structure de données en mémoire. Ci-dessous, vous trouverez un bref aperçu des choses que Redis peut faire au-delà d'un simple cache clé / valeur comme memcached. Plus 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, il semble de plus en plus vrai tout le temps.

redis.io est une ressource fantastique facilement navigable. Ça te permet essayez redis dans le navigateur et même vous donne des exemples interactifs en direct avec chaque commande dans les docs.

Il y a maintenant 2x fois plus de résultats de stackoverflow pour redis que memcached. 2 fois plus de résultats Google Des exemples plus facilement accessibles dans plus de langues. Développement plus actif. Développement de client plus actif. Ces mesures peuvent ne pas signifier beaucoup individuellement, mais en combinaison, elles montrent clairement que le support et la documentation pour Redis sont plus importants et beaucoup plus à jour.

Persistance

Par défaut, redis conserve vos données sur le disque en utilisant un mécanisme appelé snapshotting. Si vous avez suffisamment de RAM disponible, il est capable d'écrire toutes vos données sur disque sans presque aucune dégradation des performances. C'est presque gratuit!

En mode instantané, il est possible qu'une panne soudaine 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 a aussi votre dos avec le mode AOF (Append Only File). Dans ce mode de persistance, les données peuvent être synchronisées sur le disque au moment où il est écrit. Cela peut réduire le débit d'écriture maximal, quelle que soit la rapidité avec laquelle votre disque peut écrire, mais devrait être assez rapide.

Il existe de nombreuses options de configuration pour affiner la persistance si vous en avez besoin, mais les valeurs par défaut sont très judicieuses. Ces options facilitent la configuration de redis en tant que lieu sûr et redondant pour stocker des données. C'est un réal base de données.

De nombreux types de données

Memcached est limité aux chaînes, mais Redis est un serveur de structure de données pouvant servir de nombreux types de données différents. Il fournit également les commandes dont vous avez besoin pour tirer le meilleur parti de ces types de données.

Cordes (commandes)

Texte simple ou valeurs binaires pouvant atteindre 512 Mo. C'est le seul type de données redis et memcached partagé, bien que les chaînes memcached soient limitées à 1 Mo.

Redis vous donne plus d'outils pour tirer parti de ce type de données en offrant des commandes pour les opérations au niveau du bit, la manipulation au niveau des bits, la prise en charge des incréments / décréments à virgule flottante, les requêtes de plage et les opérations multi-clés. Memcached ne supporte pas cela.

Les chaînes sont utiles pour toutes sortes de cas d'utilisation, ce qui explique pourquoi memcached est assez utile avec ce type de données seul.

Hashes (commandes)

Les hachages sont un peu comme un magasin de valeurs clés dans un magasin de valeurs clés. Ils mappent entre les champs de chaîne et les valeurs de chaîne. Les mappes champ-> valeur utilisant un hachage sont légèrement plus efficaces que les mappes clés-> valeurs utilisant des chaînes normales.

Les hachages sont utiles en tant qu'espace de noms ou lorsque vous voulez grouper plusieurs clés de façon logique. Avec un hachage, vous pouvez saisir tous les membres efficacement, expirer tous les membres ensemble, supprimer tous les membres ensemble, etc. Idéal pour tout cas d'utilisation où vous avez plusieurs paires clé / valeur qui doivent être regroupées.

Un exemple d'utilisation d'un hachage consiste à stocker des profils d'utilisateur entre des applications. Un hachage redis stocké avec l'ID utilisateur comme clé vous permettra de stocker autant de bits de données sur un utilisateur que nécessaire tout en les gardant stockés sous une seule clé. 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 d'une application remplaçant les modifications apportées par d'autres (ce qui peut arriver Les données).

Listes (commandes)

Les listes Redis sont des collections ordonnées de chaînes. Ils sont optimisés pour insérer, lire ou supprimer des valeurs du haut ou du bas (alias: gauche ou droite) de la liste.

Redis fournit de nombreux commandes pour tirer parti des listes, y compris les commandes pour pousser / pop des éléments, appuyez sur / pop entre les listes, tronquer les listes, effectuer des requêtes de plage, etc.

Les listes font de grandes files d'attente atomiques et durables. Ils sont parfaits pour les files d'attente, les journaux, les tampons et bien d'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 l'ensemble, d'ajouter / de supprimer rapidement des valeurs et de mesurer le chevauchement avec d'autres ensembles.

Ils sont parfaits pour des choses comme les listes de contrôle d'accès, les trackers 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 gérer des ensembles. Les plus évidents, comme l'ajout, le retrait et la vérification de l'ensemble, sont présents. Il y a donc des commandes moins évidentes comme sauter / lire un élément aléatoire et des commandes pour effectuer 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 son nom l'indique, sont commandés. Ils sont classés par partition, puis lexicographiquement.

Ce type de données est optimisé pour les recherches rapides par score. Obtenir le plus élevé, le plus bas, ou n'importe quelle gamme de valeurs entre les deux est extrêmement rapide.

Si vous ajoutez des utilisateurs à un ensemble trié avec leur score élevé, vous avez vous-même un tableau de bord parfait. Au fur et à mesure que de nouveaux scores élevés arrivent, il suffit de les ajouter à l'ensemble avec leur meilleur score et il réorganisera votre tableau de classement. Aussi bien pour garder une trace de la dernière fois que les utilisateurs ont visité et qui est actif dans votre application.

Stocker des valeurs avec le même score les amène à être ordonnées lexicographiquement (pensez alphabétiquement). Cela peut être utile pour des fonctionnalités comme les fonctions de saisie automatique.

Beaucoup de l'ensemble trié commandes sont similaires aux commandes d'ensembles, parfois avec un paramètre de score supplémentaire. Sont également incluses des commandes de gestion des scores et d'interrogation par score.

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 la mesure des distances entre les points.

Les données techniquement géographiques dans redis sont stockées dans des ensembles triés, ce n'est donc pas un type de données vraiment séparé. C'est plus une extension au-dessus des ensembles triés.

Bitmap et HyperLogLog

Comme geo, ce ne sont pas des types de données 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 sont ce que les opérateurs de niveau de bits j'ai référencé sous Strings sont pour. Ce type de données constituait le bloc de construction de base du récent projet artistique collaboratif de reddit: r / Place.

HyperLogLog vous permet d'utiliser une quantité constante d'espace extrêmement faible 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 est dans les millions.

Transactions et atomicité

Les commandes redis sont atomiques, ce qui signifie que vous pouvez être sûr que dès que vous écrivez une valeur à redis, cette valeur est visible pour tous les clients connectés à redis. Il n'y a pas d'attente pour que cette valeur se propage. Techniquement memcached est aussi atomique, mais avec redis ajoutant toute cette fonctionnalité au-delà de memcached il est intéressant de noter et quelque peu impressionnant que tous ces types de données et fonctionnalités sont également atomiques.

Bien que pas tout à fait la même chose que les transactions dans les bases de données relationnelles, redis a également transactions qui utilisent le "verrouillage optimiste" (REGARDER/MULTI/EXEC).

Pipelining

Redis fournit une fonctionnalité appelée 'pipelining'. Si vous avez plusieurs commandes redis que vous voulez exécuter, vous pouvez les utiliser pour les envoyer à redis tout-en-un au lieu d'un à la fois.

Normalement, lorsque vous exécutez une commande redis ou memcached, chaque commande est un cycle de requête / réponse distinct. Avec pipelining, redis peut mettre en tampon plusieurs commandes et les exécuter toutes en même temps, en répondant à toutes les réponses à toutes vos commandes dans une seule réponse.

Cela peut vous permettre d'atteindre un débit encore plus important lors de l'importation en bloc ou d'autres actions impliquant de nombreuses commandes.

Pub / Sub

Redis a commandes dédié à pub / sous-fonctionnalité, permettant Redis d'agir comme un diffuseur de message à haute vitesse. Cela permet à un seul client de publier des messages à de nombreux autres clients connectés à un canal.

Redis fait pub / sub ainsi que presque n'importe quel outil. Des courtiers de messages dédiés comme RabbitMQ peut avoir des avantages dans certains domaines, mais le fait que le même serveur peut également vous donner des files d'attente persistantes et d'autres structures de données dont vos charges de travail pub / sous-tâches ont probablement besoin, Redis s'avérera souvent être l'outil le meilleur et le plus simple.

Lua Scripting

Vous pouvez en quelque sorte penser à scripts lua comme SQL propre de Redis ou procédures stockées. C'est à la fois plus et moins que cela, mais l'analogie fonctionne surtout.

Peut-être que vous avez des calculs complexes que vous voulez effectuer. Peut-être que vous ne pouvez pas vous permettre de faire reculer vos transactions et avoir besoin de garanties à chaque étape d'un processus complexe qui se produira de façon atomique. Ces problèmes et beaucoup d'autres peuvent être résolus avec des scripts lua.

Le script entier est exécuté de manière atomique, donc si vous pouvez adapter votre logique dans un script lua, vous pouvez souvent éviter de jouer avec des transactions de verrouillage optimistes.

Mise à l'échelle

Comme mentionné ci-dessus, Redis comprend un support intégré pour la mise en cluster et est livré avec son propre outil de haute disponibilité appelé redis-sentinel.

Conclusion

Sans hésitation, je recommanderais redis sur memcached pour tous les nouveaux projets, ou les projets existants qui n'utilisent pas déjà memcached.

Ce qui précède peut sembler que je n'aime 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 pas que cela a beaucoup de sens pour le développement futur.

Redis fait tout ce que Memcached fait, souvent mieux. Tout avantage de performance pour memcached est mineur et spécifique à la charge de travail. Il y a aussi des charges de travail pour lesquelles redis sera plus rapide, et beaucoup plus de charges de travail que redis peut faire ce que memcached ne peut tout simplement pas faire. Les minuscules différences de performances semblent mineures face à l'énorme gouffre de fonctionnalité et le fait que les deux outils sont si rapides et efficaces qu'ils peuvent très bien être la dernière pièce de votre infrastructure, vous aurez jamais à vous soucier de la mise à l'échelle.

Il n'y a qu'un seul scénario où memcached a plus de sens: où memcached est déjà utilisé comme cache. Si vous êtes déjà en cache avec memcached, continuez à l'utiliser s'il répond à vos besoins. Il ne vaut probablement pas la peine de passer à redis et si vous allez utiliser redis juste pour la mise en cache, il peut ne pas offrir suffisamment d'avantages pour valoir le coup. Si memcached ne répond pas à vos besoins, alors vous devriez probablement passer à redis. Cela est vrai que vous ayez besoin d'évoluer au-delà de memcached ou que vous ayez besoin de fonctionnalités supplémentaires.


1638
2018-06-29 06:54



Utilisez Redis si

  1. Vous avez besoin de supprimer / expirer sélectivement des éléments dans le cache. (Tu en as besoin)

  2. Vous avez besoin de la possibilité d'interroger des clés d'un type particulier. éq. 'blog1: messages: *', 'blog2: catégories: xyz: messages: *'. Oh oui! c'est très important. Utilisez ceci pour invalider certains types d'éléments mis en cache sélectivement. Vous pouvez également l'utiliser pour invalider le cache de fragment, le cache de page, uniquement les objets AR d'un type donné, etc.

  3. Persistance (Vous en aurez également besoin, à moins que votre cache ne soit en train de se réchauffer après chaque redémarrage, ce qui est très important pour les objets qui changent rarement)

Utilisez memcached si

  1. Memcached vous donne la tête!
  2. euh ... le regroupement? meh. Si vous allez aussi loin, utilisez Varnish et Redis pour mettre en cache des fragments et des objets AR.

D'après mon expérience, j'ai eu une bien meilleure stabilité avec Redis qu'avec Memcached


128
2017-07-05 06:04



Memcached est multithread et rapide.

Redis a beaucoup de fonctionnalités et est très rapide, mais complètement limité à un noyau car il est basé sur une boucle d'événement.

Nous utilisons les deux. Memcached est utilisé pour mettre en cache des objets, en réduisant principalement la charge de lecture sur les bases de données. Redis est utilisé pour des choses comme des ensembles triés qui sont utiles pour enrouler des données de séries chronologiques.


76
2018-05-03 16:41



Ceci est trop long pour être posté comme commentaire à la réponse déjà acceptée, donc je l'ai mis comme une réponse séparée

Une chose à considérer est de savoir si vous prévoyez d'avoir une limite de mémoire supérieure dure sur votre instance de cache.

Puisque redis est une base de données nosql avec des tonnes de fonctionnalités et que la mise en cache n'est qu'une option possible, elle alloue de la mémoire quand elle en a besoin - plus vous y mettez d'objets, plus elle utilise de mémoire. le maxmemory L'option n'applique pas strictement l'utilisation de la limite supérieure de mémoire. Lorsque vous travaillez avec le cache, les clés sont expulsées et expirées; Il est probable que vos clés ne soient pas toutes de la même taille, ce qui entraîne une fragmentation de la mémoire interne.

Par défaut, redis utilise jemalloc L'allocateur de mémoire, qui fait de son mieux pour être à la fois compact et rapide, est un répartiteur de mémoire à usage général et il ne peut pas suivre de nombreuses allocations et purges d'objets à un taux élevé. Pour cette raison, sur certains modèles de charge, le processus redis peut apparemment perdre de la mémoire à cause de la fragmentation interne. Par exemple, si vous avez un serveur avec 7 Go de RAM et que vous voulez utiliser redis comme cache LRU non persistant, vous pouvez trouver ce processus redis avec maxmemory Avec 5 Go de mémoire au fil du temps, la mémoire serait de plus en plus utilisée, ce qui finirait par atteindre la limite de RAM totale jusqu'à ce que le tueur de mémoire insuffisante interfère.

memcached est un meilleur ajustement 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 morceau de mémoire - tout ce dont il aura besoin - puis gère lui-même cette mémoire, en utilisant sa propre mémoire répartiteur de dalle. En outre, memcached s'efforce de maintenir la fragmentation interne à un bas niveau utilise l'algorithme LRU par plaquette, lorsque les expulsions LRU sont effectuées avec la taille d'objet considérée.

Cela dit, memcached a toujours une position forte dans les environnements, où l'utilisation de la mémoire doit être appliquée et / ou être prévisible. Nous avons essayé d'utiliser le dernier redis stable (2.8.19) comme un remplacement memcached LRU non persistant drop-in dans la charge de travail de 10-15k op / s, et il a fui la mémoire A LOT; la même charge de travail écrasait les instances Redis d'ElastiCache d'Amazon en un jour ou deux pour les mêmes raisons.


68
2018-03-02 11:13



Memcached est bon pour être un simple magasin de clé / valeur et est bon pour faire la clé => STRING. Cela le rend vraiment bon pour le stockage de session.

Redis est bon à faire la clé => SOME_OBJECT.

Cela dépend vraiment de ce que vous allez y mettre. Ma compréhension est qu'en termes de performance, ils sont assez même.

Aussi bonne chance de trouver des repères objectifs, si vous trouvez certains de les envoyer aimablement leur chemin.


44
2018-05-11 23:27



Si cela ne vous dérange pas un style d'écriture grossier, Redis contre Memcached sur le blog Systoilet, cela vaut la peine d'être lu du point de vue de la convivialité, mais assurez-vous de lire les commentaires 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 apporté quelques améliorations depuis que l'article a été écrit.

Et aucun lien de référence n'est complet sans confondre un peu les choses, alors vérifiez également quelques points de référence contradictoires à LiveJournal de Dormondo et le blog d'Antirez.

modifier - comme le souligne Antirez, l'analyse Systoilet est plutôt mal conçue. Même au-delà de la pénurie de threads uniques, une grande partie de la disparité des performances de ces tests peut être attribuée aux bibliothèques client plutôt qu'au débit du serveur. Les repères à le blog d'Antirez présentent en effet une comparaison beaucoup plus pommes-pommes (avec la même bouche).


36
2018-06-15 22:38



J'ai eu l'occasion d'utiliser à la fois memcached et redis ensemble dans le proxy de mise en cache sur lequel j'ai travaillé, laissez-moi vous partager où exactement j'ai utilisé quoi et raison derrière même ....

Redis>

1) Utilisé pour indexer le contenu du cache, sur le cluster. J'ai plus de milliards de clés réparties sur les clusters redis, les temps de réponse redis sont bien moins et stables.

2) Fondamentalement, c'est un magasin de clé / valeur, donc où dans votre application vous avez quelque chose de similaire, on peut utiliser Redis avec beaucoup déranger.

3) La persistance Redis, le basculement et la sauvegarde (AOF) faciliteront votre travail.

Memcache>

1) oui, une mémoire optimisée pouvant être utilisée en cache. Je l'ai utilisé pour stocker le contenu du cache en accédant très fréquemment (avec 50 hits / seconde) avec une taille inférieure à 1 Mo.

2) J'ai alloué seulement 2 Go sur 16 Go pour memcached cela aussi lorsque ma taille de contenu unique était> 1 Mo.

3) Comme le contenu se rapproche des limites, j'ai parfois observé des temps de réponse plus élevés dans les statistiques (ce qui n'est pas le cas avec les redis).

Si vous demandez une expérience globale, Redis est beaucoup vert car il est facile à configurer, très flexible avec des fonctionnalités robustes et stables.

En outre, il existe un résultat d'analyse comparative disponible à cette lien , ci-dessous sont peu de lumière de même,

enter image description here

enter image description here

J'espère que cela t'aides!!


18
2017-10-16 10:20



Un autre bonus est qu'il peut être très clair comment memcache va se comporter dans un scénario de cache, alors que redis est généralement utilisé comme un datastore persistant, bien qu'il puisse être configuré pour se comporter comme memcached alias expulser les éléments les moins utilisés. capacité.

Certaines applications sur lesquelles j'ai travaillé utilisent à la fois juste pour clarifier la façon dont nous entendons que les données se comportent - des choses dans memcache, nous écrivons du code pour gérer les cas où il n'y en a pas - des choses en redis, nous nous en remettons .

Autre que 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 flexible.


11
2017-07-04 12:42



Tester. Exécuter quelques repères simples. Pendant longtemps, je me considérais comme un rhinocéros de la vieille école, car je l'utilisais surtout comme memcached et je considérais Redis comme le nouveau gamin.

Avec ma société actuelle, Redis a été utilisé comme cache principal. Quand j'ai creusé des statistiques de performance et commencé à tester, Redis était, en termes de performance, comparable ou minimalement Ralentissez que MySQL.

Memcached, bien que simpliste, a soufflé Redis hors de l'eau totalement. Il a beaucoup mieux évolué:

  • pour les plus grandes valeurs (changement nécessaire de la taille de la dalle, mais travaillé)
  • pour plusieurs demandes simultanées

En outre, la politique d'expulsion de memcached est, à mon avis, bien mieux mise en œuvre, ce qui se traduit par un temps de réponse moyen global plus stable tout en gérant plus de données que le cache ne peut en gérer.

Certains benchmarks ont révélé que Redis, dans notre cas, fonctionne très mal. Je crois que cela a à voir avec beaucoup de variables:

  • type de matériel que vous exécutez Redis sur
  • types de données que vous stockez
  • quantité de get et de sets
  • comment votre application est concurrente
  • avez-vous besoin de stockage de structure de données

Personnellement, je ne partage pas la vue que les auteurs de Redis ont sur la concurrence et le multithreading.


11
2017-11-13 08:14



Il ne serait pas faux, si nous disons que redis est une combinaison de (cache + structure de données) tandis que memcached est juste un cache.


9
2018-06-16 05:45



Une différence majeure qui n'a pas été signalée ici est que Memcache a toujours une limite de mémoire supérieure, alors que Redis ne l'est pas par défaut (mais peut être configuré pour). Si vous souhaitez toujours stocker une clé / valeur pour un certain laps de temps (et ne jamais l'expulser en raison de la mémoire faible), vous voulez aller avec Redis. Bien sûr, vous risquez également de manquer de mémoire ...


7
2018-03-01 09:45