Strings Redis vs hashes Redis para representar JSON:eficiência?

1. 
   Armazene o objeto inteiro como string codificada em JSON em uma única chave e acompanhe todos os objetos usando um conjunto (ou lista, se mais apropriado). Por exemplo:
   

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

   
   De um modo geral, este é provavelmente o melhor método na maioria dos casos. Se houver muitos campos no objeto, seus objetos não estão aninhados com outros objetos e você tende a acessar apenas um pequeno subconjunto de campos por vez, talvez seja melhor usar a opção 2.
   
   Vantagens :considerado uma "boa prática". Cada objeto é uma chave Redis completa. A análise de JSON é rápida, especialmente quando você precisa acessar vários campos para este objeto de uma só vez. Desvantagens :mais lento quando você só precisa acessar um único campo.
   
2. 
   Armazene as propriedades de cada objeto em um hash Redis.
   

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

   
   Vantagens :considerado uma "boa prática". Cada objeto é uma chave Redis completa. Não há necessidade de analisar strings JSON. Desvantagens :possivelmente mais lento quando você precisa acessar todos/a maioria dos campos em um objeto. Além disso, objetos aninhados (objetos dentro de objetos) não podem ser armazenados facilmente.
   
3. 
   Armazene cada objeto como uma string JSON em um hash Redis.
   

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

   
   Isso permite que você consolide um pouco e use apenas duas chaves em vez de muitas chaves. A desvantagem óbvia é que você não pode definir o TTL (e outras coisas) em cada objeto de usuário, pois é apenas um campo no hash Redis e não uma chave Redis completa.
   
   Vantagens :A análise de JSON é rápida, especialmente quando você precisa acessar vários campos para este objeto de uma só vez. Menos "poluente" do namespace da chave principal. Desvantagens :Sobre o mesmo uso de memória que #1 quando você tem muitos objetos. Mais lento que #2 quando você só precisa acessar um único campo. Provavelmente não é considerada uma "boa prática".
   
4. 
   Armazene cada propriedade de cada Objeto em uma chave dedicada.
   

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

   
   De acordo com o artigo acima, esta opção é quase nunca preferencial (a menos que a propriedade do Objeto precise ter TTL específico ou algo assim).
   
   Vantagens :as propriedades do objeto são chaves Redis completas, o que pode não ser um exagero para seu aplicativo. Desvantagens :lento, usa mais memória e não é considerado "prática recomendada". Muita poluição do namespace da chave principal.
   

Resumo geral