Memcached vs Redis : Quelle solution de cache choisir ?

Choisir son champion du cache ?

Ah, la sainte quête du cache parfait ! On entre ici dans l’arène des débats informatiques épiques, juste après le sempiternel « Tabulations ou Espaces ? » et le passionnant « Mon IDE est plus cool que le tien ! ». Memcached vs Redis, c’est un peu le choc des titans du stockage temporaire, où chacun a ses groupies ferventes, souvent armées d’arguments… disons… créatifs.

Pendant longtemps, j’ai erré dans les couloirs sombres du développement, entendant des incantations du genre « Redis, c’est la vie ! » ou « Memcached, le seul, le vrai ! ». Et moi, pauvre mortel, osais demander « Euh… pourquoi ? ». La réponse était souvent un regard vague et une tirade technique à moitié comprise, saupoudrée de quelques contre-vérités croustillantes.

Las de cette ignorance béate, j’ai décidé de plonger la tête la première dans les entrailles de ces deux bêtes. J’ai lu des tonnes de documentation, décortiqué des architectures obscures, tout ça pour pouvoir enfin briller en société. (du moins, dans mes cercles de développeurs insomniaques).

Différences évidentes entre Memcached et Redis

Bon, commençons par les trucs gros comme le nez au milieu de la figure, les différences tellement flagrantes qu’on se demande comment certains font pour les ignorer (sûrement en fixant intensément leur écran, hypnotisés par leur propre génie, mais c’est une autre histoire). On parle ici des distinctions fondamentales dans le match Memcached vs Redis.

La première, et c’est un peu la base dans ce débat Memcached vs Redis, c’est que Redis, c’est un peu le couteau suisse du cache. Il jongle avec plusieurs types de données, un peu comme un chef étoilé qui peut te faire une symphonie avec des légumes oubliés au fond du frigo. On parle de :

Les trucs en plus de Redis

• Chaînes de caractères (le bon vieux texte, rien de transcendant, mais ça fait le job).
• Listes (pratiques pour faire des files d’attente… de tâches à faire, tiens !).
• Ensembles (pour les collections uniques, genre la liste des excuses que j’ai déjà utilisées au travail).
• Tables de hachage (des paires clé-valeur plus complexes, un peu comme mon cerveau qui essaie de retenir où j’ai mis mes clés).
• Ensembles triés (comme les classements, mais pour les données, moins de compétition, je vous rassure).
• Bitmaps (pour manipuler des bits, le genre de truc qui fait dire « ah ouais, cool… » sans vraiment comprendre).
• HyperLogLogs (estimation de cardinalité, le genre de concept obscur qui impressionne en réunion).

Et ce n’est pas tout ! Redis a aussi quelques tours dans son sac, des features bonus pour impressionner la galerie, des arguments de poids dans le match Memcached vs Redis :

• Persistance sur disque (parce que perdre ses données, c’est jamais une partie de plaisir, même pour un cache).
• Courtier de messages (pour que vos applications papotent entre elles, comme des commères au café du coin).
• Scripting Lua (pour écrire des petits programmes directement dans le cache, attention, ça peut devenir addictif).
• Transactions (pour que plusieurs opérations se fassent en bloc, un peu comme quand j’essaie de ranger mon bureau en une seule fois – le résultat est variable).
• Pub/Sub (publication/souscription) (pour diffuser des messages à ceux qui sont intéressés, un peu comme les notifications sur votre téléphone, mais en moins intrusif).
• Support géospatial (pour localiser des trucs, pratique si vous avez perdu votre serveur).

Les trucs en plus de Memcached

Alors que Memcached, lui, c’est plutôt le spécialiste mono-tâche, le gars qui excelle dans une seule chose : stocker des chaînes de caractères (et des objets sérialisés).

C’est le maçon du cache, il pose brique par brique (enfin, clé par valeur) avec une efficacité redoutable, mais ne lui demandez pas de faire de la plomberie ou de l’électricité.

Genèse des Géants : Quand le Cache Avait Encore des Couches (d’oignon ?) – L’Histoire de Memcached et de Redis

Maintenant, remontons le temps, faisons un petit bond dans le passé pour comprendre d’où viennent ces deux mastodontes du stockage temporaire. C’est un peu comme regarder des photos de famille embarrassantes, mais avec des serveurs à la place des coupes de cheveux douteuses, l’histoire de Memcached vs Redis en quelque sorte.

Memcached, le Vieux Sage (2003) dans l’Épopée Memcached vs Redis

Imaginez l’an 2003. Le web en était encore à ses balbutiements « Web 2.0 » (oui, c’était une chose). Et au milieu de ce chaos numérique, il y avait LiveJournal, une plateforme où les gens déversaient leurs états d’âme (un peu comme Twitter aujourd’hui, mais avec moins de trolls et plus de poésie, peut-être). Le souci, c’est que ça commençait à ramer sévère.

C’est là qu’intervient un esprit brillant (ou peut-être juste quelqu’un qui en avait marre d’attendre le chargement des pages) qui pond Memcached. D’abord gribouillé en Perl (oui, Perl ! Les anciens se souviennent…), il a vite été refait en C, le langage des vrais durs de l’informatique. L’idée de base était aussi simple que géniale : prendre la RAM inutilisée des serveurs web et la transformer en un immense coffre-fort super rapide pour y stocker les données les plus demandées.

Memcached est vite devenu la coqueluche des sites web à forte affluence. Youtube, Reddit, Facebook, Pinterest, Twitter, Wikipédia… tous ces géants l’ont adopté. C’était l’astuce magique pour que les sites PHP (très populaires à l’époque) puissent enfin stocker des informations sans devoir harceler constamment la base de données, un peu comme donner un pense-bête à un amnésique pour qu’il arrête de vous poser la même question toutes les cinq minutes, une solution simple et efficace.

Redis, le Jeune Loup (2009) entre en Scène dans Memcached vs Redis

Avance rapide jusqu’en 2009. Salvatore Sanfilippo, un développeur italien avec une vision (et probablement quelques frustrations avec les performances logicielles), décide de créer Redis. L’histoire raconte qu’il l’a d’abord prototypé en TCL (un autre langage de l’époque, un peu le cousin un peu bizarre du C), avant de finalement le coder lui aussi en C (décidément, le C, c’était le must-have !). Son arrivée a complexifié le paysage du caching.

Contrairement à Memcached, l’objectif initial de Redis n’était pas uniquement le caching. Salvatore voulait une sorte de magasin de structures de données en mémoire persistant. Oui, vous avez bien entendu, persistant ! C’est un peu comme avoir un pense-bête qui se souvient de tout même quand on éteint la lumière, une différence fondamentale dans la comparaison Memcached vs Redis. C’est pour ça qu’il a intégré tous ces types de données exotiques dont on parlait plus tôt, des fonctionnalités absentes de Memcached.

Redis a rapidement conquis le cœur de la communauté Ruby on Rails, probablement grâce à d’excellentes bibliothèques et une intégration aux petits oignons. Des sites comme GitHub, Instagram, Stack Overflow et Craigslist l’ont adopté, séduits par sa flexibilité et ses fonctionnalités avancées, des arguments de poids dans le choix Memcached vs Redis.

Comparaison de Redis et Memcached

En résumé : Memcached vs Redis ?

Alors, l’heure de la grande décision a sonné : faut-il parier sur le bon vieux Memcached ou le jeune et fougueux Redis ? Accrochez-vous, car voici quelques règles empiriques, avec une pincée d’humour pour faire passer la pilule (surtout si vous finissez par choisir le mauvais) :

Optez pour Memcached si :

• Votre serveur a plus de cœurs qu’une pieuvre en colère : Vous voulez que votre cache carbure à fond en exploitant chaque petit processeur comme un hamster sous stéroïdes ? Memcached, avec son côté « on met tout le monde à la tâche », pourrait être votre bolide.
• Votre cache est sous pression comme un candidat de télé-réalité avant l’élimination : Vous envoyez des requêtes au cache plus vite que votre ado ne consomme des chips ? Memcached, le bourreau de travail multi-thread, pourrait mieux encaisser le choc sans broncher (ou presque).
• Vos données ressemblent à une armée de clones miniatures : Vous cachez une quantité astronomique de petites valeurs, toutes calibrées au millimètre près ? Le système de « slabs » de Memcached pourrait optimiser le stockage comme Marie Kondo range vos chaussettes (mais pour des bits).

Craquez pour Redis si :

• Votre cache a des ambitions au-delà du simple « stocker et oublier » : Vous rêvez d’un cache avec une mémoire à long terme (persistance), capable de jongler avec des listes comme un pro, de faire des ensembles plus uniques que votre collection de timbres, et même de trier des choses plus vite que vous ne triez vos emails non lus ? Redis, le touche-à-tout talentueux, est votre homme (ou plutôt, votre logiciel).
• Votre vision de la scalabilité ressemble plus à une partie de tétris géante qu’à une simple addition de machines : Vous imaginez déjà des clusters tentaculaires et du sharding plus complexe qu’un Rubik’s Cube pour experts ? Redis, avec ses outils intégrés, pourrait vous éviter de vous arracher les cheveux (enfin, plus que d’habitude).

Le Bilan (Subjectif et Amical) :

En gros, si votre besoin se limite à un cache simple et ultra-rapide pour des données uniformes et que votre serveur a des muscles à revendre (des cœurs, on a dit !), Memcached pourrait être le choix pragmatique et direct, un peu comme choisir un bon vieux marteau pour planter un clou.

Par contre, si vous sentez que votre cache a besoin d’une boîte à outils complète, avec des fonctionnalités avancées et une gestion de la scalabilité plus sophistiquée, Redis risque de devenir votre meilleur ami, même s’il est parfois un peu plus « usine à gaz » à configurer.

La Vérité Ultime (Chut, Faut Pas le Dire Trop Fort) :

En fin de compte, c’est votre tambouille spécifique qui compte. Testez les deux dans votre environnement si possible ! Et rappelez-vous, dans le monde du développement, la seule règle d’or est qu’il n’y a pas de règle d’or. Alors, faites votre expérience, mesurez, et surtout, amusez-vous (enfin, autant qu’on peut s’amuser avec du caching).