Valkey, la base de datos en memoria, abstrae la representación real de los datos en RAM mediante codificaciones automáticas que elige según el tamaño y la cantidad de elementos. Cada tipo de dato (hashes, listas, conjuntos, conjuntos ordenados y streams) puede almacenarse con estructuras más o menos compactas, y la transición entre ellas depende de umbrales de configuración como hash-max-listpack-entries, hash-max-listpack-value, list-max-listpack-size, set-max-intset-entries, set-max-listpack-entries, set-max-listpack-value, zset-max-listpack-entries y zset-max-listpack-value.
Un valor de hash de 64 bytes se codifica como listpack y consume 120 bytes por clave, pero al pasar a 65 bytes el sistema salta a una tabla hash que eleva el consumo a 212 bytes, un 76,67% más. El comando OBJECT ENCODING permite inspeccionar la codificación activa y MEMORY USAGE mide el consumo real de cada clave. Los streams y los módulos de Valkey no dependen de estos umbrales configurables.
Revisar los valores por defecto merece la pena cuando se busca reducir coste o exprimir la infraestructura. Ajustar hash-max-listpack-value al tamaño real de los datos puede permitir mantener la codificación compacta en un porcentaje mucho mayor de claves. Los autores ilustran el potencial con dos escenarios: un caso extremo en el que el 95% de las claves superan el umbral permite pasar de un clúster de 100 GB repartido en 5 nodos primarios de 20 GB a uno de 58,8 GB en 3 primarios, eliminando dos nodos primarios y sus réplicas; en un escenario más realista con el 60% de las claves por encima del umbral, se mantendrían los 5 nodos pero cada uno bajaría de 20 GB a 14,8 GB, con la posibilidad de contratar máquinas de 16 GB de RAM. El ahorro final depende de los saltos de precio por especificaciones en cloud o en entornos on-premises.