Vous apprendrez deux techniques de stockage et de récupération des données. Lorsque vous choisissez la méthode à utiliser dans votre application, sélectionnez celle qui simplifie votre architecture en fonction de vos schémas d'accès aux données.
Mais d'abord, assurez-vous que vous pouvez vous connecter à Redis.
Durée du module : 60 minutes
Retour au tableau de bord ElastiCache
(Cliquer pour agrandir)
(Cliquer pour agrandir)
Dans les exemples, chaque fois qu'un point de terminaison est mentionné, vous devez utiliser le nom d'hôte de votre point de terminaison de configuration.
(Cliquer pour agrandir)
syntaxe : shell
$ python
Si les commandes sont suspendues, veuillez consulter la note qui suit l'exemple.
syntaxe : python
syntax: python
>>> import redis
>>> client = redis.Redis.from_url('redis://endpoint:6379')
>>> client.ping()
True
Remarque : Si l’affichage se fige, cela signifie que vous êtes bloqué par les réglages du groupe de sécurité. Vérifiez que votre instance EC2 a accès au groupe de sécurité assigné à votre instance ElastiCache. Imaginons par exemple que votre instance EC2 a été assignée au groupe de sécurité par défaut. Vous pouvez désormais modifier le groupe de sécurité de votre instance Amazon ElastiCache et ajouter une règle TCP personnalisée autorisant les connexions sur le port 6379 à partir de n’importe quelle instance dans le groupe de sécurité par défaut :
Dans Source, commencez à saisir le nom du groupe de sécurité. L'ID du groupe de sécurité apparaîtra et vous pourrez cliquer dessus. Si vous souhaitez en savoir plus sur les groupes de sécurité, consultez la documentation ou les Règles de référence du groupe de sécurité.
(Cliquer pour agrandir)
Dans le dépôt, vous trouverez du code Python que vous pouvez exécuter dans votre instance EC2. Mais vous devez d'abord configurer certaines variables d'environnement :
syntaxe : shell
$ export REDIS_URL=redis://your_redis_endpoint:6379/ $ export DB_HOST=your_mysql_endpoint $ export DB_USER=admin $ export DB_PASS=your_admin_password $ export DB_NAME=tutorial
Notez que les valeurs de mysql_endpoint, redis_endpoint et password sont celles que vous avez enregistrées lors des étapes précédentes.
La première des deux méthodes implémentées dans le modèle de code fonctionne en mettant en cache une représentation sérialisée du résultat de la requête SQL. L'extrait de Python suivant illustre cette logique :
syntaxe : python
def fetch(sql):
result = cache.get(sql)
if result:
return deserialize(result)
else:
result = db.query(sql)
cache.setex(sql, ttl, serialize(result))
return result
Tout d'abord, l'instruction SQL est utilisée comme clé dans Redis, et le cache est examiné pour voir si une valeur est présente. Si une valeur n'est pas présente, l'instruction SQL est utilisée pour interroger la base de données. Le résultat de l'interrogation de la base de données est stocké dans Redis. La variable ttl doit être fixée à une valeur raisonnable, qui dépend de la nature de votre demande. À l'expiration du ttl, Redis expulse la clé et libère la mémoire associée. Ce code est disponible dans le dépôt du didacticiel et vous pouvez l'exécuter tel quel, mais n'hésitez pas à ajouter des déclarations à imprimer ici et là si vous voulez voir la valeur d'une variable à un moment donné.
En termes de stratégie, l'inconvénient de cette approche est que lorsque les données sont modifiées dans la base de données, les changements ne seront pas automatiquement répercutés à l'utilisateur si un résultat précédent a été mis en cache et que son ttl n'est pas encore écoulé.
Un exemple de la façon dont vous utiliseriez la fonction de recherche :
syntaxe : python
print(fetch("SELECT * FROM planet"))
Le résultat serait :
syntaxe : python
[{'id': 10, 'name': 'Mercury'},
{'id': 11, 'name': 'Venus'},
{'id': 12, 'name': 'Earth'},
{'id': 13, 'name': 'Mars'},
{'id': 14, 'name': 'Jupiter'},
{'id': 15, 'name': 'Saturn'},
{'id': 16, 'name': 'Uranus'},
{'id': 17, 'name': 'Neptune'}]
Bien sûr, il s'agit d'un exemple très simple, mais votre application peut tirer un grand profit de la mise en œuvre de ce modèle de mise en cache où il n'y a aucune différence entre un résultat provenant du cache et un résultat provenant directement de la base de données.
Dans le deuxième exemple, vous allez mettre en œuvre des cartes d'un enregistrement de base de données vers un hachage Redis :
syntaxe : python
def planet(id):
key = "planet:" + str(id)
result = cache.hgetall(key)
if result:
return result
else:
sql = "SELECT `id`, `name` FROM `planet` WHERE `id`=%s"
result = db_record(sql, (id,))
if result:
cache.hmset(key, result)
cache.expire(key, ttl)
return result
L'espace-clé dans Redis est plat, mais il existe une convention pour simuler la structure en utilisant des chaînes de caractères séparées par des points. Dans l'exemple, la clé de l'enregistrement avec ID 1 sera avec « plante :1 ». Si cet extrait est suffisant pour présenter un modèle commun, une plus grande abstraction est possible : un module pourrait être chargé de générer les clés, un autre pourrait s'occuper de la construction de la chaîne SQL, etc. De plus, il y a de fortes chances qu'il existe des outils conçus à cette fin dans le langage de programmation que vous utilisez.
L'exemple permet de récupérer des enregistrements soit à partir du cache, soit à partir de la base de données. De même, il pourrait y avoir une fonction chargée de persister un objet dans la base de données.
Dans les deux exemples, vous avez utilisé un Time To Live ou ttl, après quoi Redis expulse la clé. Bien que cela soit suffisant dans la plupart des cas, vous voudrez peut-être supprimer les données obsolètes du cache dès que possible. Si c'est votre cas d'utilisation, assurez-vous de cocher d'autres options comme la stratégie de mise en cache par écriture. Des liens pour plus d'informations sont fournis à la fin de ce didacticiel. À noter, au cas où vous seriez curieux : si les exemples utilisent la commande EXPIRE, Redis propose également la commande EXPIREAT, qui vous permet de spécifier une date et une heure précises auxquelles une clé doit être expulsée. Il prend comme paramètre un timestamp Unix absolu (c'est-à-dire les secondes écoulées depuis le 1er janvier 1970).
Lorsque la quantité de données dépasse le paramètre maxmemory configuré, Redis a différentes manières de réagir en fonction de la politique d'expulsion choisie. Par défaut, ElastiCache for Redis est configuré pour supprimer de la mémoire les clés les moins récemment utilisées avec un jeu de ttl. Le paramètre de la politique d'expulsion est appelé maxmemory-policy, et la valeur par défaut dans ElastiCache est volatile-lru. Une autre option intéressante pour ce cas d'utilisation est la politique volatile-ttl, qui ordonne à Redis de récupérer la mémoire en supprimant les clés ayant le ttl le plus court.
Une fois que vous avez mis en œuvre cette stratégie, assurez-vous de tester votre demande afin de trouver la meilleure valeur pour le ttl et la meilleure stratégie d'expulsion. Vérifiez la performance de votre demande avec un cache vide et avec un cache plein.