Boutiques en ligne
Les pages produits, les prix et les niveaux de stock sont lus des milliers de fois par seconde et rafraîchis par tag quand le catalogue change.
Gardez vos données les plus sollicitées en mémoire et répondez aux lectures en bien moins d'une milliseconde, sur un moteur qui fait travailler chaque cœur.
Un succès revient directement de la mémoire. La base de données n'est pas sollicitée.
Une démonstration animée avec de vraies commandes HotKV et des exemples de réponses. Cliquez sur une étape pour y accéder directement. Les commandes et les réponses restent en anglais, exactement comme vous les saisissez et les voyez dans HotKV.
Les bases de données sont lentes et coûteuses à solliciter pour des données lues des milliers de fois par seconde. Chaque affichage de page, appel d'API ou rafraîchissement de tableau de bord répète la même requête, et la base de données devient le goulot d'étranglement bien avant votre application.
HotKV se place devant la base de données et garde les résultats en mémoire. Votre application lit d'abord dans HotKV et ne se rabat sur la base de données qu'en cas d'échec. Comme HotKV exécute les commandes sur de nombreux threads à la fois, un cache très sollicité ne fait pas passer tous les clients par un seul cœur, et les tags vous permettent d'invalider tout un groupe d'entrées quand les données sous-jacentes changent.
Un succès revient directement de la mémoire. La base de données n'est pas sollicitée.
GET product:1001En cas d'échec, l'application lit une fois la base de données et met le résultat en cache pour cinq minutes.
SET product:2002 "{\"name\":\"Oak desk\",\"price\":420}" EX 300Chaque page en cache qui affiche des produits d'éclairage porte le même tag.
TAG.SET product:1001 catalog:lightingLes prix ont changé. Listez chaque clé portant le tag et supprimez-les dans un seul pipeline.
TAG.MEMBERS catalog:lightingUn jeton flash, déjà défini, qui doit disparaître après 250 ms, avec une précision à la nanoseconde.
NEXPIRE flash:token:9 250000000Les pages produits, les prix et les niveaux de stock sont lus des milliers de fois par seconde et rafraîchis par tag quand le catalogue change.
Les réponses des endpoints populaires sont mises en cache avec des TTL courts, et les pics de trafic touchent la mémoire au lieu de la base de données.
Les fragments rendus et les métadonnées des articles sont mis en cache pendant quelques minutes et invalidés par tag quand un éditeur publie.
EXPIRE et PEXPIRE fonctionnent comme prévu. NEXPIRE ajoute la précision à la nanoseconde.
EXPIREPEXPIRENEXPIREÉtiquetez les clés avec TAG.SET, puis retrouvez chaque clé portant une étiquette.
TAG.SETTAG.MEMBERSLes grosses charges utiles peuvent être compressées pour qu'une plus grande part de vos données actives tienne en mémoire.
Les commandes s'exécutent sur des threads parallèles, et le débit augmente avec le nombre de cœurs. Les chiffres sont sur la page Performances.
GETMGETHotKV parle le protocole Redis (RESP2 et RESP3), et les clients Redis standard s'y connectent. Vérifiez dans la référence des commandes celles dont vous dépendez.
Étiquetez les clés avec TAG.SET au moment de les mettre en cache, puis appelez TAG.MEMBERS et supprimez ce qui est renvoyé.
C'est le débit de GET en pipeline issu du benchmark publié de HotKV. La méthode et le matériel sont décrits sur la page Performances.
HotKV parle le protocole Redis. Vous pouvez donc y connecter un client existant et exécuter ces mêmes commandes.