Passer 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 accéder plus rapidement aux données clé-valeur en mémoire temporaire et avec moins d’efforts que les données stockées dans le stockage de données classique. Les caches sont utiles dans plusieurs scénarios avec plusieurs technologies, telles que la mise en cache d’ordinateurs avec mémoire vive (RAM), 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 cloud pour améliorer la résilience des applications cloud. Les développeurs conçoivent souvent des applications pour mettre en cache les données traitées, puis les réaffecter 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 à ce que la plupart des bases de données peuvent offrir, et améliorer les performances des applications cloud et web.

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 utilisent généralement une base de données classique pour stocker des jeux de données volumineux, durables et complets, ils utilisent un cache pour stocker des sous-ensembles temporaires de données pour une récupération rapide.

Vous pouvez utiliser la mise en cache avec tous les types de magasins de données, y compris les bases de données NoSQL ainsi que les bases de données relationnelles telles que SQL Server, MySQL ou MariaDB. La mise en cache fonctionne également correctement avec de nombreuses plateformes de données spécifiques telles que Azure Database pour PostgreSQL, Azure 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 souhaiterez comprendre la valeur de PostgreSQL avant de l’utiliser pour combiner des magasins de données relationnels et non structurés.

Quels sont les avantages des couches de cache et qu’est-ce que Redis ?

Les développeurs utilisent des caches multiniveaux 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 ou plusieurs couches de cache, vous pouvez améliorer considérablement les performances 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 utilisée pour créer des couches de cache hautes performances et d’autres magasins de données. Une étude récente a montré que l’ajout de Azure Cache pour Redis à un exemple d’application a augmenté ledébit de données de plus de 800 % et amélioré les performances de latence de plus de 1 000 %1.

Les caches peuvent également réduire le coût total de possession (TCO) 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 surapprovisionner les 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 façon dont votre application lit et écrit les données. Votre application écrit-elle beaucoup ou les données sont-elles écrites une seule fois et lues fréquemment ? Les données retournées sont-ils toujours uniques ? Différents modèles d’accès aux données influencent la façon dont vous configurez un cache. Les types de mise en cache courants incluent cache-aside, lecture/écriture par écriture, et write-behind/write-back.

Mis de côté dans le cache

Pour les applications avec des charges de travail nécessitant beaucoup de lectures, les développeurs utilisent souvent un modèle de programmation de cache-aside ou « side-cache ». Ils localisent le cache latéral 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 se trouvent 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 latéral pour améliorer les performances de l’application, maintenir la cohérence entre le cache et le magasin de données, et éviter que les données du cache ne soient périmées.

Cache en lecture/écriture

Les caches en lecture continue restent à jour, tandis qu’avec la mise en cache en écriture, l’application écrit des données dans le cache, puis dans la base de données. Les deux caches sont en ligne avec la base de données et l’application les traite comme le magasin de données principal.

Les caches en lecture seule simplifient les applications où les mêmes données sont demandées plusieurs fois, mais le cache lui-même est plus complexe, tandis que le processus d’écriture via deux étapes peut créer une latence. Les développeurs couplent les deux pour garantir la cohérence des données entre le cache et la base de données, réduire la latence d’écriture dans le cache et faciliter la mise à jour du cache en lecture seule.

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

Cache d’écriture différée/réécriture

Dans ce scénario, l’application écrit les données dans le cache, ce qui est immédiatement reconnu, puis le cache écrit les données dans la base de données en arrière-plan. Les caches en écriture différée, parfois appelés caches d’écriture différée, sont adaptés aux charges de travail en écriture intensives et améliorent les performances d’écriture, car l’application n’a pas besoin d’attendre la fin de l’écriture avant de passer à la tâche suivante.

Cache distribué et magasin de sessions

Les utilisateurs confondent souvent les caches distribués avec les magasins de sessions, qui sont similaires, mais avec 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 comme les applications web.

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

Les applications orientées session effectuent le suivi des actions que les utilisateurs effectuent lorsqu’ils sont connectés aux applications. Pour conserver ces données lorsque l’utilisateur se déconnecte, vous pouvez les conserver dans 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.

En quoi l’utilisation d’un magasin de sessions est-elle différente de 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, 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 améliorer les performances des applications en écrivant des données dans le magasin en mémoire, éliminant ainsi la nécessité d’accéder à une base de données.

Les données écrites dans un magasin de sessions sont généralement de courte durée, tandis que les données mises en cache avec une base de données primaire sont généralement destinées à durer beaucoup plus longtemps. Un magasin de sessions nécessite une réplication, une haute disponibilité et une durabilité des données pour s’assurer 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 latéral sont perdues, il y en a toujours une copie dans la base de données permanente.

Avantages de la mise en cache

Amélioration des performances des applications

L’accès aux 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 piloté par disque. Et avec un accès plus rapide aux données, l’expérience globale de l’application s’améliore considérablement.

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

La mise en cache entraîne moins 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 de réduire les frais de débit.

Performances évolutives et prévisibles

Une instance de cache unique peut gérer des millions de demandes par seconde, offrant un niveau de débit et d’extensibilité que les bases de données ne peuvent pas correspondre. La mise en cache offre également la flexibilité dont vous avez besoin, que vous procédiez à 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 augmenter la charge sur les bases de données back-end. Et si une application rencontre souvent des pics d’utilisation et un débit élevé, les caches en mémoire peuvent atténuer la latence.

À quoi sert la mise en cache ?

Mise en cache de sortie

La mise en cache de sortie permet d’augmenter les performances des pages web en stockant le code source complet des pages, telles que les scripts HTML et client, 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 ou communiquer avec d’autres serveurs.

Mise en cache des données et mise en cache de base 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 base de données est utilisée pour les appels fréquents à des données qui ne changent pas souvent, telles que les données de tarification ou d’inventaire. Il permet aux sites web et aux applications de se charger plus rapidement tout en augmentant le débit et en réduisant la latence de récupération des données à partir des bases de données back-end.

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 tel que Redis est idéal pour stocker efficacement et de manière fiable de grands volumes de données de session, tels que des entrées utilisateur, des entrées de panier ou des préférences de personnalisation à un coût inférieur au stockage ou aux bases de données.

Brokers de messages et architectures de publication/abonnement

Les applications cloud ont souvent besoin d’échanger des données entre les services et peuvent utiliser la mise en cache pour implémenter des architectures publish/subscribe ou Message Broker qui réduisent la latence et accélèrent la gestion des données.

Applications et API

À l’instar des navigateurs, les applications enregistrent des fichiers et des données importants pour recharger rapidement ces informations en cas de besoin. Les réponses d’API mises en cache éliminent la demande ou la charge sur les serveurs d’applications et les bases de données, ce qui accélère les temps de réponse et améliore les performances.

1 Les revendications de performance sont basées sur les données d’une étude qui a été commandée par Microsoft et effectuée par GigaOm en octobre 2020. L’étude a comparé les performances d’une application de test utilisant une base de données Azure avec et sans implémenter Azure Cache pour Redis en tant que solution de mise en cache. Azure SQL Database et Azure Database pour PostgreSQL ont été utilisés comme élément de base de données dans l’étude. Une instance de 2 vCore Gen5 usage général de Azure SQL Database et une instance de usage général de 2 vCores de Azure Database pour PostgreSQL ont été utilisées avec une instance Premium P1 de 6 gigaoctets d’Azure pour Redis. Ces résultats ont été comparés à 8, 16, 24 et 32 instances de usage général vCore Gen5 de Azure SQL Database et 8, 16, 24 et 32 instances de usage général vCore de Azure Database pour PostgreSQL sans Azure Cache pour Redis. Les données d’évaluation proviennent du test de charge de la base de données d’applications web GigaOm, qui simule une application web et une base de données back-end courantes qui sont prises en charge par l’augmentation des requêtes HTTP. Les résultats réels peuvent varier en fonction de la configuration et de la région. Affichez l’étude complète.

Ajoutez une couche de mise en cache agile à 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 les fichiers pour les applications hautes performances, consultez Azure HPC Cache.

Pouvons-nous vous aider ?