Redis низове срещу Redis хешове за представяне на JSON:ефективност?

Тази статия може да предостави много информация тук:http://redis.io/topics/memory-optimization

Има много начини за съхраняване на масив от обекти в Redis (спойлер :Харесвам вариант 1 за повечето случаи на употреба):

1. Съхранявайте целия обект като JSON-кодиран низ в един ключ и следете всички обекти, като използвате набор (или списък, ако е по-подходящо). Например:

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

   Най-общо казано, това е може би най-добрият метод в повечето случаи. Ако има много полета в обекта, вашите обекти не са вложени с други обекти и сте склонни да осъществявате достъп само до малка част от полета наведнъж, може би е по-добре да използвате опция 2.

   Предимства :счита се за „добра практика“. Всеки обект е пълноценен Redis ключ. Разборът на JSON е бърз, особено когато трябва да получите достъп до много полета за този обект наведнъж. Недостатъци :по-бавно, когато имате нужда от достъп само до едно поле.

2. Съхранявайте свойствата на всеки обект в хеш на Redis.

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

   Предимства :счита се за „добра практика“. Всеки обект е пълноценен Redis ключ. Няма нужда да анализирате JSON низове. Недостатъци :вероятно по-бавно, когато трябва да получите достъп до всички/повечето полета в обект. Също така, вложените обекти (обекти в обекти) не могат да се съхраняват лесно.

3. Съхранявайте всеки обект като JSON низ в хеш на Redis.

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

   Това ви позволява да консолидирате малко и да използвате само два ключа вместо много ключове. Очевидният недостатък е, че не можете да зададете TTL (и други неща) на всеки потребителски обект, тъй като това е просто поле в хеша на Redis, а не пълноценен Redis ключ.

   Предимства :Разборът на JSON е бърз, особено когато трябва да получите достъп до много полета за този обект наведнъж. По-малко „замърсяване“ на пространството от имена на главния ключ. Недостатъци :Приблизително същото използване на паметта като № 1, когато имате много обекти. По-бавно от #2, когато трябва да имате достъп само до едно поле. Вероятно не се счита за „добра практика“.

4. Съхранявайте всяко свойство на всеки обект в специален ключ.

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

   Според статията по-горе тази опция почти никога не е предпочитан (освен ако свойството на обекта трябва да има специфичен TTL или нещо подобно).

   Предимства :Свойствата на обекта са пълноценни Redis ключове, което може да не е излишно за вашето приложение. Недостатъци :бавен, използва повече памет и не се счита за „най-добра практика“. Много замърсяване на пространството от имена на главния ключ.

Общо обобщение

Вариант 4 обикновено не се предпочита. Опции 1 и 2 са много сходни и и двете са доста често срещани. Предпочитам вариант 1 (най-общо казано), защото ви позволява да съхранявате по-сложни обекти (с множество слоеве на влагане и т.н.). Опция 3 се използва, когато наистина ви е грижа за това да не замърсявате пространството от имена на главния ключ (т.е. не искате да има много ключове във вашата база данни и не ви интересуват неща като TTL, разделяне на ключове или каквото и да било).

Ако имам нещо нередно тук, моля, помислете да оставите коментар и да ми позволите да преразгледам отговора, преди да откажа. Благодаря! :)