Résumé (TL;DR)
Mis à jour le 3 juin 2017
Redis est plus puissant, plus populaire et mieux pris en charge que memcached. Memcached ne peut faire qu'une petite partie de ce que Redis peut faire. Redis est meilleur même lorsque leurs fonctionnalités se chevauchent.
Pour toute nouveauté, utilisez Redis.
Memcached vs Redis :comparaison directe
Les deux outils sont des magasins de données puissants, rapides et en mémoire qui sont utiles comme cache. Les deux peuvent 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 pouvant ê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 d'origine :
- Vitesse de lecture/écriture :Les deux sont extrêmement rapides. Les benchmarks 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 le cas.
- 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 grandit rapidement jusqu'à un peu plus que cette taille. Il n'y a jamais vraiment de moyen de récupérer cet espace, à moins de redémarrer memcached. Toutes vos clés pourraient avoir expiré, vous pourriez vider la base de données et elle utiliserait toujours la totalité de la RAM avec laquelle vous l'avez configurée.
- redis :la définition d'une taille maximale dépend de vous. Redis n'utilisera jamais plus que nécessaire et vous rendra la mémoire qu'il n'utilise plus.
- J'ai stocké 100 000 chaînes d'environ 2 Ko (~200 Mo) de phrases aléatoires dans les deux. L'utilisation de la RAM Memcached est passée à environ 225 Mo. L'utilisation de la RAM Redis est passée à environ 228 Mo. Après avoir vidé les deux, redis est tombé à ~ 29 Mo et memcached est resté à ~ 225 Mo. Ils sont tout aussi efficaces dans la façon dont ils stockent les données, mais un seul est capable de les récupérer.
- Vidage d'E/S de disque :Une nette victoire pour redis puisqu'il le fait par défaut et a une persistance très configurable. Memcached ne dispose d'aucun mécanisme de vidage 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 comme cache. Redis inclut des outils pour vous aider à aller au-delà de cela, contrairement à memcached.
mémcaché
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 jusqu'à 1 Mo.
C'est bon pour ça, mais c'est tout ce qu'il fait. Vous pouvez accéder à ces valeurs par 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 bien pour un cache. Vous ne devriez rien y stocker d'important.
Si vous avez besoin de hautes performances ou d'une haute disponibilité, des outils, produits et services tiers sont disponibles.
redis
Redis peut faire les mêmes tâches que memcached, et peut les faire mieux.
Redis peut également servir de cache. Il peut également stocker des paires clé/valeur. Dans Redis, ils peuvent même atteindre 512 Mo.
Vous pouvez désactiver la persistance et vos données seront également perdues au redémarrage. Si vous voulez que votre cache survive aux redémarrages, il vous permet également de le faire. En fait, c'est la valeur par défaut.
Il est également très 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 choix évident. Redis inclut la prise en charge des clusters et est livré avec des outils de haute disponibilité (redis-sentinel) directement "dans la boîte". Au cours des dernières années, redis est également devenu le leader incontesté des outils tiers. Des entreprises comme Redis Labs, Amazon et d'autres proposent 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 désormais probablement supérieur à celui de memcached.
Le sur-ensemble 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 des choses que Redis peut faire au-delà d'être un simple cache clé/valeur comme memcached. La plupart des fonctionnalités de redis sont des choses que memcached ne peut pas faire.
Documents
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 ressource fantastique facile à naviguer. Il vous permet d'essayer redis dans le navigateur et vous donne même des exemples interactifs en direct avec chaque commande dans la documentation.
Il y a maintenant 2 fois plus de résultats de stackoverflow pour redis que memcached. 2x plus de résultats Google. Des exemples plus facilement accessibles dans plus de langues. Développement plus actif. Développement plus actif de la clientèle. Ces mesures peuvent ne pas signifier grand-chose individuellement, mais combinées, elles brossent un tableau clair 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 à l'aide d'un mécanisme appelé instantané. Si vous disposez de suffisamment de RAM, il est capable d'écrire toutes vos données sur le disque sans pratiquement aucune dégradation des performances. C'est presque gratuit !
En mode instantané, il est possible qu'un plantage soudain entraîne la perte d'une petite quantité de données. 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 avec le mode AOF (Append Only File). Dans ce mode de persistance, les données peuvent être synchronisées sur le disque au fur et à mesure qu'elles sont écrites. Cela peut réduire le débit d'écriture maximal à 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 sensibles. Ces options facilitent la configuration de redis en tant qu'emplacement sûr et redondant pour stocker des données. C'est un vrai 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 qui peut 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.
Chaînes (commandes)
Texte simple ou valeurs binaires dont la taille peut atteindre 512 Mo. Il s'agit du seul partage de type de données redis et memcached, 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 proposant des commandes pour les opérations au niveau du bit, la manipulation au niveau du bit, la prise en charge de l'incrémentation/décrémentation en virgule flottante, les requêtes de plage et les opérations multi-clés. Memcached ne supporte rien de tout cela.
Les chaînes sont utiles pour toutes sortes de cas d'utilisation, c'est pourquoi memcached est assez utile avec ce seul type de données.
Hachages (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 mappages champ->valeur utilisant un hachage sont légèrement plus efficaces en termes d'espace que les mappages clé->valeur utilisant des chaînes normales.
Les hachages sont utiles comme espace de noms ou lorsque vous souhaitez regrouper logiquement de nombreuses clés. Avec un hachage, vous pouvez saisir tous les membres efficacement, faire expirer tous les membres ensemble, supprimer tous les membres ensemble, etc. Idéal pour tous les cas d'utilisation où vous avez plusieurs paires clé/valeur qui doivent être regroupées.
Un exemple d'utilisation d'un hachage est le stockage de profils d'utilisateurs 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 conservant 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 faire en sorte que différentes applications lisent/écrivent différents champs dans le profil utilisateur sans avoir à vous soucier qu'une application annule les modifications apportées par d'autres (ce qui peut arriver si vous sérialisez des 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 en haut ou en bas (c'est-à-dire à gauche ou à droite) de la liste.
Redis fournit de nombreuses commandes pour tirer parti des listes, y compris des commandes pour pousser/déplacer des éléments, pousser/déplacer entre des listes, tronquer des listes, effectuer des requêtes de plage, etc.
Les listes constituent d'excellentes files d'attente durables et atomiques. Ceux-ci fonctionnent très bien pour les files d'attente de tâches, les journaux, les 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 se trouve dans l'ensemble, d'ajouter/supprimer rapidement des valeurs et de mesurer le chevauchement avec d'autres ensembles.
Ils sont parfaits pour des éléments tels que 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. Des éléments évidents tels que l'ajout, la suppression et la vérification de l'ensemble sont présents. Il en va de même pour les commandes moins évidentes comme faire apparaître/lire un élément aléatoire et les 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 leur nom l'indique, sont ordonnés. Ils sont classés par partition, puis lexicographiquement.
Ce type de données est optimisé pour les recherches rapides par score. Obtenir les valeurs les plus élevées, les plus basses ou toute plage intermédiaire est extrêmement rapide.
Si vous ajoutez des utilisateurs à un ensemble trié avec leur meilleur score, vous avez vous-même un classement parfait. Au fur et à mesure que de nouveaux meilleurs scores arrivent, ajoutez-les simplement à l'ensemble avec leur meilleur score et cela réorganisera votre classement. Idéal également pour garder une 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 commandes d'ensembles triés sont similaires aux commandes d'ensembles, parfois avec un paramètre de score supplémentaire. Sont également incluses les commandes de gestion des scores et d'interrogation par score.
Géo
Redis dispose de 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.
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 distinct. Il s'agit plutôt d'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 au niveau du bit que j'ai référencés sous Strings
sont pour. Ce type de données était la pierre angulaire du récent projet artistique collaboratif de reddit :r/Place.
HyperLogLog vous permet d'utiliser une quantité d'espace constante extrêmement petite 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 pour 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 redis ajoutant toutes ces fonctionnalités au-delà de memcached, il convient 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 des transactions qui utilisent le "verrouillage optimiste" (WATCH/MULTI/EXEC).
Tuyautage
Redis fournit une fonctionnalité appelée "pipelining". Si vous souhaitez exécuter de nombreuses commandes Redis, vous pouvez utiliser le pipelining pour les envoyer à Redis en une seule fois au lieu d'une à la fois.
Normalement, lorsque vous exécutez une commande vers redis ou memcached, chaque commande est un cycle de demande/réponse distinct. Avec le pipelining, redis peut mettre en mémoire 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 de l'importation en masse ou d'autres actions impliquant de nombreuses commandes.
Pub/Sub
Redis a des commandes dédiées à la fonctionnalité pub/sub, permettant à redis d'agir comme un diffuseur de messages à grande vitesse. Cela permet à un seul client de publier des messages vers de nombreux autres clients connectés à un canal.
Redis fait du 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 fournir des files d'attente durables persistantes et d'autres structures de données dont vos charges de travail pub/sub ont probablement besoin, Redis s'avérera souvent être le meilleur et le plus simple outil. pour le travail.
Scripts Lua
Vous pouvez en quelque sorte penser à des scripts lua comme le propre SQL de Redis ou des procédures stockées. 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. Peut-être que vous ne pouvez pas vous permettre d'annuler vos transactions et que vous avez besoin de garanties que chaque étape d'un processus complexe se déroulera de manière atomique. Ces problèmes et bien d'autres peuvent être résolus avec les scripts lua.
L'ensemble du script est exécuté de manière atomique, donc si vous pouvez intégrer 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 inclut une prise en charge intégrée du clustering et est fourni avec son propre outil de haute disponibilité appelé redis-sentinel
.
Conclusion
Sans hésitation, je recommanderais redis plutôt que memcached pour tout nouveau projet ou projet existant qui n'utilise 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 endurci. Il y a même des cas d'utilisation où c'est un peu plus rapide que redis. J'adore 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 existe également des charges de travail pour lesquelles redis sera plus rapide, et de nombreuses autres charges de travail que redis peut faire et que memcached ne peut tout simplement pas. Les minuscules différences de performances semblent mineures face au gouffre géant des fonctionnalités et au fait que les deux outils sont si rapides et efficaces qu'ils pourraient très bien être le dernier élément de votre infrastructure dont vous aurez à 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 mettez déjà en cache avec memcached, continuez à l'utiliser, s'il répond à vos besoins. Cela ne vaut probablement pas la peine de passer à redis et si vous utilisez redis uniquement pour la mise en cache, il se peut qu'il n'offre 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'évoluer au-delà de memcached ou que vous ayez besoin de fonctionnalités supplémentaires.