La commande SET est une bête étrange

La commande SET est une bête étrange

L’hélicoprion est un animal maintenant éteint mais étrange qui parcourait les mers du début du Permien. Il ressemble plus ou moins en taille et en forme à un grand requin blanc contemporain. Très probablement, c’était un redoutable prédateur des mers. Ce qui le distinguait, c’était qu’il avait une «verticille de dent», ce qui s’apparente un peu à une scie circulaire à dents de requin située à l’intérieur de la mâchoire inférieure. On dirait que ce serait une bonne idée, mais l’évolution avait une idée différente et nous n’avons pas d’animaux existants comme ça. Une impasse évolutive.

À certains égards, le Redis POSITIONNER La commande est comme l’Helicoprion, mais elle parcourt toujours les eaux des serveurs Redis partout dans le monde. Il s’agit d’une commande très précoce avec des fonctionnalités inhabituelles qui semblent être une bonne idée mais qui peuvent s’avérer dangereuses mais profondément utiles lorsqu’elles sont correctement utilisées.

D’autre part, la commande SET semble être aussi simple et ordinaire que n’importe quoi. Nous l’utilisons comme l’une des premières commandes lors de l’apprentissage et nous l’utilisons pour effectuer un test simple afin de nous assurer que Redis fonctionne correctement. Je ne peux pas vous dire combien de fois j’ai tapé la commande:

> SET foo bar

Donc, cela n’a rien d’exotique à première vue. Mais cache-t-il quelque chose ?

SET : destructeur de données

Revenons à notre exemple simple de SET. Ajoutons un peu plus de contexte :

> UNLINK foo
(integer) 1
> HSET foo bar 123
(integer) 1
> SET foo bar
OK

Avez-vous attrapé la bizarrerie ici avec SET? La clé existante fou était de type hash (en raison de la HSET), mais quand j’ai exécuté SET immédiatement après, il acceptait toujours la commande. C’est en fait profondément étrange par rapport aux autres commandes Redis. Prenons les mêmes commandes mais inversons l’ordre des deux dernières :

> UNLINK foo
(integer) 1
> SET foo bar
OK
> HSET foo bar 123
(error) WRONGTYPE Operation against a key holding the wrong kind of value

Vous pouvez voir que SET ne tient pas compte de l’existence ou du type de clé et écrit toujours. Les hachages, en revanche, génèrent une erreur lorsqu’ils sont confrontés à une clé non vide d’un type différent. Il en va de même pour tous les types de données à l’exception des chaînes et plus particulièrement de la commande SET et de quelques variantes (PSETEX, SETEX, MSET). Prenez ceci, par exemple :

> HSET foo bar 123
(integer) 1
> APPEND foo bar
(error) WRONGTYPE Operation against a key holding the wrong kind of value
> INCR foo
(error) WRONGTYPE Operation against a key holding the wrong kind of value
> SETBIT foo 1 1
(error) WRONGTYPE Operation against a key holding the wrong kind of value
> BITFIELD foo SET u8 0 1
(error) WRONGTYPE Operation against a key holding the wrong kind of value
> INCRBY foo 1
(error) WRONGTYPE Operation against a key holding the wrong kind of value
> INCRBYFLOAT foo 1
(error) WRONGTYPE Operation against a key holding the wrong kind of value
> SETRANGE foo 1 barbar
(error) WRONGTYPE Operation against a key holding the wrong kind of value

SETNX et SET…NX (plus sur cela plus tard) sont une remarque intéressante, ils seront SET si la clé n’existe pas, renvoyant un 1 si elle était définie et 0 sinon. Ainsi, il ne s’agit pas de vérification de type, mais plutôt de vérification de présence.

Dans l’ensemble, SET ne se soucie tout simplement pas des types. Il écrit toujours, très peu de choses peuvent se dresser sur son chemin.

Un TYPE trois types.

Si vous avez fait plusieurs fois le tour du bloc dans Redis, vous savez que vous pouvez récupérer le type de données stockées sur une clé en utilisant le TAPER commande. Ainsi, par exemple, revenons à fou:

> SET foo bar
OK
> TYPE foo
string

Assez facile. Vous définissez la valeur “bar” à la clé fou. Maintenant, voyons autre chose :

> SET foo 1234
OK
> TYPE foo
String
> GETRANGE foo 2 3
"34"

Ainsi, vous pourriez penser que le nombre 1234 est stocké sous forme de caractères, et vous auriez plus ou moins raison. Cependant, il y a plus dans cette histoire :

> INCR foo
(integer) 1235
> GETRANGE foo 2 3
"35"

Cela montre que Redis comprend les caractères comme du texte et des chiffres – vous pouvez le considérer comme une forme de frappe lâche. Mais ça devient bizarre :

> SET foo "hello world"
OK
> INCR foo
(error) ERR value is not an integer or out of range

Évidemment, Redis ne peut pas incrémenter un non-numéro. Mais il y a plus de détails à couvrir. Redis comprend également les valeurs flottantes. Prenons cet exemple :

> SET foo 1.2
OK
> INCR foo
(error) ERR value is not an integer or out of range
> INCRBYFLOAT foo 0.8
"2"
> INCR foo
(integer) 3

Vous pouvez voir que la valeur initiale est mise en tant que flotteur et donc le INCR (qui est pour les entiers) ne fonctionnerait pas. Cependant, INCRBYFLOAT fonctionne. Cela change la valeur en un nombre entier qui peut être utilisé par la précédente commande INCR non autorisée.

Une commande, plusieurs arguments

L’autre chose qui distingue la commande est la possibilité de fournir deux catégories d’arguments optionnels : une catégorie pour l’expiration et l’autre pour la vérification de l’existence. Examinons la première catégorie : les arguments d’expiration.

Pour la plupart des commandes, si vous souhaitez faire expirer une clé immédiatement, vous devez émettre le EXPIRER ou PEXPIRE immédiatement après, le plus souvent dans un MULTI / EXEC transaction. Par exemple:

> MULTI
OK
> SADD baz alpha beta gamma
QUEUED
> EXPIRE baz 10
QUEUED
> EXEC
1) (integer) 3
2) (integer) 1

Cela garantit que vous ne pouvez pas être interrompu entre votre SADD et votre commande EXPIRE. Vous savez qu’immédiatement après l’EXEC, vous aurez un set qui expire dans 10 secondes. Avec SET, cependant, vous pouvez le faire sans transaction.

> SET foo bar EX 10
OK

Alternativement, vous pouvez utiliser PX au lieu de EX pour expirer en unités de millisecondes au lieu de secondes. C’est un raccourci pratique qui peut également être exprimé avec SETEX et PSETEX. Je considère ces commandes comme des raccourcis uniquement – elles échangent quelques frappes dans votre application et quelques octets vers et depuis le serveur pour un peu moins de lisibilité et de flexibilité.

L’autre catégorie d’arguments, NX / XX, contrôle le fonctionnement de SET avec des données existantes ou inexistantes. La clé NX définit une valeur uniquement si la clé n’existe pas. Alors, prenez cet exemple :

> UNLINK foo
(integer) 0
> SET foo 1234 NX
OK
> GET foo
"1234"
> SET foo 5678 NX
(nil)
> GET foo
"1234"

Vous pouvez voir que la 4ème commande ne fait rien car la clé fou existe déjà. Cela a de nombreuses utilisations : définir des valeurs par défaut et sans écraser les données existantes, empêcher les SETS accidentels lorsque l’entrée de l’utilisateur fait partie d’une clé, etc.

L’inverse de ceci est la commande XX. Cela ne définit une valeur que lorsque la clé existe déjà.

> UNLINK foo
(integer) 1
> SET foo 1234 XX
(nil)
> set foo 1234
OK
> SET foo 5678 XX
OK

Cela peut être utilisé pour limiter les écritures à des clés expressément définies. Une chose que cela ne fait pas est la vérification de type. Ainsi, XX écrasera toujours une clé d’un autre type, tant qu’elle existe.

Alors, SET est-il dangereux/mauvais/non suggéré ?

Absolument pas. SET est fondamental pour le fonctionnement de nombreux excellents modèles dans Redis. Cependant, il possède un certain nombre de fonctionnalités qui sont fondamentalement différentes du reste de Redis. Il est important de savoir comment ces fonctionnalités fonctionnent afin de faire des hypothèses appropriées sur la façon de structurer votre espace de clés et d’utiliser Redis dans votre application.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *