Trace Id is missing
Ignorez la navigation

Qu’est-ce que la mise en cache ?

Les développeurs et les professionnels de l’informatique utilisent la mise en cache pour enregistrer et consulter les données clé-valeur dans la mémoire temporaire plus rapidement et avec moins d’efforts que les données stockées dans le stockage de données conventionnel. Les caches sont utiles dans plusieurs scénarios avec plusieurs technologies, comme la mise en cache de l’ordinateur avec la mémoire RAM (Random Access Memory), la mise en cache réseau sur un réseau de distribution de contenu, un cache web pour les données multimédias web ou un cache nuage pour améliorer la résilience des applications nuage. Les développeurs conçoivent souvent des applications de façon à ce qu’elles mettent en cache les données traitées qui sont ensuite redéfinies pour traiter les demandes plus rapidement que dans les requêtes de base de données standard.

Vous pouvez utiliser la mise en cache pour réduire les coûts de base de données, fournir un débit plus élevé et une latence inférieure à celle que la plupart des bases de données peuvent offrir, et améliorer les performances des applications web et nuage.

Comment la mise en cache fonctionne-t-elle pour les bases de données ?

Les développeurs peuvent compléter une base de données primaire avec un cache de base de données, qu’ils peuvent placer dans la base de données ou l’application, ou configurer en tant que couche autonome. Bien qu’ils s’appuient généralement sur une base de données conventionnelle pour stocker des jeux de données volumineux, durables et complets, ils utilisent un cache pour stocker des sous-ensembles de données temporaires pour une récupération rapide.

Vous pouvez utiliser la mise en cache avec tous les types de magasins de données, notamment les bases de données NoSQL et les bases de données relationnelles telles que SQL Server, MySQL ou  MariaDB. La mise en cache fonctionne également avec de nombreuses plateformes de données spécifiques, telles que Azure Database pour PostgreSQLAzure SQL Database ou  Azure SQL Managed Instance. Nous vous recommandons de rechercher le type de magasin de données qui répond le mieux à vos besoins avant de commencer à configurer une architecture de données. Par exemple, vous devez comprendre ce qu’est PostgreSQL avant de l’utiliser pour combiner des magasins de données relationnels et non structurés.

Avantages des couches de cache et présentation de Redis

Les développeurs utilisent des caches à plusieurs niveaux appelés couches de cache pour stocker différents types de données dans des caches distincts en fonction de la demande. En ajoutant une couche de cache, ou plusieurs, vous pouvez améliorer considérablement les performances en termes de débit et de latence d’une couche de données.

Redis est une structure de données en mémoire open source populaire qui permet de créer des couches de cache hautes performances et d’autres magasins de données. Une étude récente a montré que l’ajout d’Azure Cache pour Redis à un exemple d’application a augmenté le débit de données de plus de 800 % et a amélioré les performances de latence de plus de 1 000 %1.

Les caches peuvent également réduire le coût total de possession d’une couche de données. En utilisant des caches pour traiter les requêtes les plus courantes et réduire la charge de la base de données, vous pouvez réduire la nécessité de surprovisionner des instances de base de données, ce qui entraîne des économies significatives et une réduction du coût total de possession.

Types de mise en cache

Votre stratégie de mise en cache dépend de la manière dont votre application lit et écrit les données. Votre application est-elle gourmande en écritures, ou les données sont-elles écrites une fois et lues fréquemment ? Les données renvoyées sont-elles toujours uniques ? Différents modèles d’accès aux données influencent la configuration d’un cache. Les types de mise en cache courants incluent le cache secondaire, de double lecture/écriture et d’écriture différée.

Modèle Cache-Aside

Pour les applications avec des charges de travail nécessitant beaucoup de lectures, les développeurs utilisent souvent un modèle de programmation Cache-Aside (ou "cache secondaire"). Ils placent le cache secondaire en dehors de l’application, qui peut ensuite se connecter au cache pour interroger et récupérer des données ou directement avec la base de données si les données ne sont pas dans le cache. Lorsque l’application récupère les données, elle les copie dans le cache pour les requêtes ultérieures.

Vous pouvez utiliser un cache secondaire pour améliorer les performances de l’application, maintenir la cohérence entre le cache et le magasin de données et empêcher l’obsolescence des données du cache.

Cache de double lecture/écriture

Les caches de double lecture sont toujours à jour, tandis qu’avec la mise en cache en double écriture, l’application écrit les données dans le cache, puis dans la base de données. Les deux caches sont alignés sur la base de données et l’application les traite en tant que magasin de données principal.

Les caches de double lecture permettent de simplifier les applications où les demandes concernent souvent les mêmes données, mais le cache lui-même est plus complexe, tandis que le processus d’écriture différée peut créer de la latence. Les développeurs associent les deux pour garantir la cohérence des données entre le cache et la base de données, réduire la latence du cache de double écriture et faciliter la mise à jour du cache de double lecture.

Avec la mise en cache de double lecture/écriture, les développeurs peuvent simplifier le code d’application, augmenter la scalabilité du cache et réduire la charge de la base de données.

Cache en écriture différée

Dans ce scénario, l’application écrit des données dans le cache, qui est immédiatement reconnu, puis le cache lui-même réécrit les données dans la base de données en arrière-plan. Les caches en écriture différée conviennent mieux aux charges de travail gourmandes en écritures et améliorent les performances en écriture, car l’application n’a pas besoin d’attendre que l’écriture se termine avant de passer à la tâche suivante.

Cache distribué et magasin de sessions

Les personnes confondent souvent les caches distribués avec les magasins de sessions, qui sont similaires mais ont des exigences et des objectifs différents. Au lieu d’utiliser un cache distribué pour compléter une base de données, les développeurs implémentent des magasins de sessions, qui sont des magasins de données temporaires au niveau de la couche utilisateur, pour les profils, les messages et d’autres données utilisateur dans les applications orientées session, telles que les applications web.

Qu’est-ce qu’un magasin de sessions ?

Les applications orientées session suivent les actions que les utilisateurs effectuent pendant qu’ils sont connectés aux applications. Pour conserver ces données lorsque l’utilisateur se déconnecte, vous pouvez utiliser un magasin de sessions, ce qui améliore la gestion des sessions, réduit les coûts et accélère les performances de l’application.

Quelle est la différence entre un magasin de sessions et la mise en cache d’une base de données ?

Dans un magasin de sessions, les données ne sont pas partagées entre différents utilisateurs, tandis qu’avec la mise en cache, les différents utilisateurs peuvent accéder au même cache. Les développeurs utilisent la mise en cache pour améliorer les performances d’une base de données ou d’une instance de stockage, tandis qu’ils utilisent des magasins de sessions pour booster les performances de l’application en écrivant des données dans le magasin en mémoire, ce qui évite d’avoir à accéder à une base de données.

Les données écrites dans un magasin de sessions sont généralement éphémères, tandis que celles qui sont mises en cache avec une base de données primaire sont généralement conçues pour durer plus longtemps. Un magasin de sessions requiert la réplication, la haute disponibilité et la durabilité des données pour garantir que les données transactionnelles ne sont pas perdues et que les utilisateurs restent engagés. En revanche, si les données d’un cache secondaire sont perdues, il y a toujours une copie de celles-ci dans la base de données permanente.

Avantages de la mise en cache

Amélioration des performances des applications

La lecture de données à partir d’un cache en mémoire est beaucoup plus rapide que l’accès aux données à partir d’un magasin de données basé sur un disque. Et avec un accès plus rapide aux données, l’expérience globale de l’application s’améliore de manière significative.

Réduction des coûts et de l’utilisation des bases de données

La mise en cache permet de réduire le nombre de requêtes de base de données, ce qui améliore les performances et réduit les coûts en limitant la nécessité de mettre à l’échelle l’infrastructure de base de données et en réduisant les frais de débit.

Performances prédictibles et scalables

Une même instance de cache peut gérer des millions de demandes par seconde, ce qui offre un niveau de débit et de scalabilité que les bases de données ne peuvent pas égaler. La mise en cache offre également la flexibilité dont vous avez besoin pour effectuer un scale-out ou un scale-up de vos applications et magasins de données. Ensuite, votre application peut permettre à de nombreux utilisateurs d’accéder simultanément aux mêmes fichiers, sans avoir à améliorer la charge sur les bases de données principales. Et si une application rencontre souvent des pics d’utilisation et un débit élevé, les caches en mémoire peuvent réduire la latence.

À quoi sert la mise en cache ?

Mise en cache de sortie

La mise en cache de sortie permet d’accroître les performances des pages web en stockant le code source complet des pages, comme le HTML et les scripts clients qu’un serveur envoie aux navigateurs pour le rendu. Chaque fois qu’un utilisateur consulte la page, le serveur met en cache le code de sortie dans la mémoire de l’application. Cela permet à l’application de traiter les demandes sans exécuter de code de page ni communiquer avec d’autres serveurs.

Mise en cache des données et mise en cache des bases de données

La vitesse et le débit de la base de données peuvent être des facteurs clés dans les performances globales de l’application. La mise en cache de la base de données est utilisée pour les appels fréquents aux données qui ne changent pas souvent, comme les données d’inventaire ou de tarification. Elle permet aux sites web et aux applications de charger plus rapidement tout en optimisant le débit et en diminuant la latence d’extraction de données des bases de données principales.

Stockage des données de session utilisateur

Les utilisateurs de l’application génèrent souvent des données qui doivent être stockées pendant de courtes périodes. Un magasin de données en mémoire comme Redis est parfait pour stocker de manière efficace et fiable des volumes importants de données de session, comme les entrées utilisateur, les entrées de panier d’achat ou les préférences de personnalisation à un coût inférieur à celui des bases de données ou du stockage.

Courtiers de messages et architectures de publication/abonnement

Les applications nuage doivent souvent échanger des données entre les services, et elles peuvent utiliser la mise en cache pour implémenter des architectures de publication/abonnement ou de courtier de messages qui réduisent la latence et accélèrent la gestion des données.

Applications et API

Tout comme les navigateurs, les applications sauvegardent des données et fichiers importants pour recharger rapidement ces informations si nécessaire. Les réponses d’API mises en cache éliminent la demande ou la charge sur les bases de données et les serveurs d’applications, ce qui offre des temps de réponse plus rapides et de meilleures performances.

[1] Les chiffres sur les performances sont extraits des données d’une étude commandée par Microsoft et menée par GigaOm en octobre 2020. L’étude compare les performances d’une application test utilisant une base de données Azure avec et sans implémentation d’Azure Cache pour Redis comme solution de mise en cache. Dans le cadre de cette étude, Azure SQL Database et Azure Database pour PostgreSQL ont été utilisés comme élément de base de données. Une instance Gen 5 Usage général à 2 vCore d’Azure SQL Database et une instance Usage général à 2 vCore d’Azure Database pour PostgreSQL ont été utilisées avec une instance P1 haut de gamme de 6 Go d’Azure pour Redis. Ces résultats ont été comparés avec des instances Gen 5 Usage général à 8, 16, 24 et 32 vCore d’Azure SQL Database et des instances Usage général à 8, 16, 24 et 32 vCore d’Azure Database pour PostgreSQL sans Azure Cache pour Redis. Les données de référence proviennent du test de charge « GigaOm Web Application Database Load Test » qui simule une application web commune et une base de données back-end soumise à des requêtes HTTP croissantes. Les résultats réels peuvent varier en fonction de la configuration et de la région. Lisez l’intégralité de l’étude.

Compte gratuit

Essayez les services Azure cloud computing gratuitement pendant 30 jours maximum.

Paiement à l’utilisation

Commencez en optant pour une tarification à l’utilisation. Pas d’engagement initial. Annulation possible à tout moment.

Ajoutez une couche de mise en cache grande rapidité à votre application avec un service Redis complètement managé. Découvrez comment bien démarrer avec Azure Cache pour Redis.

Si vous souhaitez exécuter une mise en cache flexible basée sur des fichiers pour les applications à hautes performances, consultez les informations sur Azure HPC Cache.