Tudo depende de como você vai usá-lo. Se cada byte conta, por exemplo, quando você tem que pagar por cada kB transferido para um serviço em nuvem, você pode calcular os custos. A matemática é simples; um byte é um byte 'no fio'. Dentro do redis, para valores maiores é igualmente simples. Para valores menores, o Redis faz alguma otimização de memória.

Em seu HSET Por exemplo, você divide os membros, o que só faz sentido se você precisar deles separados na maioria das vezes. Uma abordagem melhor -pode- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Chaves/membros separados 'custam' muito mais do que strings mais longas, em termos de desempenho. Você pode até mesmo colocar uma tabela ou conjunto de dados inteiro em um membro se for usado apenas como uma entidade semi-estática completa.

Velocidade e tamanho:há uma diferença notável entre as chaves e valores .

Chaves: Mais curto geralmente é mais eficiente em termos de memória e de velocidade. Se você usar um Redis Sorted Set, você pode até usar 'números' como chaves (conjunto ordenado 'membros' mais 'pontuações'). Eu digo 'números' porque uma pontuação é tecnicamente um float64, mas para ser usado como um ID tem que estar entre -999999999999999 e 999999999999999 incluindo (isso é 15 dígitos), sem qualquer parte fracionária. Isso pode ser muito útil, já que o Redis faz uma classificação O(log(n)) rápida e escalável de conjuntos ordenados (usando skiplists, simplificado).

Valores: O formato MsgPack (descompactado) ocupa menos espaço, especialmente se você armazenar as definições uma vez e os valores muitos. JSON é um pouco menos eficiente em termos de memória, mas é claro que é um formato IPC tão comum que não deve ser deixado de fora. Strings brutas, separadas por caracteres, comprimento fixo (ugh), qualquer que seja o seu desejo, é possível usar. Você sempre pode compactar seus dados antes de armazená-los no Redis. Até agora, eficiência de memória . Quando se trata de velocidade , é menos simples. Se você quiser usar scripts do lado do servidor Lua (o que você deve fazer), você não pode fazer nada com dados compactados. JSON e MsgPack podem ser desserializados, mas apenas 'como um todo'. O que é bom na maioria dos cenários. Mais flexível é armazenar valores separados (por exemplo, como membros de um HSET), mas isso também tem um preço (na maioria das vezes:um preço muito alto). Você também pode combinar tudo isso. O que mais usamos:um prefixo de dois ou três valores separados por delimitadores, seguidos por um payload MsgPack.

Meu conselho geral é:comece usando apenas HSETs e ZSETs, não divida os dados que pertencem juntos, use nomes PascalCased descritivos para suas chaves entre 10-25 caracteres, use ':' se você precisar de delimitadores em suas chaves (namespaces) , serialize como JSON (para simplificar, mas codifique para facilitar a troca para MsgPack), use scripts Lua (mesmo que você não conheça Lua, o subconjunto que você usa no Redis é minúsculo).

Eu não me preocuparia muito com isso na fase de inicialização do seu projeto, você sempre pode alterá-lo mais tarde e fazer algumas comparações A/B assim que tiver alguns dados interpoláveis.

Espero ter ajudado, tw