Redis o Memcached: más funciones pueden perder frente a más hilos

Redis conviene cuando la aplicación necesita operar sobre estructuras de datos, conservar información o mantener réplicas: la descripción oficial de Redis documenta esas capacidades. Si las entradas son valores reconstruibles y predominan GET y SET, Memcached merece una prueba en la misma carga. Las funciones adicionales no aseguran más caudal ni menor latencia para una caché simple.

La posibilidad de que Memcached rinda mejor tiene respaldo, aunque depende de las condiciones. Un estudio de la Universidad de Waterloo con Redis 3.2.5 y Memcached 1.4.13 encontró mayor caudal de Memcached en una carga de lectura intensiva en clúster y relacionó ese resultado con su ejecución multihilo. Es un resultado de aquellas versiones y aquella carga; para elegir hoy también importa que el caudal se sostenga dentro del límite de latencia P99 de la aplicación.

Qué compra cada modelo de datos

Memcached guarda valores asociados a claves. Encaja bien cuando la aplicación produce un valor completo, lo recupera y puede volver a calcularlo si falta. Una respuesta serializada, por ejemplo, puede tratarse como una sola entrada: el servidor no necesita conocer los campos que contiene.

Redis permite que el servidor trabaje directamente con hashes, listas, conjuntos y conjuntos ordenados. Si varios clientes deben modificar campos o miembros concretos, esas operaciones pueden evitar la secuencia de leer un objeto entero, cambiarlo en la aplicación y escribirlo de nuevo. También permiten expresar ciertas operaciones sobre los datos sin trasladar toda su coordinación al cliente. Esa diferencia funcional solo aporta valor cuando la carga realmente utiliza las estructuras.

La pregunta útil es dónde se realizará el trabajo. Reemplazar de vez en cuando un valor completo favorece el modelo sencillo de Memcached. Actualizar con frecuencia partes de una colección hace más interesante Redis, porque la serialización y la coordinación en la aplicación también consumen tiempo. Una prueba limitada a GET y SET de cadenas mide la caché simple; no asigna valor a operaciones sobre estructuras que esa prueba nunca ejecuta.

Persistencia y replicación cambian el coste de perder la caché

Redis puede guardar instantáneas o un registro de escrituras y mantener réplicas. La persistencia es opcional: su configuración determina cuánto estado puede recuperarse y qué trabajo adicional realiza el sistema. La replicación facilita disponer de otra copia, pero es asíncrona; no debe confundirse con la garantía de que cada escritura sobrevivirá a cualquier fallo.

Memcached parte de una expectativa distinta: las entradas se pueden reconstruir desde el sistema de origen. Hay un matiz relevante: la función de reinicio en caliente de Memcached puede recuperar la caché tras una parada ordenada, pero no la hace segura ante un fallo abrupto. Tampoco sustituye la replicación integrada que puede necesitar una aplicación que dependa de conservar el estado.

Cuando una caché se vacía, el efecto no termina en el servidor de memoria. Las solicitudes que antes encontraban una entrada vuelven a la base de datos o al servicio que genera el valor. Por eso el tiempo de recarga y la capacidad del origen forman parte de la elección: aceptar la pérdida de las entradas puede ser razonable para una caché pequeña y barata de reconstruir, pero costoso si su recarga concentra muchas consultas.

Cuándo pueden pesar más los hilos

Memcached reparte trabajo entre hilos, mientras que la ejecución de comandos de una instancia de Redis ocurre principalmente en un hilo. Esto le da a Memcached una oportunidad de aprovechar varios núcleos cuando llegan suficientes peticiones independientes. Redis también utiliza hilos para determinadas tareas; además, varias instancias pueden distribuir el procesamiento de comandos entre núcleos, con la correspondiente distribución de claves y capacidad.

La ventaja potencial aparece con concurrencia suficiente para ocupar esos recursos. Si llegan pocas solicitudes, añadir hilos puede no cambiar la respuesta percibida. Si aumenta el tráfico, el caudal puede crecer hasta que otro componente limite la prueba: el generador, la red, la memoria o la contención interna. Incluso una configuración que complete más operaciones por segundo deja de ser preferible si sus solicitudes más lentas superan el P99 exigido.

También importa qué se llama «la misma carga». Cambiar el tamaño de los valores modifica los bytes transferidos; cambiar la proporción de lecturas y escrituras altera el trabajo del servidor. Una tasa de aciertos distinta traslada una cantidad diferente de solicitudes al sistema de origen. Comparar dos cifras de caudal sin fijar esas condiciones puede atribuir al motor una diferencia que procede del escenario.

Qué permite concluir un ensayo publicado

Un ensayo presentado en Linux Plumbers Conference usó Redis 7.2.0 y Memcached 1.6.21, precargó los datos hasta obtener un 95 % de aciertos, fijó una proporción de un SET por diez GET y un valor medio de 64 bytes, y exigió un P99 inferior a 1 ms. Cada ejecución duró dos minutos y los autores tomaron la mediana de cinco; los clientes corrían en máquinas separadas.

Ese ensayo estudiaba configuraciones de memoria y asignó una CPU dedicada a cada instancia, aunque describía Redis como monohilo y Memcached como multihilo. Por tanto, no mide cuánto gana Memcached al disponer de varios núcleos para una sola instancia. Además, dejó fuera la persistencia y la replicación de Redis. Su utilidad para esta elección está en hacer explícitos la tasa de aciertos, la mezcla de operaciones, los valores, la concurrencia y el umbral de latencia que definen cualquier resultado.

Una comparación reproducible con memtier_benchmark

El manual de memtier_benchmark documenta los protocolos de Redis y Memcached y los parámetros para fijar hilos y clientes del generador, proporción SET:GET, tamaño de valores, distribución de claves, duración y repeticiones. Los hilos de esa herramienta generan tráfico; no son los hilos del servidor que se está evaluando.

1. Define primero una carga de GET y SET que represente la aplicación. Reserva la misma memoria para ambos motores, usa el mismo espacio y distribución de claves y precarga los valores. Comprueba los aciertos observados durante la medición: la proporción de GET, por sí sola, no dice cuántos encuentran una entrada.
2. Ejecuta el generador desde otra máquina y registra las versiones, la configuración de red y las opciones del servidor. Como ejemplo condicional, una serie puede usar --ratio=1:10, --data-size=256, --key-maximum=100000, --key-pattern=R:R, --pipeline=1, --test-time=120 y --run-count=5. Cambia --protocol=redis por --protocol=memcache_text al pasar al otro motor, junto con su host y puerto. Estos valores ilustran un diseño de prueba; no reproducen el ensayo publicado.
3. Repite la serie con distintos valores de --threads y --clients, manteniendo iguales los parámetros de carga. Registra por separado cada combinación y verifica que el generador y la red conservan margen. Si la aplicación agrupa peticiones, mide también una profundidad de pipeline representativa; una profundidad elegida solo para elevar el caudal no describe necesariamente su comportamiento.
4. Compara el caudal únicamente entre series que cumplen el P99 requerido y revisa las latencias de GET y SET, los aciertos y el uso de CPU. Si Redis se desplegará con persistencia o réplicas, mide esa configuración aparte. La decisión favorece a Memcached si la caché simple cumple mejor el objetivo; favorece a Redis cuando sus operaciones sobre estructuras o sus opciones de conservación resuelven una necesidad que GET y SET no cubren.

Lee también:

• Cloudera lleva la IA hasta los datos que no pueden ir a la nube
• Gridsight capta 26 millones: conectar más carga sin ampliar la red
• Patreon estrena 30 funciones: descubrir talento ya no favorecerá solo a grandes