Redis est facile à réduire à "cache clé-valeur rapide".
Cela ignore la partie qui le rend précieux : Redis expose des structures de données spécialisées avec des compromis de performance et de mémoire très spécifiques.
HyperLogLog est le meilleur exemple
Si vous avez besoin d'un comptage approximatif des valeurs uniques, un ensemble peut être excessif.
Un ensemble Redis vous donne une unicité exacte, mais le coût en mémoire augmente avec le nombre de membres.
HyperLogLog échange l'exactitude contre une utilisation mémoire fixe minuscule :
PFADD stream:123:views 203.0.113.10
PFADD stream:123:views 203.0.113.11
PFCOUNT stream:123:views
Cela en fait un bon choix pour :
- les visiteurs uniques approximatifs
- les événements uniques approximatifs
- la mesure des tendances où une petite erreur est acceptable
Ce n'est pas adapté lorsque des comptes exacts sont requis pour la facturation, la conformité ou le mouvement d'argent.
C'est pourquoi une petite preuve de concept est importante avant l'adoption. Alimentez HyperLogLog avec un trafic réaliste et comparez le résultat approximatif avec un ensemble exact sur un ensemble de données échantillon. Le gain mémoire est souvent excellent, mais le taux d'erreur acceptable doit être vérifié par rapport au cas d'utilisation réel du produit, et ne doit pas être supposé à partir d'un article de blog.
C'est le schéma avec les structures de données Redis en général : chacune encode un compromis utile.
Pensez en formes de problèmes
Redis devient plus puissant lorsque vous vous demandez :
- ai-je besoin d'exactitude ou d'approximation ?
- ai-je besoin d'un ordre ?
- ai-je besoin d'unicité ?
- ai-je besoin d'un comportement par fenêtre temporelle ?
Cela mène naturellement aux ensembles ordonnés, aux bitmaps, à HyperLogLog, aux flux (streams) et au reste de la boîte à outils.
Lectures complémentaires