Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Cas ElastiCache d'utilisation courants et comment ElastiCache vous y aider
Qu'il s'agisse de fournir les dernières actualités ou un catalogue de produits, ou de vendre des billets d'entrée pour un événement, tout est une question de rapidité. Le succès de votre site web et de votre activité dépend essentiellement de la vitesse à laquelle vous diffusez du contenu.
Dans son article « For Impatient Web Users, an Eye Blink Is Just Too Long to Wait (pour les utilisateurs Web impatients, patienter le temps d'un clignement d'œil est encore trop long)
Si quelqu'un recherche des données, vous pouvez fournir ces données beaucoup plus rapidement si elles sont mises en cache. Cela est vrai que ce soit pour une page web ou un rapport qui permet de prendre des décisions métier. Votre entreprise peut-elle se permettre de ne pas mettre en cache ses pages Web afin de les diffuser avec la plus brève latence possible ?
Intuitivement, il peut être évident de vouloir mettre en cache vos éléments les plus fortement demandés. Mais pourquoi ne pas mettre en cache vos éléments les moins fréquemment demandés ? Même les requêtes de base de données ou les API appels distants les plus optimisés sont nettement plus lents que la récupération d'une clé plate dans un cache en mémoire. Sensiblement plus lent est ce qui a tendance à faire fuir les clients.
Les exemples suivants illustrent certaines des manières dont l'utilisation ElastiCache peut améliorer les performances globales de votre application.
Stockage de données en mémoire
Le principal objectif d'un magasin clé/valeur en mémoire est de fournir un accès ultra rapide (latence inférieure à la milliseconde) et un accès abordable aux copies de données. La plupart des magasins de données ont des zones de données qui sont fréquemment consultées mais rarement mises à jour. En outre, l'interrogation d'une base de données est toujours plus lente et moins chère que la recherche d'une clé dans le cache d'une paire clé-valeur. Certaines requêtes de base de données sont particulièrement onéreuses à effectuer. Par exemple, les requêtes qui impliquent des jointures entre plusieurs tables ou des requêtes avec des calculs intensifs. En mettant en cache les résultats de cette requête, vous ne payez le prix de la requête qu’une seule fois. Ensuite, vous pouvez récupérer rapidement les données plusieurs fois sans avoir à réexécuter la requête.
Que dois-je mettre en cache ?
Lorsque vous choisissez les données à mettre en cache, tenez compte des facteurs suivants :
Vitesse et coûts : il est toujours plus lent et plus cher d'acquérir des données à partir d'une base de données qu'à partir d'un cache. Certaines requêtes de base de données sont, par nature, plus lentes et plus chères que les autres. Par exemple, les requêtes qui effectuent des jointures entre plusieurs tables sont nettement plus lentes et plus onéreuses que les requêtes de table simples. Si les données intéressantes à acquérir nécessitent une requête lente et coûteuse, il serait judicieux de les mettre en cache. Si l'acquisition de données nécessite une requête relativement simple et rapide, elles peuvent toujours être mises en cache en fonction des autres facteurs.
Data and access pattern (Données et modèle d'accès) : déterminer les données à mettre en cache nécessite aussi de comprendre les données elles-mêmes ainsi que leurs modèles d'accès. À titre d'exemple, il n'est pas judicieux de mettre en cache des données qui changent rapidement ou qui sont rarement consultées. Pour que la mise en cache constitue un réel avantage, les données doivent être relativement statiques et fréquemment consultées. Par exemple, un profil personnel sur un site de médias sociaux. En revanche, vous ne voulez pas mettre en cache des données si la mise en cache ne constitue aucun avantage en matière de vitesse et de coût. Par exemple, il n'est pas logique de mettre en cache des pages web qui renvoient des résultats de recherche, car les requêtes et les résultats sont généralement uniques.
Importance : par définition, les données mises en cache sont des données obsolètes. Même si dans certains cas elles ne le sont pas, elles doivent toujours être considérées et traitées comme telles. Pour déterminer si vos données peuvent être mises en cache, déterminez la tolérance de votre application concernant les données obsolètes.
Votre application peut être en mesure de tolérer des données obsolètes dans un contexte, mais pas un autre. Par exemple, supposons que votre site sert un cours d'action coté en bourse. Vos clients peuvent accepter une certaine moralité avec une clause de non-responsabilité selon laquelle les prix peuvent être n minutes de retard. Cependant, si vous communiquez le cours pour la même action à un courtier effectuant une vente ou un achat, vous aurez besoin de données en temps réel.
Envisagez de mettre en cache vos données dans les cas suivants :
elles sont trop lentes ou onéreuses à acquérir en comparaison à la récupération de cache.
Les utilisateurs accèdent souvent à vos données.
Vos données restent relativement les mêmes, ou si elles changent rapidement, le manque de stabilité n'est pas un gros problème.
Pour plus d’informations, consultez les ressources suivantes :
Stratégies de mise en cache dans le guide de l'ElastiCache utilisateur (Memcached)
ElastiCache Témoignages de clients
Pour découvrir comment des entreprises comme AirbnbPBS, Esri et d'autres utilisent Amazon ElastiCache pour développer leurs activités grâce à une meilleure expérience client, consultez Comment les autres utilisent Amazon ElastiCache
Vous pouvez également regarder les vidéos du didacticiel pour découvrir d'autres cas d'utilisation par des ElastiCache clients.
