Todo depende de cómo lo vayas a utilizar. Si cada byte cuenta, por ejemplo cuando tienes que pagar por cada kB transferido a un servicio en la nube, puedes calcular los costes. Las matemáticas son simples; un byte es un byte 'en el cable'. Dentro de redis, para valores más grandes es igualmente simple. Para valores más pequeños, Redis optimiza la memoria.
En su HSET Por ejemplo, separa a los miembros, lo que solo tiene sentido si los necesita separados la mayor parte del tiempo. Un mejor enfoque -podría- ser:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Las claves/miembros separados 'cuestan' mucho más que las cadenas más largas, en cuanto al rendimiento. Incluso puede poner una tabla completa o un conjunto de datos en un miembro si solo se va a usar como una entidad semiestática completa.
Velocidad y tamaño:hay una diferencia notable entre las teclas y valores .
Teclas: Más corto es generalmente más eficiente en memoria y velocidad. Si usa un conjunto ordenado redis, puede incluso usar 'números' como claves (conjunto ordenado 'miembros' más 'puntuaciones'). Digo 'números' porque un puntaje es técnicamente un float64, pero para ser usado como ID tiene que estar entre -999999999999999 y 999999999999999 incluidos (eso es 15 dígitos), sin ninguna parte fraccionaria. Esto puede ser realmente útil, ya que Redis realiza una clasificación O(log(n)) rápida y escalable sobre la marcha de conjuntos ordenados (usando listas de exclusión, simplificado).
Valores: El formato MsgPack (sin comprimir) ocupa menos espacio, especialmente si almacena las definiciones una vez y los valores muchos. JSON es un poco menos eficiente en términos de memoria, pero, por supuesto, es un formato IPC tan común que no debe dejarse de lado. Cadenas sin procesar, caracteres separados, longitud fija (ugh), cualquiera que sea su deseo, es posible usar. Siempre puede comprimir sus datos antes de almacenarlos en Redis. Hasta ahora eficiencia de la memoria . Cuando se trata de velocidad , es menos simple. Si desea utilizar secuencias de comandos del lado del servidor de Lua (que debería hacerlo), no puede hacer nada con los datos comprimidos. JSON y MsgPack se pueden deserializar, pero solo 'como un todo'. Lo cual está bien en la mayoría de los escenarios. Lo más flexible es almacenar valores separados (por ejemplo, como miembros de un HSET), pero esto también tiene un precio (la mayoría de las veces:un precio demasiado alto). También puedes combinar todo esto. Lo que más usamos:un prefijo de dos o tres valores separados por delimitadores, seguido de una carga útil de MsgPack.
Mi consejo general es:comience usando solo HSET y ZSET, no divida los datos que deben estar juntos, use nombres descriptivos de PascalCased para sus claves entre 10-25 caracteres, use ':' si necesita delimitadores en sus claves (espacios de nombres) , serialice como JSON (para simplificar, pero codifique para cambiar fácilmente a MsgPack), use secuencias de comandos Lua (incluso si no conoce Lua, el subconjunto que usa en Redis es pequeño).
No me preocuparía demasiado por eso en la fase de inicio de su proyecto, siempre puede cambiarlo más adelante y hacer algunas comparaciones A/B tan pronto como tenga algunos datos interpolables.
Espero que esto ayude, TW
