Chaînes Redis vs hachages Redis pour représenter JSON :efficacité ?

Cet article peut fournir beaucoup d'informations ici :http://redis.io/topics/memory-optimization

Il existe de nombreuses façons de stocker un tableau d'objets dans Redis (spoiler :J'aime l'option 1 pour la plupart des cas d'utilisation):

Stockez l'objet entier sous forme de chaîne codée JSON dans une seule clé et gardez une trace de tous les objets à l'aide d'un ensemble (ou d'une liste, si plus approprié). Par exemple :
```
INCR id:users
SET user:{id} '{"name":"Fred","age":25}'
SADD users {id}
```
D'une manière générale, c'est probablement la meilleure méthode dans la plupart des cas. S'il y a beaucoup de champs dans l'Objet, vos Objets ne sont pas imbriqués avec d'autres Objets, et vous avez tendance à n'accéder qu'à un petit sous-ensemble de champs à la fois, il peut être préférable d'opter pour l'option 2.

Avantages :considéré comme une "bonne pratique". Chaque objet est une clé Redis à part entière. L'analyse JSON est rapide, en particulier lorsque vous devez accéder à plusieurs champs pour cet objet à la fois. Inconvénients :plus lent lorsque vous n'avez besoin d'accéder qu'à un seul champ.
Stockez les propriétés de chaque objet dans un hachage Redis.
```
INCR id:users
HMSET user:{id} name "Fred" age 25
SADD users {id}
```
Avantages :considéré comme une "bonne pratique". Chaque objet est une clé Redis à part entière. Pas besoin d'analyser les chaînes JSON. Inconvénients :éventuellement plus lent lorsque vous devez accéder à tous/la plupart des champs d'un objet. De plus, les objets imbriqués (objets dans des objets) ne peuvent pas être facilement stockés.
Stockez chaque objet sous forme de chaîne JSON dans un hachage Redis.
```
INCR id:users
HMSET users {id} '{"name":"Fred","age":25}'
```
Cela vous permet de consolider un peu et de n'utiliser que deux clés au lieu de beaucoup de clés. L'inconvénient évident est que vous ne pouvez pas définir le TTL (et d'autres éléments) sur chaque objet utilisateur, car il s'agit simplement d'un champ dans le hachage Redis et non d'une clé Redis complète.

Avantages :L'analyse JSON est rapide, en particulier lorsque vous devez accéder à plusieurs champs pour cet objet à la fois. Moins "polluant" de l'espace de noms de la clé principale. Inconvénients :À peu près la même utilisation de la mémoire que #1 lorsque vous avez beaucoup d'Objets. Plus lent que #2 lorsque vous n'avez besoin d'accéder qu'à un seul champ. Probablement pas considéré comme une "bonne pratique".
Stockez chaque propriété de chaque objet dans une clé dédiée.
```
INCR id:users
SET user:{id}:name "Fred"
SET user:{id}:age 25
SADD users {id}
```
Selon l'article ci-dessus, cette option n'est presque jamais préféré (sauf si la propriété de l'objet doit avoir un TTL spécifique ou quelque chose).

Avantages :Les propriétés d'objet sont des clés Redis complètes, qui ne sont peut-être pas exagérées pour votre application. Inconvénients :lent, utilise plus de mémoire et n'est pas considéré comme une "meilleure pratique". Beaucoup de pollution de l'espace de noms de la clé principale.

Résumé général

L'option 4 n'est généralement pas préférée. Les options 1 et 2 sont très similaires, et elles sont toutes les deux assez courantes. Je préfère l'option 1 (d'une manière générale) car elle vous permet de stocker des objets plus compliqués (avec plusieurs couches d'imbrication, etc.) L'option 3 est utilisée lorsque vous vous souciez vraiment de ne pas polluer l'espace de noms de clé principal (c'est-à-dire que vous ne voulez pas qu'il y ait beaucoup de clés dans votre base de données et que vous ne vous souciez pas de choses comme le TTL, le partage de clé, etc.).

Si je me trompe ici, veuillez envisager de laisser un commentaire et de me permettre de réviser la réponse avant de voter contre. Merci! :)