caching - humano - batería iphone 6s

Si redis ya es parte de la pila, ¿por qué Memcached todavía se usa junto con Redis? (2)

La razón principal que veo hoy en día como un caso de uso para Memcached sobre Redis es la superior eficiencia de memoria que debería poder obtener con el almacenamiento en caché de fragmentos de HTML simple (o aplicaciones similares). Si necesita almacenar diferentes campos de sus objetos en diferentes claves guardadas, entonces los hashes de Redis serán más eficientes en cuanto a la memoria, pero cuando tiene una gran cantidad de pares clave -> simple_string, memcached debería poder darle más elementos por megabyte.

Otras cosas que son buenos puntos sobre memcached:

Es un código muy simple, así que si solo necesitas la funcionalidad que proporciona, supongo que es una alternativa razonable, pero nunca la utilicé en producción.
Tiene múltiples subprocesos, por lo que si necesita escalar en una configuración de caja única, es algo bueno y debe hablar con una sola instancia.

Creo que Redis como memoria caché tiene cada vez más sentido a medida que las personas avanzan hacia el almacenamiento en caché inteligente o cuando intentan preservar la estructura de los datos en caché a través de las estructuras de datos de Redis.

Comparación entre Redis LRU y memcached LRU.

Tanto Memcached como Redis no realizan desalojos LRU reales, sino solo una aproximación de eso.

El desalojo de Memcache es por clase de tamaño y depende de los detalles de implementación de su asignador de planchón. Por ejemplo, si desea agregar un elemento que se ajuste a una clase de tamaño determinada, Memcached intentará eliminar los elementos caducados / que no se usaron recientemente en esa clase, en lugar de intentar un intento global de comprender qué es el objeto, independientemente de su tamaño, que es el mejor candidato.

En cambio, Redis intenta elegir un buen objeto como candidato para el desalojo cuando se maxmemory límite maxmemory la maxmemory , observando todos los objetos, independientemente de la clase de tamaño, pero solo puede proporcionar un objeto aproximadamente bueno, no el mejor objeto con el mayor tiempo de inactividad.

La forma en que Redis hace esto es muestreando algunos objetos, seleccionando el que estaba inactivo (no se accede) durante más tiempo. Desde Redis 3.0 (actualmente en beta), el algoritmo se mejoró y también tiene un buen conjunto de candidatos en todos los desalojos, por lo que se mejoró la aproximación. En la documentación de Redis puede encontrar una descripción y gráficos con detalles sobre cómo funciona .

¿Por qué Memcached tiene una huella de memoria mejor que Redis para cadenas simples -> mapas de cadenas.

Redis es una pieza de software más compleja, por lo que los valores en Redis se almacenan de forma más similar a los objetos en un lenguaje de programación de alto nivel: tienen un tipo asociado, codificación, recuento de referencias para la gestión de la memoria. Esto hace que la estructura interna de Redis sea buena y manejable, pero tiene una sobrecarga en comparación con memcached, que solo trata con cadenas.

Cuando Redis comienza a ser más eficiente con la memoria

Redis puede almacenar pequeños tipos de datos agregados de una forma especial para guardar la memoria. Por ejemplo, un pequeño Redis Hash que representa un objeto, se almacena internamente no con una tabla hash, sino como un blob exclusivo binario. Entonces, establecer múltiples campos por objeto en un hash es más eficiente que almacenar N claves separadas en memcached.

En realidad, puede almacenar un objeto en memcached como un blob JSON único (o codificado en binario), pero a diferencia de Redis, esto no le permitirá recuperar ni actualizar campos independientes.

La ventaja de Redis en el contexto del almacenamiento en caché inteligente.

Debido a las estructuras de datos de Redis, el patrón habitual utilizado con memcached para destruir objetos cuando se invalida la memoria caché, para volver a crearlo a partir del DB más tarde, es una forma primitiva de utilizar Redis.

Por ejemplo, imagine que necesita almacenar en caché las últimas noticias de N publicadas en Hacker News para completar la sección "Más reciente" del sitio. Lo que usted hace con Redis es tomar una lista (con un límite de M elementos) con las noticias más recientes insertadas. Si utiliza otra tienda para sus datos, y Redis como caché, lo que debe hacer es completar ambas vistas (Redis y la base de datos) cuando se publica un nuevo elemento. No hay invalidación de caché.

Sin embargo, la aplicación siempre puede tener lógica, de modo que si se encuentra que la lista de Redis está vacía, por ejemplo después de un inicio, la vista inicial puede recrearse desde el DB.

Al utilizar el almacenamiento en caché inteligente, es posible realizar el almacenamiento en caché con Redis de una manera más eficiente en comparación con los dispositivos de memoria caché, pero no todos los problemas son adecuados para este patrón. Por ejemplo, el almacenamiento en caché de fragmentos HTML puede no beneficiarse de esta técnica.

Redis puede hacer todo lo que proporciona Memcached (caché LRU, caducidad del elemento y ahora clúster en la versión 3.x +, actualmente en beta) o por herramientas como twemproxy. El rendimiento es similar también. Además, Redis agrega persistencia debido a lo cual no es necesario hacer el calentamiento del caché en caso de un reinicio del servidor.

Referencia a algunas respuestas antiguas que comparan Redis y Memcache, algunas de las cuales favorecen a Redis como reemplazo de Memcache (si ya está presente en la pila):

A pesar de esto, al estudiar montones de grandes compañías de escala web como Instagram, Pinterest, Twitter, etc., descubrí que usan Memcached y Redis para diferentes propósitos, sin utilizar Redis para el almacenamiento en caché primario. La memoria caché principal sigue siendo Memcached, y Redis se utiliza para sus estructuras de datos basadas en el almacenamiento en caché lógico.

A partir de 2014, ¿por qué todavía se merece que se agregue el dolor como componente adicional en tu pila, cuando ya tienes un componente de Redis que puede hacer todo lo que se puede hacer con memcached? ¿Cuáles son los puntos favorables que inclinan a los arquitectos / ingenieros a incluir aún memcached aparte de Redis ya existente?

Actualización:

Para nuestras plataformas, hemos descartado Memcached por completo y usamos redis para requisitos de almacenamiento en caché tanto lógicos como simples. Altamente eficiente, flexible y confiable.

Algunos ejemplos de escenarios:

Enumerar todas las claves en caché por un patrón específico, y leer o eliminar sus valores. Muy fácil en redis, no factible (fácilmente) en memcached.
Almacenar una carga útil de más de 1mb, fácil de hacer en redis, requiere ajustes de tamaño de losa en memcached, que tiene efectos secundarios propios del rendimiento.
Instantáneas fáciles del contenido actual de la memoria caché
El clúster de Redis también está listo para la producción junto con los controladores de idioma, por lo que la implementación en clúster también es fácil.

Los hábitos son difíciles de romper :)

En serio, hay dos razones principales, a mi entender, por las cuales Memcached todavía se usa:

Legacy: hay desarrolladores que están cómodos y familiarizados con Memcached, así como también aplicaciones que lo soportan. Esto también significa que es una tecnología madura y bien probada.
Escalado: Memcached estándar es fácilmente escalable horizontalmente, mientras que Redis (hasta y excluyendo el v3 que pronto se lanzará) requiere más trabajo para ese fin (es decir, fragmentación).

Sin embargo:

Re. legado: dada la robustez de Redis (estructuras de datos, comandos, persistencia ...), se desarrolla activamente y los clientes en cualquier lenguaje concebible, con él se desarrollan nuevas aplicaciones.
Re escalado: además de la próxima v3, hay soluciones que pueden hacer que la escalación sea mucho más fácil. Por ejemplo, Redis Cloud ofrece escalas sin interrupciones sin pérdida de datos o interrupción del servicio. Otro enfoque popular para escalar / fragmentar Redis es twemproxy .