Comment fonctionnent les bases de données clé-valeur (par ex., Redis, Memcached)
Votre application frontend semble rapide. Les utilisateurs cliquent, les données apparaissent, les pages se chargent instantanément. Derrière cette expérience, il y a souvent une base de données clé-valeur qui fait le gros du travail — interceptant les requêtes avant même qu’elles n’atteignent votre base de données principale. Comprendre le fonctionnement de ces systèmes vous aide à prendre des décisions plus éclairées concernant la mise en cache, les sessions et l’architecture backend.
Points clés à retenir
- Les bases de données clé-valeur stockent et récupèrent les données en utilisant une clé unique associée à une valeur, sacrifiant la flexibilité des requêtes au profit d’une vitesse exceptionnelle.
- Le stockage en mémoire (RAM) permet des recherches en temps constant via des tables de hachage, souvent 100 à 1000 fois plus rapides que les lectures sur disque.
- Redis offre des structures de données riches, une persistance optionnelle et un clustering intégré, tandis que Memcached excelle en tant que cache simple, multi-thread et dédié.
- Les cas d’usage courants incluent la gestion de sessions, la mise en cache des réponses API et la limitation de débit — tous des scénarios où la faible latence est primordiale.
- Les magasins clé-valeur complètent les bases de données relationnelles plutôt que de les remplacer. Utilisez-les comme couche de performance, non comme stockage de données principal.
Qu’est-ce qu’une base de données clé-valeur ?
Une base de données clé-valeur est un type de stockage de données NoSQL qui enregistre et récupère les données en utilisant une structure simple en deux parties : une clé unique et sa valeur associée.
Imaginez-la comme un objet JavaScript ou une table de hachage :
"session:user:4821" → { userId: 4821, role: "admin", expires: 1720000000 }
"product:sku:9001" → { name: "Wireless Keyboard", price: 49.99 }Vous recherchez les données par clé. C’est tout. Il n’y a pas de langage de requête, pas de JOINs, pas de schéma. Cette contrainte est précisément ce qui rend les magasins clé-valeur si rapides.
Comment le stockage en mémoire accélère les recherches
La plupart des bases de données clé-valeur — y compris Redis et Memcached — stockent les données en RAM, et non sur disque. Les lectures sur disque se mesurent en millisecondes. Les lectures en mémoire se produisent en microsecondes, souvent 100 à 1000 fois plus rapides.
En interne, ces systèmes utilisent une table de hachage : la clé est hachée vers une adresse mémoire, et la valeur est récupérée directement. Il n’y a pas de balayage, pas d’indexation, pas de planification de requête. Le temps de recherche est effectivement O(1) — constant quelle que soit la taille de l’ensemble de données.
C’est pourquoi les magasins clé-valeur sont le choix par défaut pour les couches de mise en cache, le stockage de sessions et tout service backend où le temps de réponse affecte directement l’expérience utilisateur.
Opérations de base : SET, GET et expiration
Les opérations fondamentales sont minimales par conception :
- SET
key value— stocker une valeur - GET
key— récupérer une valeur - DEL
key— supprimer une valeur - EXPIRE
key seconds— suppression automatique après une durée de vie (TTL)
Le TTL est particulièrement utile pour la mise en cache. Vous stockez une réponse API ou un fragment HTML rendu avec une expiration de 60 secondes. Votre application lit d’abord depuis le cache. Si la clé est manquante ou expirée, elle se rabat sur la base de données et repeuple le cache. Ce modèle — cache-aside — est l’un des modèles les plus courants dans l’architecture web.
Discover how at OpenReplay.com.
Redis vs. Memcached : différences architecturales clés
Les deux sont des magasins clé-valeur en mémoire. Les deux offrent des performances sub-millisecondes. Mais ils font des compromis différents.
| Fonctionnalité | Redis | Memcached |
|---|---|---|
| Types de données | Chaînes, listes, ensembles, hachages, ensembles triés, flux, et plus | Chaînes uniquement |
| Limite de taille de valeur | Jusqu’à 512 Mo | Jusqu’à 1 Mo |
| Persistance | Optionnelle (snapshots RDB ou fichier append-only) | Aucune — purement volatile |
| Multi-threading | Boucle d’événements mono-thread (threading I/O ajouté en 6.0+) | Entièrement multi-thread |
| Récupération de mémoire | Retourne la mémoire libérée au système d’exploitation | Conserve la mémoire allouée via l’allocateur slab jusqu’au redémarrage |
| Clustering intégré | Oui (Redis Cluster, Sentinel) | Nécessite un sharding côté client |
Memcached est un cache dédié. Il est simple, rapide et prévisible. Son allocateur de mémoire basé sur des slabs maintient la fragmentation faible, rendant l’utilisation de la mémoire très cohérente — utile lorsque vous avez besoin d’un plafond mémoire strict. C’est un choix solide lorsque vous mettez en cache de simples chaînes et ne voulez rien de plus.
Redis est un magasin de structures de données en mémoire plus large. Au-delà de la mise en cache, il prend en charge les ensembles triés pour les classements, la messagerie pub/sub, les compteurs atomiques et la persistance optionnelle. Redis moderne est utilisé comme cache, magasin de sessions, courtier de messages et base de données légère — parfois tout à la fois. À noter : la licence Redis a changé à partir de 2024, ce qui a conduit certaines équipes à évaluer Valkey, un fork open-source compatible maintenu sous une licence permissive par la Linux Foundation.
Où les bases de données clé-valeur s’intègrent dans les systèmes orientés frontend
Du point de vue d’un développeur frontend, le stockage clé-valeur apparaît généralement à trois endroits :
- Gestion de sessions — stockage côté serveur des jetons d’authentification, de l’état utilisateur et des préférences
- Mise en cache des réponses API — réduction de la charge de la base de données et accélération des requêtes répétées
- Limitation de débit — suivi du nombre de requêtes par utilisateur ou IP en utilisant des opérations d’incrémentation atomique
Chacun de ces cas bénéficie directement de ce que les bases de données clé-valeur font le mieux : lectures rapides, écritures rapides et logique d’expiration simple.
Quand ne pas utiliser un magasin clé-valeur
Les bases de données clé-valeur ne remplacent pas les bases de données relationnelles. Elles ont de réelles limitations :
- La plupart des requêtes sont basées sur des clés, avec un support limité pour le filtrage ou le tri comparé aux bases de données relationnelles.
- Pas de relations intégrées entre les enregistrements
- Non adaptées aux rapports complexes ou à l’analytique
- La modélisation des données nécessite une conception soigneuse des clés en amont
Si vos données ont des relations ou nécessitent des requêtes flexibles, optez plutôt pour PostgreSQL ou une base de données documentaire. Utilisez le stockage clé-valeur comme couche de performance au-dessus de votre magasin de données principal, non comme substitut.
Conclusion
Les bases de données clé-valeur fonctionnent parce qu’elles échangent la complexité contre la vitesse. Elles font une chose — stocker et récupérer des valeurs par clé, principalement en mémoire — et elles le font exceptionnellement bien. Que vous choisissiez Redis pour sa flexibilité ou Memcached pour sa simplicité, comprendre le modèle sous-jacent vous aide à utiliser ces outils là où ils ont vraiment leur place : comme une couche rapide et ciblée qui maintient vos applications réactives.
FAQ
Redis prend en charge deux mécanismes de persistance optionnels : les snapshots RDB, qui sauvegardent l'ensemble de données à intervalles configurés, et le fichier append-only (AOF), qui enregistre chaque opération d'écriture. Vous pouvez utiliser l'un ou l'autre, ou les deux. Sans persistance activée, les données sont perdues au redémarrage, tout comme Memcached. Pour une mise en cache pure, la persistance est souvent inutile.
Memcached est un bon choix lorsque vous avez besoin d'un cache simple et multi-thread pour des valeurs de chaînes simples et souhaitez une utilisation mémoire prévisible avec une configuration minimale. Si vous n'avez pas besoin de structures de données riches, de persistance ou de clustering intégré, la simplicité de Memcached et son allocateur de mémoire efficace basé sur des slabs en font une option fiable et légère.
Redis et Memcached utilisent tous deux des politiques d'éviction pour gérer les limites de mémoire. Memcached utilise l'éviction LRU (least recently used - moins récemment utilisé) par défaut. Redis offre plusieurs politiques configurables, notamment LRU, LFU (least frequently used - moins fréquemment utilisé), éviction aléatoire et mode sans éviction, qui retourne des erreurs lors des écritures lorsque la mémoire est pleine.
Redis peut fonctionner comme magasin de données principal pour des cas d'usage spécifiques comme la gestion de sessions, les compteurs ou les classements en temps réel, surtout avec la persistance activée. Cependant, il manque de requêtes relationnelles, de schémas imposés et de support transactionnel mature. Pour la plupart des applications, il fonctionne mieux comme couche de performance complémentaire aux côtés d'une base de données relationnelle ou documentaire.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
