Cas ElastiCache d'utilisation courants et comment ElastiCache vous pouvez vous y aider - Amazon ElastiCache

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 pouvez vous y aider

Qu'il s'agisse de communiquer les dernières actualités, le classement des 10 meilleurs, 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) », le New York Times note que les utilisateurs peuvent enregistrer une différence de 250 millisecondes (1/4 de seconde) entre des sites concurrents. Les utilisateurs ont tendance à éliminer le site le plus lent en faveur du site le plus rapide. Les tests effectués chez Amazon, cités dans l'article How Webpage Load Time Is Related to Visitor Loss (comment le délai de chargement d'une page Web est lié à la perte de visiteurs), a révélé que pour chaque augmentation du temps de chargement de 100 ms (1/10 de seconde), les ventes diminuent de 1 %.

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 Stratégies de mise en cache pour Memcached.

Classements de jeu

Avec les ensembles OSS triés par Valkey ou Redis, vous pouvez déplacer la complexité informatique des classements de votre application vers votre cluster.

Des classements, tels que les 10 meilleurs pour un jeu, nécessitent des calculs complexes. Cela est particulièrement vrai lorsque le nombre de joueurs est important et que les scores changent constamment. Les ensembles OSS triés Valkey et Redis garantissent à la fois l'unicité et l'ordre des éléments. Avec les ensembles triés, chaque fois qu'un nouvel élément est ajouté à l'ensemble trié, il est reclassé en temps réel. Cela est ensuite ajouté à l'ensemble dans son ordre numérique approprié.

Dans le schéma suivant, vous pouvez voir comment fonctionne un classement de ElastiCache jeu.

Image : Schéma du classement des ElastiCache jeux
Exemple Classement Valkey ou Redis OSS

Dans cet exemple, quatre joueurs et leurs résultats sont saisis dans une liste triée à l'aide de ZADD. La commande ZREVRANGEBYSCORE répertorie les joueurs en fonction de leur score, par ordre décroissant. Ensuite, la commande ZADD est utilisée pour mettre à jour le score de Jeanne en remplaçant l'entrée existante. Enfin, ZREVRANGEBYSCORE répertorie les joueurs en fonction de leur score, par ordre décroissant. La liste montre que Jeanne a grimpé dans les classements.

ZADD leaderboard 132 Robert ZADD leaderboard 231 Sandra ZADD leaderboard 32 June ZADD leaderboard 381 Adam ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) Sandra 3) Robert 4) June ZADD leaderboard 232 June ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) June 3) Sandra 4) Robert

La commande suivante permet à Jeanne de voir où elle se classe parmi tous les joueurs. Comme le classement est basé sur zéro, ZREVRANKrenvoie un 1 pour June, qui est en deuxième position.

ZREVRANK leaderboard June 1

Pour plus d'informations, consultez la documentation de Valkey sur les ensembles triés.

Messagerie (Pub/Sub)

Lorsque vous envoyez un message électronique, vous envoyez à un ou plusieurs destinataires spécifiés. Dans le paradigme OSS pub/sub de Valkey et Redis, vous envoyez un message à une chaîne spécifique sans savoir qui, le cas échéant, le reçoit. Les personnes qui reçoivent le message sont celles qui sont abonnées à la chaîne. Par exemple, supposons que vous vous abonniez à la chaîne news.sports.golf. Vous et toutes les autres personnes abonnées à la chaîne news.sports.golf reçoivent des messages publiés dans news.sports.golf.

La fonctionnalité PUB/Sub n'a aucun rapport avec un espace clé. Par conséquent, elle n'interfère à aucun niveau. Dans le schéma suivant, vous pouvez trouver une illustration de la ElastiCache messagerie avec Valkey et RedisOSS.

Image : schéma ElastiCache de messagerie

Abonnement en cours

Pour recevoir des messages sur une chaîne, vous devez vous y être abonné. Vous pouvez vous abonner à une seule chaîne, à plusieurs chaînes spécifiées ou à toutes les chaînes qui correspondent à un modèle. Pour annuler un abonnement, vous devez vous désinscrire de la chaîne spécifiée lors de l'inscription. Ou, si vous vous êtes abonné à l'aide de la mise en correspondance de modèle, vous vous désabonnez en utilisant le même modèle que celui utilisé précédemment.

Exemple – Abonnement à une chaîne unique

Pour vous abonner à une seule chaîne, utilisez la SUBSCRIBE commande indiquant la chaîne à laquelle vous souhaitez vous abonner. Dans l'exemple suivant, un client s'abonne à la chaîne news.sports.golf.

SUBSCRIBE news.sports.golf

Après un certain temps, le client annule son abonnement à la chaîne à l'aide de la UNSUBSCRIBE commande spécifiant la chaîne dont il souhaite se désabonner.

UNSUBSCRIBE news.sports.golf
Exemple – Abonnements à plusieurs chaînes spécifiées

Pour vous abonner à plusieurs chaînes spécifiques, listez les chaînes à l'aide de la SUBSCRIBE commande. Dans l'exemple suivant, un client souscrit aux chaînes news.sports.golf, news.sports.soccer et news.sports.skiing.

SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing

Pour annuler un abonnement à une chaîne spécifique, utilisez la UNSUBSCRIBE commande et spécifiez la chaîne dont vous souhaitez vous désabonner.

UNSUBSCRIBE news.sports.golf

Pour annuler les abonnements à plusieurs chaînes, utilisez la UNSUBSCRIBE commande et spécifiez les chaînes dont vous souhaitez vous désabonner.

UNSUBSCRIBE news.sports.golf news.sports.soccer

Pour annuler tous les abonnements, utilisez UNSUBSCRIBE et spécifiez chaque canal. Ou utilisez UNSUBSCRIBE et ne spécifiez pas de canal.

UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing

or

UNSUBSCRIBE
Exemple – Abonnements à l'aide la correspondance de modèles

Les clients peuvent s'abonner à toutes les chaînes correspondant à un modèle à l'aide de la PSUBSCRIBE commande.

Dans l'exemple suivant, un client souscrit à toutes les chaînes de sport. Vous ne listez pas toutes les chaînes de sport individuellement, comme vous le faites à l'aide de SUBSCRIBE. Au lieu de cela, avec la commande PSUBSCRIBE, vous utilisez la correspondance des motifs.

PSUBSCRIBE news.sports.*
Exemple Annulation d'abonnements

Pour annuler des abonnements à ces chaînes, utilisez la commande PUNSUBSCRIBE.

PUNSUBSCRIBE news.sports.*
Important

La chaîne de canal envoyée à une SUBSCRIBE commande [P] et à la UNSUBSCRIBE commande [P] doit correspondre. Vous ne pouvez pas PSUBSCRIBE vers news.* et PUNSUBSCRIBE depuis news.sports.* ou UNSUBSCRIBE depuis news.sports.golf.

Publication

Pour envoyer un message à tous les abonnés d'une chaîne, utilisez la commande PUBLISH, en spécifiant la chaîne et le message. L'exemple suivant publie le message, « C'est samedi et il fait beau. Je suis dirigé vers les liens. » vers la chaîne news.sports.golf.

PUBLISH news.sports.golf "It's Saturday and sunny. I'm headed to the links."

Un client ne peut pas publier sur une chaîne à laquelle il est abonné.

Pour plus d'informations, consultez Pub/Sub dans la documentation de Valkey.

Données de recommandation (hachages)

L'utilisation de INCR ou DECR dans Valkey ou Redis OSS simplifie la compilation des recommandations. Chaque fois qu'un utilisateur « aime » un produit, vous incrémentez un compteur item:productID:like. Chaque fois qu'un utilisateur « n'aime pas » un produit, vous incrémentez un compteur item:productID:like. À l'aide de hachages, vous pouvez également tenir à jour une liste de tous ceux qui ont aimé ou non un produit.

Exemple – « J'aime » et « Je n'aime pas »
INCR item:38923:likes HSET item:38923:ratings Susan 1 INCR item:38923:dislikes HSET item:38923:ratings Tommy -1

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 visionner les vidéos du didacticiel pour découvrir d'autres cas d'utilisation par des ElastiCache clients.