Redis-strings versus Redis-hashes om JSON weer te geven:efficiëntie?

Dit artikel kan hier veel inzicht bieden:http://redis.io/topics/memory-optimization

Er zijn veel manieren om een ​​reeks objecten in Redis op te slaan (spoiler :Ik hou van optie 1 voor de meeste gevallen):

1. Sla het hele object op als JSON-gecodeerde tekenreeks in een enkele sleutel en houd alle objecten bij met behulp van een set (of lijst, indien meer van toepassing). Bijvoorbeeld:

   INCR id:users
   SET user:{id} '{"name":"Fred","age":25}'
   SADD users {id}
   

   Over het algemeen is dit in de meeste gevallen waarschijnlijk de beste methode. Als er veel velden in het object zijn, zijn uw objecten niet genest met andere objecten en hebt u de neiging om slechts een kleine subset van velden tegelijk te gebruiken, dan is het misschien beter om voor optie 2 te kiezen.

   Voordelen :beschouwd als een "goede praktijk". Elk object is een volwaardige Redis-sleutel. JSON-parsing is snel, vooral wanneer u veel velden voor dit object tegelijk moet openen. Nadelen :langzamer wanneer u slechts een enkel veld hoeft te openen.

2. Sla de eigenschappen van elk object op in een Redis-hash.

   INCR id:users
   HMSET user:{id} name "Fred" age 25
   SADD users {id}
   

   Voordelen :beschouwd als een "goede praktijk". Elk object is een volwaardige Redis-sleutel. Het is niet nodig om JSON-tekenreeksen te ontleden. Nadelen :mogelijk langzamer wanneer u toegang moet hebben tot alle/de meeste velden in een object. Ook kunnen geneste objecten (objecten binnen objecten) niet gemakkelijk worden opgeslagen.

3. Bewaar elk object als een JSON-tekenreeks in een Redis-hash.

   INCR id:users
   HMSET users {id} '{"name":"Fred","age":25}'
   

   Hierdoor kunt u een beetje consolideren en slechts twee sleutels gebruiken in plaats van veel sleutels. Het voor de hand liggende nadeel is dat je de TTL (en andere dingen) niet voor elk gebruikersobject kunt instellen, omdat het slechts een veld in de Redis-hash is en geen volledige Redis-sleutel.

   Voordelen :JSON-parsering is snel, vooral wanneer u veel velden voor dit object tegelijk moet openen. Minder "vervuilend" van de hoofdsleutelnaamruimte. Nadelen :Ongeveer hetzelfde geheugengebruik als #1 als je veel objecten hebt. Langzamer dan #2 wanneer u slechts een enkel veld hoeft te openen. Waarschijnlijk niet beschouwd als een 'goede praktijk'.

4. Sla elke eigenschap van elk object op in een speciale sleutel.

   INCR id:users
   SET user:{id}:name "Fred"
   SET user:{id}:age 25
   SADD users {id}
   

   Volgens het bovenstaande artikel is deze optie bijna nooit voorkeur (tenzij de eigenschap van het object een specifieke TTL of iets dergelijks moet hebben).

   Voordelen :Objecteigenschappen zijn volledige Redis-sleutels, die misschien niet overdreven zijn voor uw app. Nadelen :traag, gebruikt meer geheugen en wordt niet beschouwd als 'best practice'. Veel vervuiling van de hoofdsleutelnaamruimte.

Algemene samenvatting

Optie 4 heeft over het algemeen niet de voorkeur. Optie 1 en 2 lijken erg op elkaar, en ze komen beide vrij vaak voor. Ik geef de voorkeur aan optie 1 (in het algemeen) omdat je hiermee meer gecompliceerde objecten kunt opslaan (met meerdere lagen nesting, enz.) Optie 3 wordt gebruikt wanneer het je echt iets uitmaakt over het niet vervuilen van de hoofdsleutelnaamruimte (d.w.z. u wilt niet dat er veel sleutels in uw database zijn en u geeft niet om zaken als TTL, key sharding of wat dan ook).

Als ik hier iets fout heb gedaan, overweeg dan om een ​​reactie achter te laten en mij de kans te geven het antwoord te herzien voordat ik naar beneden stem. Bedankt! :)