Si vous envisagez une solution de mise en cache côté serveur, vous avez probablement entendu parler de Redis ou de Memcached.
Les deux Redis et Memcached sont :
Quelle est la différence entre Memcached et Redis ?
Memcached et Redis stockent tous deux des données en mémoire pour améliorer la vitesse des applications, mais ils répondent à des besoins différents.
Mais explorons plus en détail les différences dans cet article. Sur la base d'un projet que nous avons développé pour un client, je vais couvrir comment ils gèrent le stockage des données, évolutivité et lequel fonctionne le mieux en tenant compte de certains scénarios. Mais d'abord, commençons par les bases.
Redis, qui signifie Remote Dictionary Server, a été créé en 2009 par Salvatore Sanfilippo, pour améliorer l'évolutivité de l'analyseur de journaux Web que sa start-up italienne était en train de développer. Le premier prototype a été écrit en Tcl puis transcrit en C. Lorsque Sanfilippo a décidé d'ouvrir le projet en open source, il a commencé à gagner en popularité. Des géants comme GitHub et Instagram ont été parmi les premières entreprises à l'adopter.
Memcached a été créé un peu plus tôt, en 2003, par Brad Fitzpatrick pour son site LiveJournal. Il a d'abord été développé en Perl puis traduit en C. Il est utilisé par certaines des plus grandes entreprises telles que Facebook, Youtube et Twitter.
Redis possède cinq types de données :
Redis prend en charge les opérations de type de données. Cela signifie que vous pouvez accéder à des parties d'un objet de données ou en modifier certaines parties sans avoir à charger l'objet entier au niveau de l'application, à le modifier, puis à stocker à nouveau la version mise à jour. Redis utilise une version encapsulée de la gestion de la mémoire malloc/free, ce qui constitue une approche plus simple que le mécanisme Memcached Slab, comme je vais l'expliquer ci-dessous. Redis prend en charge les clés d'une taille maximale de 512 Mo et des valeurs allant jusqu'à 512 Mo. Cette limite est par élément pour les types de données agrégés (listes et ensembles).
Contrairement à Redis, Memcached n'a aucun type de données, car il stocke les chaînes indexées par une clé de chaîne. Par rapport à Redis, il utilise moins de mémoire. De plus, il est limité par la quantité de mémoire de sa machine et, s'il est plein, il commencera à purger les valeurs selon l'ordre utilisé le moins récemment. Il utilise un mécanisme d'allocation appelé Slab, qui segmente la mémoire allouée en morceaux de différentes tailles et stocke des enregistrements de données clé-valeur de la taille correspondante. Cela résout le problème de fragmentation de la mémoire. Memcached prend en charge les clés d'une taille maximale de 250 Go et des valeurs allant jusqu'à 1 Mo. Mais notez que ce n'est que la valeur par défaut et qu'elle peut être modifiée au démarrage en augmentant la taille maximale de la dalle.
Prenons l'exemple simple de l'utilisation d'un cache pour stocker un objet de session utilisateur.
Si nous utilisons Memcached pour modifier un seul champ de l'objet, la chaîne doit être chargée, désérialisée, le champ objet édité, sérialisé et stocké. Si nous utilisons Redis, le type de données de hachage peut être utilisé. Il donne accès à chaque champ du hachage individuellement afin que toute opération CRUD (créer, lire, mettre à jour, supprimer) puisse être exécutée sur chacun d'eux. Cela permet de réduire la nécessité de le faire au niveau de l'application. Cela conduit à l'efficacité, une fois qu'il nécessite moins d'opérations d'E/S.
Depuis Redis est principalement monothread et dispose d'un support natif pour le clustering, il pousse bien horizontalement.
Le clustering Redis fonctionne avec une architecture maître/esclave. Pour chaque nœud maître, il existe deux nœuds esclaves à des fins de redondance. Par conséquent, si le maître tombe en panne, le système promeut automatiquement l'un des esclaves en tant que nouveau maître. Ce type d'évolutivité présente l'inconvénient d'une complexité de maintenance. Il est plus difficile de gérer plusieurs nœuds de manière synchrone qu'un seul.
Memcached est facilement redimensionnable verticalement, comme il est multithread. Les seules exigences sont de lui donner plus de cœurs et plus de mémoire. Il peut également être redimensionné horizontalement, côté client, par la mise en œuvre d'un algorithme distribué. Cela présente l'inconvénient d'être plus complexe à implémenter alors que Redis l'a prêt à l'emploi.
Lorsque vous décidez d'utiliser Redis ou Memcached, la principale différence entre les deux est la persistance des données.
Alors que Redis est un magasin de données en mémoire (principalement) et il n'est pas volatil, Memcached est un cache en mémoire et elle est volatile.
Également Memcached est limité à la politique d'expulsion LRU (la moins récemment utilisée) tandis que Redis soutient six politiques différentes :
Redis soutient la persévérance, c'est pourquoi on l'appelle magasin de données, de deux manières différentes :
Ces fichiers sont gérés par un processus enfant et c'est un facteur clé pour décider du type de persistance à utiliser.
Si le jeu de données stocké dans Redis est trop volumineux, la création du fichier RDB prendra un certain temps, ce qui a un impact sur le temps de réponse. En revanche, il sera plus rapide à charger au démarrage que le journal AOF.
Le Le journal AOF est meilleur si la perte de données n'est pas du tout acceptable, car il peut être mis à jour à chaque commande. Il ne présente pas non plus de problèmes de corruption puisqu'il s'agit d'un fichier à ajouter uniquement. Cependant, il peut devenir beaucoup plus grand qu'un instantané RDB.
1. Mise en cache de session dans les applications Web : Redis peut stocker les données de session utilisateur pour les applications Web, ce qui est particulièrement utile pour les plateformes comptant un grand nombre d'utilisateurs simultanés. Par exemple, un site de commerce électronique peut utiliser Redis pour récupérer rapidement les sessions des utilisateurs sans accéder à la base de données, accélérant ainsi l'expérience utilisateur lors des processus de connexion et de paiement.
2. Analyses en temps réel : Les structures de données de Redis, telles que les ensembles triés et les hachages, peuvent être utilisées pour implémenter des tableaux de bord analytiques en temps réel. Par exemple, une plateforme de réseau social peut utiliser Redis pour suivre et afficher le nombre d'utilisateurs actifs ou les tendances des publications en temps réel.
3. Applications de mise en file d'attente des messages et de chat : Les fonctionnalités pub/sub de Redis permettent de mettre en place des systèmes de mise en file d'attente des messages en temps réel. Il peut être utilisé pour créer des applications de chat dans lesquelles les messages doivent être transmis instantanément à différents abonnés.
4. Classements et comptage : Les jeux et les plateformes sociales utilisent souvent Redis pour gérer les classements en raison de sa capacité à gérer des taux d'écriture et de lecture élevés. Par exemple, une plateforme de jeu en ligne peut utiliser Redis pour mettre à jour et afficher le classement des joueurs en temps réel.
5. Cache pleine page (FPC) : Redis peut être utilisé comme FPC pour stocker la sortie des requêtes de base de données et réduire la charge sur la base de données. Par exemple, un système de gestion de contenu (CMS) peut utiliser Redis pour mettre en cache les pages et les diffuser rapidement sans les régénérer à chaque demande.
1. Mise en cache de chaînes simple : Memcached est idéal pour les sites web de petite et moyenne taille qui ont besoin d'une simple couche de mise en cache pour les chaînes. Par exemple, un site de blog peut l'utiliser pour mettre en cache les résultats des requêtes de base de données pour les articles de blog et les diffuser plus rapidement aux visiteurs.
2. Mise en cache des résultats des requêtes de base de données : Memcached peut être utilisé pour mettre en cache les résultats des requêtes de base de données les plus fréquemment utilisées, réduisant ainsi la charge de la base de données. Un système de catalogue en ligne pourrait l'utiliser pour mettre en cache les listes et les détails des produits.
3. Mise en cache de fragments HTML : Les sites Web contenant des fragments HTML statiques coûteux à générer peuvent utiliser Memcached pour stocker ces fragments. Par exemple, un site Web d'actualités peut mettre en cache des extraits d'articles sur la page d'accueil afin d'améliorer les temps de chargement.
4. Limitation du débit de l'API : Les opérations d'incrémentation et de décrémentation atomiques de Memcached peuvent être utilisées pour implémenter la limitation du débit des API. Une API RESTful pourrait utiliser Memcached pour suivre le nombre de requêtes d'un utilisateur au cours d'une période donnée, afin d'éviter les abus.
5. Boutique de sessions : Semblable à Redis, Memcached peut être utilisé pour stocker les sessions utilisateur, mais sans persistance. Cela convient aux applications où les données de session sont transitoires et peuvent être perdues sans impact significatif, comme dans les microservices sans état.
Cela dépend certainement des exigences.
Redis est sûrement plus flexible et plus puissant, mais Memcached répond très bien à certains objectifs et obtient dans certains cas de meilleures performances. Le fait qu'il soit multithread présente des avantages, en particulier lorsqu'il s'agit de travailler avec des mégadonnées.
Redis prend en charge les opérations de données grâce à ses types de données, qui peuvent accélérer les scénarios en réduisant le nombre d'E/S réseau et la taille des données. Ces opérations de données sont aussi lourdes qu'une collecte ou une configuration.
À Imaginary Cloud nous avons utilisé les deux dans de nombreux projets de clients différents. Dans l'une d'elles à laquelle j'ai participé, nous avons dû choisir entre les deux options. Au début, nous avons choisi Memcached en raison de sa simplicité, de sa facilité d'utilisation et de sa configuration, nous avions simplement besoin d'un cache, donc la persistance n'était pas une exigence. Bien que, après quelques essais, nous avons décidé de passer à Redis en raison des avantages d'avoir des types de données.
Dans ce projet, les opérations de type de données constituaient un avantage pour le type de données qui devaient être stockées. Redis fournit également une commande permettant de rechercher des clés correspondant à un modèle, ainsi que de nombreuses autres commandes utiles pour gérer les touches. Cela nous a été très utile et a joué un rôle clé dans notre décision de migrer vers Redis.
En ce qui concerne la migration, elle a été très facile à réaliser car Redis prend en charge la plupart des commandes de Memcached. Si nous avions inversé la route et décidé de migrer de Redis vers Memcached, cela aurait été beaucoup plus difficile car Memcached ne possède aucun type de données. Toute commande de type de données Redis aurait été traduite en de nombreuses commandes, avec un traitement de données entre elles pour obtenir le même résultat.
Lorsqu'il s'agit de prendre une décision, on ne peut pas vraiment dire que l'un est meilleur que l'autre, car tout dépend des exigences du projet. Cependant, d'après notre expérience, il est important de prendre en compte ses avantages et ses inconvénients dès le début afin d'éviter des modifications et des migrations au cours du projet.
Développeur web chez Nuage imaginaire, passionné par Node.js et par tout ce qui concerne le développement back-end.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
