Memcached contre Redis?
nous utilisons une application Ruby web avec un serveur Redis pour la mise en cache. Y a-t-il un point pour tester Memcached à la place?
Qu'est-ce qui nous donnera une meilleure performance? Un pour ou un contre entre Redis et Memcached?
Points à considérer:
- vitesse de lecture/écriture.
- l'utilisation de la Mémoire.
- I/O Disque dumping.
- mise à l'Échelle.
17 réponses
Summary (TL;DR)
mise à 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 vs Redis: Comparaison Directe
les Deux outils sont puissants, stockage rapide de données en mémoire utile comme cache. Les deux peuvent aider à accélérer votre application en cachant les résultats de la base de données, des fragments HTML, ou n'importe quoi d'autre qui pourrait être coûteux à générer.
Points à prendre en considération
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:
- vitesse de lecture/écriture : les deux sont extrêmement rapides. Référence varient selon la charge de travail, les versions, et de nombreux autres facteurs, mais montrent généralement redis être aussi rapide ou presque aussi rapide que memcached. Je recommande redis, mais pas parce que memcached est lente. Il n'est pas.
- utilisation de la Mémoire : Redis, c'est mieux.
- memcached: vous spécifiez la taille du cache et lorsque vous insérez des éléments, le démon passe rapidement à un peu plus que cette taille. Il n'y a jamais vraiment une façon de récupérer tout cet espace, sauf redémarrer memcached. Toutes vos clés pourraient être expirées, vous pourriez vider la base de données, et il utiliserait toujours la totalité de la mémoire vive avec laquelle vous l'avez configuré.
- redis: définir une taille max dépend de vous. Redis n'utilisera jamais plus que ce qu'il a et va vous redonner la mémoire, elle 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 vive Memcached a augmenté à ~ 225MO. L'utilisation de la mémoire RAM de Redis est passée à ~228MO. Après avoir rincé les deux, redis il est tombé à ~ 29MB et memcached est resté à ~ 225MB. Ils sont tout aussi efficaces dans la manière dont ils stockent les données, mais un seul est capable de les récupérer.
- disk I/O dumping : une victoire claire pour redis car il fait cela par défaut et a une persistance très configurable. Memcached n'a pas de mécanismes pour décharger sur le disque sans outils tiers.
- échelle : les deux vous donnent des tonnes de headroom avant que vous ayez besoin de plus d'une instance comme cache. Redis inclut des outils pour vous aider à aller au-delà de cela tandis que memcached ne le fait pas.
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 caractère allant jusqu'à 1MB.
C'est bien, mais c'est tout ce qu'il fait. Vous pouvez accéder à ces valeurs par leur touche à très haute vitesse, saturer 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 parfait pour une cache. Vous ne devriez pas y stocker quoi que ce soit d'important.
si vous avez besoin de hautes performances ou de haute disponibilité, il existe des outils, produits et services tiers disponibles.
redis
Redis peut faire les mêmes travaux que memcached peut, et peut les faire mieux.
Redis can sert aussi de cache . Il peut stocker des paires clé/valeur. Dans redis, ils peuvent même atteindre 512 Mo.
vous pouvez désactiver la persistance et il sera heureux de perdre vos données sur le redémarrage aussi. Si vous voulez que votre cache survive au redémarrage, il vous permet de le faire aussi. En fait, c'est la valeur par défaut.
c'est super rapide aussi, souvent limité par la bande passante réseau ou mémoire.
si une instance de redis / memcached n'est pas une performance suffisante pour votre charge de travail, redis est le choix clair. Redis inclut cluster support 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 évident de l'outillage des tiers. Des entreprises comme Redis Labs, Amazon, et d'autres offrent de nombreux outils et services redis utiles. L'écosystème autour de redis est beaucoup plus grande. Le nombre de grandes entreprises les déploiements sont probablement plus importants que pour memcached.
Le Redis Sur-Ensemble
Redis est plus qu'une cache. Il s'agit d'un serveur de structure de données en mémoire. Ci-dessous, vous trouverez un aperçu rapide des choses que Redis peut faire au-delà d'être un cache clé/valeur simple comme memcached. la plupart des 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 de plus en plus vrai tout le temps.
redis.io est une ressource fantastique facilement navigable. Il vous permet essayer redis dans le navigateur et vous donne même des exemples interactifs en direct avec chaque commande dans les docs.
il y a maintenant 2x autant de résultats de flux empilé pour redis que memcached. 2x autant de résultats Google. Des exemples plus facilement accessibles en plus de langues. Développement plus actif. Développement plus actif de la clientèle. Ces mesures ne signifient peut-être pas grand-chose individuellement, mais en les combinant, elles donnent une image claire que le support et la documentation pour redis est plus grand et beaucoup plus à jour.
persistance
par défaut redis persiste vos données au disque en utilisant un mécanisme appelé snapshot. Si vous avez assez de RAM disponible, il est capable d'écrire toutes vos données au disque avec presque aucune dégradation de performance. C'est presque gratuit!
en mode snapshot il y a une chance qu'un crash soudain puisse entraîner 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 votre derrière là aussi avec le mode AOF (ajouter seulement le fichier). Dans ce mode rémanence des données peuvent être synchronisées sur le disque comme il est écrit. Cela peut réduire le débit d'écriture maximum à la vitesse à laquelle votre disque peut écrire, mais devrait toujours ê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 raisonnables. Grâce à ces options, il est facile de configurer redis comme un endroit sûr et redondant pour stocker des données. Il s'agit d'une base de données real .
Nombreux Types De Données
Memcached est limité aux chaînes, mais Redis est un serveur de structure de données qui peut servir de nombreux types de données différents. Il fournit également l' commandes dont vous avez besoin pour tirer le meilleur de ces types de données.
cordes ( commandes )
texte Simple ou valeurs binaires pouvant atteindre 512MB de taille. C'est le seul type de données redis et memcached share, bien que les chaînes memcached soient limitées à 1MB.
Redis vous donne plus d'outils pour tirer parti de ce type de données en offrant des commandes pour les opérations bitwise, bit-level manipulation, floating point support d'incrément / décrément, requêtes de portée et opérations multi-clés. Memcached ne supporte rien de tout ça.
Les chaînessont utiles pour toutes sortes de cas d'utilisation, c'est pourquoi memcached est assez utile avec ce seul type de données.
Hashes ( commandes )
Hashes sont en quelque sorte comme un magasin de valeur clé dans un magasin de valeur clé. Ils font la correspondance entre les champs de chaîne et les valeurs de chaîne. Champ - > cartes de valeurs à l'aide d'un le hachage est légèrement plus efficace que les cartes key->value utilisant des chaînes régulières.
Hashes sont utiles comme espace de noms, ou quand vous voulez logiquement grouper de nombreuses clés. Avec un hachage, vous pouvez saisir tous les membres efficacement, expirer tous les membres ensemble, supprimer tous les membres ensemble, etc. Idéal pour toute utilisation cas où vous avez plusieurs paires clé/valeur qui doivent regroupés.
un exemple d'utilisation d'un hachage est pour stocker des profils d'utilisateur entre application. Un hachage redis stocké avec le nom d'utilisateur comme la clé vous permettra de stocker autant de bits de données sur un utilisateur que nécessaire tout en les gardant stockées sous une seule clé. L'avantage d'utiliser un hachage au lieu de sérialiser le profil dans une chaîne de caractères est que vous pouvez avoir différentes applications lire/écrire des champs différents dans le profil de l'utilisateur sans avoir à vous soucier d'une application qui supplante les changements faits par d'autres (ce qui peut se produire si vous sérialisez des données périmé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 en haut ou en bas (alias gauche ou droite) de la liste.
Redis fournit beaucoup de commandes pour tirer parti des listes, y compris des commandes pour push/pop articles, push/pop entre les listes, tronquer les listes, effectuer des requêtes de gamme, etc.
Les listes font de grandes files d'attente durables, atomiques. Ceux-ci fonctionnent très bien pour les files d'attente de travail, les journaux, les tampons, et de nombreux autres cas d'utilisation.
( commandes )
Les ensemblessont 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, rapidement ajouter/supprimer des valeurs, et de mesurer le chevauchement avec d'autres ensembles.
ceux-ci sont grands pour des choses comme les listes de contrôle d'accès, unique des traqueurs de visiteurs, 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. Évidentes comme l'ajout, la suppression et la vérification de la série sont présents. Il en est de même pour les commandes moins évidentes comme le fait de sauter/lire un élément aléatoire et les commandes pour effectuer des unions et des intersections avec d'autres ensembles.
trié Sets ( commandes )
ensembles triés sont également des collections de valeurs uniques. Celles-ci, comme leur nom l'indique, sont ordonnées. Ils sont ordonnés par une partition, puis lexicographiquement.
ce type de données est optimisé pour des recherches rapides par score. Obtenir le plus haut, le plus bas, ou n'importe quelle plage 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 une parfait chef de bord. Au fur et à mesure que de nouveaux scores élevés apparaissent, il suffit de les ajouter à nouveau sur le plateau avec leur score élevé et cela vous permettra de réorganiser votre tableau de bord. Également idéal pour garder une trace de la dernière fois utilisateurs visités et qui est actif dans votre application.
le fait de stocker des valeurs avec le même score les fait classer lexicographiquement (penser par ordre alphabétique). Cela peut être utile pour des choses comme auto-caractéristiques complètes.
Beaucoup de l'ensemble trié les commandes sont similaires aux commandes pour sets, parfois avec un paramètre score supplémentaire. Sont également incluses les commandes pour gérer les scores et les questions par score.
Geo
Redis a plusieurs commandes pour stocker, extraire et mesurer des données géographiques. Cela inclut les requêtes de rayon et la mesure des distances entre les points.
techniquement, les données géographiques dans redis sont stockées dans ensembles triés, donc ce n'est pas un type de données vraiment séparé. Il s'agit plus d'une extension sur des ensembles triés.
Bitmap and 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 si c'était un bitmap ou un hyperloglog.
Bitmaps sont ce que les opérateurs de niveau bit que j'ai référencé sous Strings sont pour. Ce type de données était la composante de base pour le récent projet d'art collaboratif de reddit: R / Place .
HyperLogLog vous permet d'utiliser une constante très petite quantité d'espace pour compter des valeurs uniques presque illimitées avec une précision choquante. En utilisant seulement ~16Ko vous pouvez compter efficacement le nombre de visiteurs uniques à votre site, même si ce nombre est en millions.
les Transactions et l'Atomicité
les commandes dans redis sont atomiques, ce qui signifie que vous pouvez être sûr que dès que vous écrivez une valeur de redis que la valeur est visible à tous les clients connectés à redis. Il n'y a pas d'attente pour que cette valeur se propage. Techniquement, memcached est atomique aussi, mais avec redis ajoutant toutes ces fonctionnalités au-delà de memcached, il est intéressant de noter et quelque peu impressionnant que tous ces types de données et fonctionnalités supplémentaires sont également atomiques.
bien que ce ne soit pas tout à fait la même chose que les transactions dans les bases de données relationnelles, redis a également transactions qui utilisent" verrouillage optimiste "( montre / MULTI / EXEC ).
Pipelining
Redis fournit une fonctionnalité appelée " pipelining '. Si vous avez beaucoup de commandes redis que vous voulez exécuter, vous pouvez utiliser pipelining pour les envoyer à redis tout-à-la-fois au lieu de one-at-a-time.
normalement quand vous exécutez un commande pour redis ou memcached, chaque commande est un cycle de requête/réponse séparé. Avec pipelining, redis peut amortir 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'atteindre un débit encore plus grand sur l'importation en vrac ou d'autres actions qui impliquent beaucoup de commandes.
Pub / Sub
Redis a commandes dédié à pub/sub fonctionnalité , permettant à redis d'agir comme un diffuseur de messages à haute vitesse. Cela permet à un seul client de publier des messages à de nombreux autres clients connectés à un canal.
Redis ne pub/sub, ainsi que presque n'importe quel outil. Les courtiers de messages dédiés comme RabbitMQ peuvent avoir des avantages dans certains domaines, mais le fait que le même serveur peut également vous donner des files d'attente durables et autres structures de données dont votre pub / sous-charge de travail a probablement besoin, Redis s'avérera souvent l'outil le meilleur et le plus simple pour le travail.
Script Lua
vous pouvez en quelque sorte penser à scripts lua comme le propre SQL de redis ou les procédures stockées. C'est à la fois plus et moins que ça, mais l'analogie fonctionne surtout.
vous avez peut-être des calculs complexes à faire par redis. Peut-être que vous ne pouvez pas vous permettre d'avoir vos transactions se rétractent et ont besoin de garanties chaque étape d'un processus complexe se produira atomiquement. Ces problèmes peuvent être résolus avec un script lua.
le script entier est exécuté atomiquement, donc si vous pouvez ajuster votre logique dans un script lua, vous pouvez souvent éviter de jouer avec des transactions de verrouillage optimistes.
à l'Échelle
comme indiqué ci-dessus, le système redis comprend un support intégré pour le regroupement et est regroupé avec son propre outil de haute disponibilité appelé redis-sentinel .
Conclusion
sans hésitation, je recommande redis au lieu de memcached pour tout nouveau projet, ou projet existant qui n'utilise pas encore memcached.
ce qui précède peut sembler comme je n'aime pas memcached. Au contraire: c'est un outil puissant, simple, stable, mûr et durci. Il y a même des cas d'utilisation où il est un peu plus rapide que redis. J'aime memcached. Je ne pense pas que cela ait 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 d'autres charges de travail que redis peut faire et memcached ne peut tout simplement pas. Les minuscules différences de performance semblent mineures face au gouffre de la fonctionnalité et le fait que les deux outils sont si rapides et efficaces qu'ils peuvent très bien être le dernier morceau de votre infrastructure que vous aurez jamais à vous soucier de 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 alors continuez à l'utiliser, si cela répond à vos besoins. Il est probable que cela ne vaille pas la peine de déménager à redis et si vous allez utiliser redis juste pour la mise en cache, il se peut que cela n'offre pas assez d'avantages pour que votre temps en vaille la peine. Si memcached ne se réunit pas vos besoins, alors vous devriez probablement passer à redis. C'est vrai que vous devez échelle au-delà de memcached ou vous avez besoin de fonctionnalités supplémentaires.
utiliser Redis if
-
vous devez supprimer sélectivement/expirer des éléments dans le cache. (Vous en avez besoin)
-
vous avez besoin de la capacité d'interroger des clés d'un type particulier. eq. 'blog1:messages:*', 'blog2:catégories:xyz:messages:*'. oh que oui! c'est très important. Utilisez cette option pour invalider sélectivement certains types d'articles mis en cache. Vous pouvez également utiliser ceci pour invalider le cache de fragment, le cache de page, seulement AR les objets d'un type donné, etc.
-
persistance (vous aurez besoin de cela aussi, à moins que vous ne soyez d'accord avec le fait que votre cache doit se réchauffer après chaque redémarrage. Très essentiel pour les objets qui changent rarement)
utiliser memcached si
- Memcached vous donne headached!
- umm... le clustering? meh. si vous allez aussi loin, utilisez Vernis et Redis pour la mise en cache. fragments et objets AR.
D'après mon expérience, J'ai eu une bien meilleure stabilité avec Redis que Memcached
Memcached est multithreaded 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 la mise en cache des objets, réduisant principalement la charge de lecture sur les bases de données. Redis est utilisé pour des choses telles que les ensembles triés qui sont pratiques pour l'accumulation de données chronologiques.
C'est trop long pour être affiché comme un commentaire à la réponse déjà acceptée, donc je l'ai mis comme une réponse séparée
une autre 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.
étant donné que 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 pour laquelle elle peut être utilisée, elle alloue de la mémoire comme elle en a besoin - plus il y a d'objets, plus il y a de mémoire utiliser. L'option maxmemory n'impose pas strictement l'utilisation de la limite supérieure de la mémoire. Comme vous travaillez avec le cache, les clés sont expulsées et expirées; il y a des chances que vos clés ne soient pas toutes de la même taille, donc la fragmentation de la mémoire interne se produit.
par défaut redis utilise jemalloc allocateur de mémoire, qui fait de son mieux pour être à la fois mémoire-compact et rapide, mais il est un allocateur de mémoire à usage général et il ne peut pas suivre avec beaucoup d'allocations et d'objet la purge se produit à 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 que le processus redis avec maxmemory défini à 5 Go au fil du temps utiliserait de plus en plus de mémoire, éventuellement en frappant la limite totale de RAM jusqu'à ce que le tueur hors-mémoire interfère.
memcached est un meilleur ajustement au scénario décrit ci-dessus, comme il gère sa mémoire dans une manière complètement différente. memcached alloue un gros morceau de mémoire - tout ce dont il aura besoin - et gère ensuite cette mémoire tout seul, en utilisant son propre slab allocator . De plus, memcached s'efforce de maintenir la fragmentation interne à un faible niveau , car il utilise en fait l'algorithme de LRU par dalle , lorsque les expulsions de LRU sont effectuées en tenant compte de la taille de l'objet.
avec ceci dit, memcached a toujours une position forte 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 un remplacement non-persistant de memcached basé sur la LRU dans une charge de travail de 10-15k op/s, et cela a laissé beaucoup de mémoire; la même charge de travail a été de planter les instances ElastiCache redis D'Amazon en un jour ou deux pour les mêmes raisons.
Memcached est bon pour être un simple stock clé/valeur et est bon pour faire Clé => Chaîne. Cela le rend vraiment bon pour le stockage de session.
Redis est bon à faire de la clé => SOME_OBJECT.
Cela dépend vraiment de ce que vous allez mettre dedans. Je crois comprendre qu'en termes de performance, ils sont assez égaux.
aussi bonne chance pour trouver des benchmarks objectifs, si vous en trouvez façon.
si vous ne vous gênez pas d'un style d'écriture grossier, Redis vs Memcached sur le Blog de Systoilet vaut une lecture d'un point de vue de la convivialité, mais assurez-vous de lire l'aller-retour dans les commentaires avant de tirer des conclusions sur la performance; Il ya quelques problèmes méthodologiques (mono-thread busy-loop tests), et Redis a fait quelques améliorations depuis que l'article a été écrit aussi.
et aucun lien de référence n'est complet sans prêter à confusion les choses un peu, donc aussi vérifier quelques points de repère contradictoires à Dormondo LiveJournal et le carnet Web D'Antirez .
Edit -- comme le souligne Antirez, L'analyse de Systoilet est plutôt mal conçue. Même au-delà du manque de filetage simple, une grande partie de la disparité de performance dans ces benchmarks peut être attribuée aux bibliothèques clientes plutôt qu'au débit du serveur. Les indices de référence à le Weblog D'Antirez présente en effet une comparaison beaucoup plus Pomme-Pomme (avec la même bouche).
j'ai eu l'occasion d'utiliser à la fois memcached et redis ensemble dans le proxy de cache sur lequel j'ai travaillé , laissez-moi vous dire 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 de redis , les temps de réponse de redis sont assez faibles et stables .
2) fondamentalement, c'est un magasin clé/valeur , donc là où dans votre application vous avez quelque chose de similaire, on peut utiliser redis avec déranger beaucoup.
3 ) Redis persisteness, failover and backup (AOF) vous facilitera la tâche .
Memcache >
1) oui , une mémoire optimisée qui peut être utilisée comme cache . Je l'ai utilisé pour stocker du contenu de cache auquel on accédait 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 quand ma taille de contenu simple était >1MB .
3) à mesure que le contenu croît près 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 redis).
si vous demandez pour l'expérience globale Redis est beaucoup vert car il est facile à configurer, beaucoup de flexibilité avec des fonctionnalités robustes stables.
en outre , il y a un résultat d'étalonnage disponible à ce lien , ci-dessous sont quelques higlight de même,
Espérons que cette aide!!
un autre bonus est qu'il peut être très clair comment memcache va se comporter dans un scénario de mise en 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 evicting articles les moins récemment utilisés lorsqu'il atteint sa capacité maximale.
certaines applications sur lesquelles j'ai travaillé utilisent à la fois juste pour indiquer clairement comment nous voulons que les données se comportent - stuff dans memcache, nous écrivons du code pour gérer les cas où il n'y en a pas - stuff dans redis, nous comptons sur sa présence.
autre que ce 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.
Test. Exécutez quelques repères simples. Pendant longtemps, je me suis considéré comme un rhino de la vieille école, car j'utilisais surtout memcached et je considérais Redis le petit nouveau.
avec ma compagnie actuelle, Redis a été utilisé comme cache principal. Quand j'ai creusé dans quelques statistiques de performance et que j'ai simplement commencé à tester, Redis était, en termes de performance, comparable ou minimalement plus lent que MySQL.
Memcached, bien que simpliste, souffla Redis out d'eau totalement .
- pour les grandes valeurs (changement nécessaire de la dalle de taille, mais il a travaillé)
- pour plusieurs requêtes concurrentes
aussi, la Politique d'expulsion memcached est, à mon avis, beaucoup mieux mise en œuvre, résultant en un temps de réponse moyen plus stable dans l'ensemble tout en traitant plus de données que le cache peut traiter.
quelques benchmarking révélé que Redis, dans notre cas, fonctionne très mal. Je crois que cela a à voir avec de nombreuses variables:
- type de matériel que vous utilisez Redis on
- types de données que vous stockez
- montant des gets et des sets
- comment simultanées votre application est
- avez-vous besoin d'une structure de données de stockage
personnellement, je ne partage pas le point de vue des auteurs Redis ont sur la simultanéité et le multithreading.
ce ne serait pas mal, 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é signalée ici est que Memcache a une limite de mémoire supérieure à tout moment, alors que Redis ne le fait 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 de la faible mémoire) vous voulez aller avec Redis. Bien sûr, vous risquez aussi de perdre la mémoire...
un test très simple pour définir et obtenir des clés et des valeurs uniques De 100k contre redis-2.2.2 et memcached. Tous les deux tournent sur linux VM(CentOS) et mon code client(collé ci-dessous) tourne sur windows desktop.
Redis
-
le temps nécessaire pour stocker 100000 valeurs est = 18954ms
-
temps de chargement des valeurs de 100000 est = 18328ms
Memcached
-
le temps nécessaire pour stocker 100000 valeurs est = 797ms
-
a pris le Temps de récupérer de 100000 valeurs = 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-décollage pour notre projet au travail. Nous avons pensé qu'en utilisant un module dans nginx appelé HttpRedis2Module ou quelque chose de similaire, nous aurions une vitesse impressionnante, mais lors des tests avec AB-test nous avons prouvé que nous avions tort.
peut-être que le module était mauvais ou notre mise en page, mais c'était une tâche très simple et il était encore plus rapide de prendre des données avec php et puis les bourrer dans MongoDB. Nous utilisons APC comme système de cache et avec php et MongoDB. Il était beaucoup beaucoup plus rapide que le module Nginx Redis.
mon conseil est de le tester vous-même, en le faisant vous montrera les résultats pour votre environnement. Nous avons décidé que l'utilisation de Redis était inutile dans notre projet car il ne serait pas logique.
la plus grande raison restante est la spécialisation.
Redis peut faire beaucoup de choses différentes et un effet secondaire de cela est les développeurs peuvent commencer à utiliser beaucoup de ces différents ensembles de fonctionnalités sur la même instance. Si vous utilisez la fonctionnalité LRU de Redis pour un cache le long du stockage de données dur côté qui n'est pas LRU, il est tout à fait possible de manquer de mémoire.
si vous voulez configurer une instance Redis dédiée pour être utilisée uniquement comme une LRU exemple pour éviter ce scénario particulier, il n'y a pas vraiment de raison impérieuse d'utiliser Redis au lieu de Memcached.
si vous avez besoin d'un cache LRU fiable" ne descend jamais"...Memcached s'adaptera à la facture puisqu'il est impossible pour elle de manquer de mémoire par la conception et la fonctionnalité de spécialisation empêche les développeurs d'essayer de faire quelque chose qui pourrait mettre en danger. Simple séparation des préoccupations.
Redis est mieux Les avantages de Redis sont,
1.It has a lot of data storage options such as string , sets , sorted sets , hashes , bitmaps
2.Disk Persistence of records
3.Stored Procedure (LUA acripting) support
4.Can act as a Message Broker using PUB/SUB
alors que Memcache est un système de type cache de valeur clé en mémoire.
- pas de support pour les différents types de stockage de données comme les listes, les ensembles comme dans redis.
- le principal inconvénient est que Memcache n'a pas de persistance de disque .
Memcached sera plus rapide si vous êtes intéressé par la performance, juste parce que Redis implique la mise en réseau (appels TCP). Memcache est également plus rapide en interne.
Redis a plus de caractéristiques, car il a été mentionné dans d'autres réponses.
J'ai surtout utilisé à la fois mes applications, Memcache pour le cache des sessions et redis pour les objets doctrine/orm queries. En termes de performances, les deux sont presque identiques.