Memcached vs Redis?


Estamos usando una aplicación web Ruby con Redis servidor para el almacenamiento en caché. Hay un punto para probar Memcached en su lugar?

¿Qué nos dará un mejor rendimiento? ¿Algún pros o contras entre Redis y Memcached?

Puntos a considerar:

  • Velocidad de lectura / escritura.
  • Uso de memoria.
  • Descarga de E/S de disco.
  • Escalado.
Author: Zeeshan Ali, 2012-05-12

17 answers

Resumen (TL; DR)

Actualizado el 3 de junio, 2017

Redis es más potente, más popular y mejor soportado que memcached. Memcached solo puede hacer una pequeña fracción de las cosas que Redis puede hacer. Redis es mejor incluso donde sus características se superponen.

Para cualquier cosa nueva, utilice Redis.

Memcached vs Redis: Comparación directa

Ambas herramientas son almacenes de datos potentes, rápidos y en memoria que son útiles como caché. Ambos pueden ayudar a acelerar su aplicación al almacenamiento en caché de resultados de bases de datos, fragmentos HTML o cualquier otra cosa que pueda ser costosa de generar.

Puntos a considerar

Cuando se usa para lo mismo, aquí es cómo se comparan usando los "Puntos a considerar"de la pregunta original:

  • Velocidad de lectura/escritura : Ambas son extremadamente rápidas. Los puntos de referencia varían según la carga de trabajo, las versiones y muchos otros factores, pero generalmente muestran que redis es tan rápido o casi tan rápido como memcached. Recomiendo redis, pero no porque memcached es lento. No lo es.
  • Uso de memoria: Redis es mejor.
    • memcached: Se especifica el tamaño de la caché y a medida que se insertan elementos el demonio crece rápidamente a un poco más de este tamaño. Nunca hay realmente una manera de recuperar nada de ese espacio, sin reiniciar memcached. Todas sus claves podrían estar caducadas, podría vaciar la base de datos, y todavía usaría la porción completa de RAM con la que la configuró.
    • redis: Establecer un tamaño máximo depende de usted. Redis nunca use más de lo necesario y le devolverá la memoria que ya no usa.
    • Almacené 100,000 ~cadenas de 2 KB (~200 MB) de oraciones aleatorias en ambas. El uso de Memcached RAM creció a ~225MB. El uso de RAM de Redis creció a ~228MB. Después de lavar ambos, redis cayó a ~29MB y memcached se quedó en ~225MB. Son igualmente eficientes en la forma en que almacenan datos, pero solo uno es capaz de recuperarlos.
  • Disk I/O dumping : Una clara victoria para redis ya que hace esto por por defecto y tiene persistencia muy configurable. Memcached no tiene mecanismos para descargar al disco sin herramientas de terceros.
  • Escalado: Ambos le dan toneladas de espacio libre antes de que necesite más de una sola instancia como caché. Redis incluye herramientas para ayudarle a ir más allá de eso, mientras que memcached no lo hace.

Memcached

Memcached es un simple servidor de caché volátil. Le permite almacenar pares clave / valor donde el valor se limita a ser una cadena hasta 1MB.

Es bueno en esto, pero eso es todo lo que hace. Puede acceder a esos valores por su clave a una velocidad extremadamente alta, a menudo saturando la red disponible o incluso el ancho de banda de la memoria.

Cuando reinicie memcached, sus datos desaparecerán. Esto está bien para un escondite. No deberías guardar nada importante allí.

Si necesita alto rendimiento o alta disponibilidad, hay herramientas, productos y servicios de terceros disponibles.

Redis

Redis puede hacer los mismos trabajos que memcached puede, y puede hacerlo mejor.

Redis puede actuar como un cache también. También puede almacenar pares clave / valor. En redis pueden llegar a ser de hasta 512MB.

Puede desactivar la persistencia y felizmente perderá sus datos al reiniciar también. Si quieres que tu caché sobreviva a los reinicios, también te permite hacerlo. De hecho, ese es el valor predeterminado.

También es súper rápido, a menudo limitado por el ancho de banda de la red o la memoria.

Si una instancia de redis / memcached no es suficiente rendimiento para su carga de trabajo, redis es la elección clara. Redis incluye soporte de clúster y viene con herramientas de alta disponibilidad ( redis-sentinel) justo "en la caja". En los últimos años, redis también se ha convertido en el claro líder en herramientas de terceros. Empresas como Redis Labs, Amazon y otras ofrecen muchas herramientas y servicios útiles de redis. El ecosistema alrededor de redis es mucho más grande. El número de implementaciones a gran escala ahora es probablemente mayor que para memcached.

El Superconjunto Redis

Redis es más que una caché. Es un servidor de estructura de datos en memoria. A continuación encontrará un resumen rápido de las cosas que Redis puede hacer más allá de ser una simple caché de clave/valor como memcached. La mayoría de de las características de redis son cosas que memcached no puede hacer.

Documentación

Redis está mejor documentado que memcached. Si bien esto puede ser subjetivo, parece ser más y más cierto todo el tiempo.

Redis.io es un fantástico recurso fácilmente navegable. Le permite probar redis en el navegador e incluso le da ejemplos interactivos en vivo con cada comando en los documentos.

Ahora hay 2 veces más resultados de stackoverflow para redis que memcached. 2 veces más resultados de Google. Ejemplos más fácilmente accesibles en más idiomas. Desarrollo más activo. Desarrollo de clientes más activo. Estas medidas pueden no significar mucho individualmente, pero en combinación pintan una imagen clara que apoya y documentación para redis es mayor y mucho más actualizada.

Persistencia

De forma predeterminada, redis conserva los datos en el disco mediante un mecanismo llamado snapshotting. Si tiene suficiente RAM disponible, es capaz de escribir todos sus datos en el disco sin casi ninguna degradación del rendimiento. Es casi gratis!

En el modo de instantánea existe la posibilidad de que un accidente repentino podría resultar en una pequeña cantidad de datos perdidos. Si es absolutamente necesario asegurarse de que no se pierda ningún dato, no se preocupe, redis también tiene su respaldo con el modo AOF (Anexar solo archivo). En este modo de persistencia, los datos se pueden sincronizar con el disco a medida que se escriben. Esto puede reducir el rendimiento máximo de escritura a cualquier velocidad que su disco pueda escribir, pero aún así debería ser bastante rápido.

Hay muchas opciones de configuración para ajustar la persistencia si es necesario, pero los valores predeterminados son muy sensibles. Estas opciones facilitan la configuración de redis como un lugar seguro y redundante para almacenar datos. Es un real base.

Muchos Tipos de Datos

Memcached está limitado a cadenas, pero Redis es un servidor de estructura de datos que puede servir muchos tipos de datos diferentes. También proporciona los comandos que necesita para aprovechar al máximo esos tipos de datos.

Cadenas (comandos)

Valores simples de texto o binarios que pueden ser de hasta 512 MB de tamaño. Este es el único tipo de datos compartido redis y memcached, aunque las cadenas memcached están limitadas a 1 MB.

Redis te da más herramientas para aprovechar este tipo de datos ofreciendo comandos para operaciones bitwise, manipulación de nivel de bits, soporte de incremento/decremento de punto flotante, consultas de rango y operaciones de múltiples claves. Memcached no admite nada de eso.

Las cadenas son útiles para todo tipo de casos de uso, por lo que memcached es bastante útil solo con este tipo de datos.

Hashes (comandos)

Los hashes son como un almacén de valores de clave dentro de un almacén de valores de clave. Mapean entre cadena campos y valores de cadena. Los mapas de campo - >valor que usan un hash son un poco más eficientes en espacio que los mapas de clave->valor que usan cadenas regulares.

Los hashes son útiles como espacio de nombres, o cuando se desea agrupar lógicamente muchas claves. Con un hash puedes agarrar todos los miembros de manera eficiente, caducar todos los miembros juntos, eliminar todos los miembros juntos, etc. Ideal para cualquier caso de uso donde tenga varios pares clave/valor que necesiten agruparse.

Un ejemplo de uso de un hash es para almacenar el usuario perfiles entre aplicaciones. Un hash de redis almacenado con el ID de usuario como clave le permitirá almacenar tantos bits de datos sobre un usuario como sea necesario mientras los mantiene almacenados bajo una sola clave. La ventaja de usar un hash en lugar de serializar el perfil en una cadena es que puede hacer que diferentes aplicaciones lean / escriban diferentes campos dentro del perfil de usuario sin tener que preocuparse de que una aplicación anule los cambios realizados por otras (lo que puede suceder si se serializa obsoleto datos).

Listas (comandos)

Las listas Redis son colecciones ordenadas de cadenas. Están optimizados para insertar, leer o eliminar valores de la parte superior o inferior (aka: izquierda o derecha) de la lista.

Redis proporciona muchos comandos para aprovechar listas, incluyendo comandos para empujar/pop elementos, empujar/pop entre listas, truncar listas, realizar consultas de rango, etc.

Las listas hacen grandes colas atómicas y duraderas. Estos funcionan muy bien para las colas de trabajo, registros, búferes y muchos otros casos de uso.

Establece (comandos )

Los conjuntos son colecciones desordenadas de valores únicos. Están optimizados para que pueda comprobar rápidamente si un valor está en el conjunto, agregar/eliminar valores rápidamente y medir la superposición con otros conjuntos.

Estos son excelentes para cosas como listas de control de acceso, rastreadores de visitantes únicos y muchas otras cosas. La mayoría de los lenguajes de programación tienen algo similar (generalmente llamado un Conjunto). Esto es así, solo que distribuido.

Redis proporciona varios comandos para administrar conjuntos. Los obvios como agregar, eliminar y verificar el conjunto están presentes. También lo son los comandos menos obvios como hacer estallar/leer un elemento aleatorio y los comandos para realizar uniones e intersecciones con otros conjuntos.

Conjuntos ordenados (comandos)

Los conjuntos ordenados también son colecciones de valores únicos. Estos, como su nombre lo indica, están ordenados. Están ordenados por una partitura, entonces lexicográficamente.

Este tipo de datos está optimizado para búsquedas rápidas por puntuación. Obtener los valores más altos, más bajos o cualquier rango de valores intermedios es extremadamente rápido.

Si agregas usuarios a un conjunto ordenado junto con su puntuación más alta, tienes una tabla de líderes perfecta. A medida que llegan nuevas puntuaciones altas, simplemente agrégalas al conjunto de nuevo con su puntuación más alta y volverá a ordenar tu tabla de líderes. También es ideal para realizar un seguimiento de la última vez que los usuarios visitaron y que está activo en su aplicación.

Almacenar valores con la misma puntuación hace que se ordenen lexicográficamente (piense alfabéticamente). Esto puede ser útil para cosas como funciones de autocompletar.

Muchos de los comandos ordenados set son similares a los comandos para conjuntos, a veces con un parámetro de puntuación adicional. También se incluyen comandos para administrar partituras y consultar por partitura.

Geo

Redis tiene varios comandos para almacenar, recuperar, y medición de datos geográficos. Esto incluye consultas de radio y medición de distancias entre puntos.

Técnicamente los datos geográficos en redis se almacenan dentro de conjuntos ordenados, por lo que este no es un tipo de datos verdaderamente separado. Es más una extensión en la parte superior de los conjuntos ordenados.

Bitmap e HyperLogLog

Al igual que geo, estos no son tipos de datos completamente separados. Estos son comandos que le permiten tratar los datos de cadena como si fueran un mapa de bits o un hyperloglog.

Los mapas de bits son lo los operadores de nivel de bits a los que hice referencia en Strings son para. Este tipo de datos fue el bloque de construcción básico para el reciente proyecto de arte colaborativo de reddit: r/Place.

HyperLogLog le permite usar una cantidad constante extremadamente pequeña de espacio para contar valores únicos casi ilimitados con una precisión sorprendente. Usando solamente ~16KB usted podría contar eficientemente el número de visitantes únicos a su sitio, incluso si ese número está en los millones.

Transacciones y Atomicidad

Los comandos en redis son atómicos, lo que significa que puede estar seguro de que tan pronto como escriba un valor en redis ese valor es visible para todos los clientes conectados a redis. No hay que esperar a que ese valor se propague. Técnicamente memcached también es atómico, pero con redis agregando toda esta funcionalidad más allá de memcached, vale la pena señalar y algo impresionante que todos estos tipos de datos y características adicionales también son atómicos.

Aunque no es exactamente lo mismo que las transacciones en bases de datos relacionales, redis también tiene transacciones que utilizan "bloqueo optimista" (VER/MULTI/EXEC ).

Canalización

Redis proporciona una característica llamada ' canalización'. Si tiene muchos comandos de redis que desea ejecutar, puede usar canalización para enviarlos a redis de una vez en lugar de uno a la vez.

Normalmente, cuando ejecuta un comando en redis o memcached, cada comando es un comando separado ciclo de solicitud / respuesta. Con la canalización, redis puede almacenar en búfer varios comandos y ejecutarlos todos a la vez, respondiendo con todas las respuestas a todos sus comandos en una sola respuesta.

Esto puede permitirle lograr un rendimiento aún mayor en la importación masiva u otras acciones que involucran muchos comandos.

Pub / Sub

Redis tiene comandosdedicados a funcionalidad pub/sub, lo que permite a redis actuar como un emisor de mensajes de alta velocidad. Este permite que un solo cliente publique mensajes a muchos otros clientes conectados a un canal.

Redis hace pub/sub así como casi cualquier herramienta. Los brokers de mensajes dedicados como RabbitMQ pueden tener ventajas en ciertas áreas, pero el hecho de que el mismo servidor también puede darle colas duraderas persistentes y otras estructuras de datos que sus cargas de trabajo pub/sub probablemente necesiten, Redis a menudo demostrará ser la mejor y más simple herramienta para el trabajo.

Lua Scripting

Puedes piense en scripts lua como el propio SQL de redis o los procedimientos almacenados. Es más y menos que eso, pero la analogía funciona en su mayoría.

Tal vez tenga cálculos complejos que desea que redis realice. Tal vez no pueda permitirse el lujo de que sus transacciones se retrasen y necesite garantías de que cada paso de un proceso complejo ocurrirá atómicamente. Estos problemas y muchos más se pueden resolver con lua scripting.

Todo el script se ejecuta atómicamente, por lo que si puede lógica en un script lua a menudo puede evitar jugar con transacciones de bloqueo optimistas.

Escala

Como se mencionó anteriormente, redis incluye soporte incorporado para clustering y está incluido con su propia herramienta de alta disponibilidad llamada redis-sentinel.

Conclusión

Sin dudarlo, recomendaría redis sobre memcached para cualquier proyecto nuevo o existente que no use memcached.

Lo anterior puede sonar como si no me gustara memcached. Al contrario: es una herramienta poderosa, simple, estable, madura y endurecida. Incluso hay algunos casos de uso en los que es un poco más rápido que redis. Me encanta memcached. No creo que tenga mucho sentido para el desarrollo futuro.

Redis hace todo lo que memcached hace, a menudo mejor. Cualquier ventaja de rendimiento para memcached es menor y específica de la carga de trabajo. También hay cargas de trabajo para las que redis será más rápido, y muchas más cargas de trabajo que redis puede hacer que memcached simplemente no puede. las diferencias parecen menores frente al enorme abismo en funcionalidad y el hecho de que ambas herramientas son tan rápidas y eficientes que muy bien pueden ser la última pieza de su infraestructura que tendrá que preocuparse por escalar.

Solo hay un escenario donde memcached tiene más sentido: donde memcached ya está en uso como caché. Si ya está almacenando en caché con memcached, siga usándolo, si cumple con sus necesidades. Es probable que no valga la pena el esfuerzo de mudarse a redis y si usar redis solo para almacenar en caché puede no ofrecer suficientes beneficios para que valga la pena su tiempo. Si memcached no satisface tus necesidades, entonces probablemente deberías mudarte a redis. Esto es cierto si necesita escalar más allá de memcached o necesita funcionalidad adicional.

 1684
Author: Carl Zulauf,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-06-03 07:08:16

Utilice Redis si

  1. Es necesario eliminar selectivamente / caducar elementos en la caché. (Necesitas esto)

  2. Necesita la capacidad de consultar claves de un tipo particular. eq. 'blog1:entradas:*','blog2:categorías:xyz:entradas:*'. oh, sí! esto es muy importante. Use esto para invalidar ciertos tipos de elementos almacenados en caché de forma selectiva. También puede usar esto para invalidar la caché de fragmentos, la caché de páginas, solo los objetos AR de un tipo determinado, etc.

  3. Persistencia (Lo harás necesita esto también, a menos que esté de acuerdo con que su caché tenga que calentarse después de cada reinicio. Muy esencial para objetos que rara vez cambian)

Utilice memcached si

  1. Memcached te da la cabeza!
  2. umm... ¿agrupamiento? meh. si vas a ir tan lejos, usa Varnish y Redis para almacenar fragmentos y objetos AR en caché.

Desde mi experiencia he tenido una estabilidad mucho mejor con Redis que Memcached

 128
Author: SMathew,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-05 06:04:10

Memcached es multiproceso y rápido.

Redis tiene muchas características y es muy rápido, pero está completamente limitado a un núcleo, ya que se basa en un bucle de eventos.

Usamos ambos. Memcached se utiliza para almacenar objetos en caché, principalmente reduciendo la carga de lectura en las bases de datos. Redis se utiliza para cosas como conjuntos ordenados que son útiles para enrollar datos de series temporales.

 79
Author: W. Andrew Loe III,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-05-03 16:41:30

Esto es demasiado largo para ser publicado como un comentario a la respuesta ya aceptada, así que lo puse como una respuesta separada

Una cosa también a considerar es si espera tener un límite de memoria superior en su instancia de caché.

Dado que redis es una base de datos nosql con toneladas de características y el almacenamiento en caché es solo una opción para la que se puede usar, asigna la memoria según la necesite: cuantos más objetos ponga en ella, más memoria usará. La opción maxmemory no aplica estrictamente uso del límite superior de memoria. A medida que trabaja con caché, las claves son desalojadas y caducadas; lo más probable es que sus claves no sean todas del mismo tamaño, por lo que se produce una fragmentación de la memoria interna.

De forma predeterminada, redis usa jemalloc el asignador de memoria, que hace todo lo posible por ser compacto y rápido, pero es un asignador de memoria de propósito general y no puede mantenerse al día con muchas asignaciones y purga de objetos que ocurren a una velocidad alta. Debido a esto, en algunos patrones de carga el proceso redis puede al parecer, fuga de memoria debido a la fragmentación interna. Por ejemplo, si tiene un servidor con 7 Gb de RAM y desea usar redis como caché LRU no persistente, puede encontrar que el proceso redis con maxmemory establecido en 5 Gb con el tiempo usaría más y más memoria, eventualmente alcanzando el límite total de RAM hasta que interfiera el asesino sin memoria.

Memcached se ajusta mejor al escenario descrito anteriormente, ya que administra su memoria de una manera completamente diferente. memcached asigna una gran parte de la memoria - todo lo que necesitará-y luego gestiona esta memoria por sí misma, utilizando su propio asignador de losas implementado . Además, memcached se esfuerza por mantener la fragmentación interna baja, ya que en realidad utiliza el algoritmo LRU por losa, cuando los desalojos LRU se realizan con el tamaño del objeto considerado.

Dicho esto, memcached todavía tiene una posición fuerte en entornos, donde el uso de memoria tiene que ser forzado y/o predecible. Hemos intentado utilizar el último redis estable (2.8.19) como un reemplazo no persistente de memcached basado en LRU en una carga de trabajo de 10-15k op/s, y filtró mucho la memoria; la misma carga de trabajo estaba bloqueando las instancias de Amazon ElastiCache redis en un día más o menos debido a las mismas razones.

 70
Author: artyom,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-03-02 11:22:00

Memcached es bueno para ser un simple almacén de clave/valor y es bueno para hacer key => STRING. Esto lo hace realmente bueno para el almacenamiento de sesiones.

Redis es bueno haciendo key => SOME_OBJECT.

Realmente depende de lo que vas a poner ahí. Tengo entendido que en términos de rendimiento son bastante uniformes.

También buena suerte para encontrar puntos de referencia objetivos, si encuentras algunos amablemente envíalos a mi manera.

 45
Author: Erik Petersen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-05-11 23:32:37

Si no le importa un estilo de escritura burdo, Redis vs Memcached en el blog de Systoilet vale la pena leerlo desde el punto de vista de la usabilidad, pero asegúrese de leer el ida y vuelta en los comentarios antes de sacar conclusiones sobre el rendimiento; hay algunos problemas metodológicos (pruebas de bucle ocupado de un solo subproceso), y Redis ha hecho algunas mejoras desde que el artículo fue escrito también.

Y ningún enlace de referencia está completo sin confundir las cosas un poco, así que también echa un vistazo a algunos puntos de referencia conflictivos en el LiveJournal de Dormondo y el Weblog de Antirez .

Edit as como Antirez señala, el análisis de Systoilet es bastante mal concebido. Incluso más allá del déficit de un solo subproceso, gran parte de la disparidad de rendimiento en esos puntos de referencia se puede atribuir a las bibliotecas cliente en lugar del rendimiento del servidor. Los puntos de referencia en el Weblog Antirez de hecho presentan mucho más manzanas a manzanas (con la misma boca) comparación.

 37
Author: Paul Smith,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-01-03 14:02:19

Tuve la oportunidad de usar memcached y redis juntos en el proxy de almacenamiento en caché en el que he trabajado , déjame compartir contigo dónde exactamente he usado qué y la razón detrás de lo mismo....

Redis >

1) Se utiliza para indexar el contenido de la caché , sobre el clúster . Tengo más de mil millones de claves repartidas en clústeres de redis , los tiempos de respuesta de redis son bastante menores y estables .

2) Básicamente, es un almacén de clave / valor, por lo que dondequiera que en su aplicación tenga algo similar, uno puede utilizar redis con molestar mucho.

3) La persistencia de Redis, la conmutación por error y la copia de seguridad (AOF ) facilitarán su trabajo .

Memcache >

1) sí , una memoria optimizada que se puede utilizar como caché . Lo utilicé para almacenar contenido de caché que se accede con mucha frecuencia (con 50 visitas/segundo)con un tamaño inferior a 1 MB .

2) Asigné solo 2 GB de 16 GB para memcached que también cuando mi tamaño de contenido único era >1MB .

3) A medida que el contenido crece cerca del límites, ocasionalmente he observado tiempos de respuesta más altos en las estadísticas (no es el caso de redis) .

Si solicita experiencia general, Redis es mucho verde, ya que es fácil de configurar, mucho flexible con características robustas y estables.

Además, hay un resultado de benchmarking disponible en este enlace , a continuación son pocos higlight de la misma,

introduzca la descripción de la imagen aquí

introduzca la descripción de la imagen aquí

Espero que esto ayude!!

 19
Author: Jain Rach,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-06-29 06:57:26

Otra ventaja es que puede ser muy claro cómo memcache se va a comportar en un escenario de almacenamiento en caché, mientras que redis se utiliza generalmente como un almacén de datos persistente, aunque se puede configurar para comportarse como memcached también conocido como desalojar los elementos Menos Utilizados recientemente cuando alcanza la capacidad máxima.

Algunas aplicaciones en las que he trabajado usan ambas solo para dejar claro cómo pretendemos que se comporten los datos-cosas en memcache, escribimos código para manejar los casos en los que no está - cosas en redis, confiamos en estar ahí.

Aparte de eso, Redis generalmente se considera superior para la mayoría de los casos de uso, ya que es más rico en funciones y, por lo tanto, flexible.

 12
Author: Scott Schulthess,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-04 12:42:21

Prueba. Ejecutar algunos puntos de referencia simples. Durante mucho tiempo me consideré un rinoceronte de la vieja escuela ya que usé principalmente memcached y consideré a Redis el nuevo chico.

Con mi empresa actual, Redis se utilizó como caché principal. Cuando profundicé en algunas estadísticas de rendimiento y simplemente comencé a probar, Redis era, en términos de rendimiento, comparable o mínimamente más lento que MySQL.

Memcached, aunque simplista, sopló Redis fuera del agua totalmente. Escala mucho mejor:

  • para valores más grandes (cambio requerido en el tamaño de la losa, pero trabajado)
  • para múltiples solicitudes simultáneas

También, en mi opinión, la política de desalojo de memcached está mucho mejor implementada, lo que resulta en un tiempo de respuesta promedio general más estable mientras maneja más datos de los que la caché puede manejar.

Algunos benchmarking revelaron que Redis, en nuestro caso, funciona muy mal. Esto creo que tiene que ver con muchas variables:

  • tipo de hardware se ejecuta Redis en
  • tipos de datos que almacena
  • cantidad de gets y conjuntos
  • qué tan concurrente es tu aplicación
  • ¿necesita almacenamiento de estructura de datos

Personalmente, no comparto la opinión que tienen los autores de Redis sobre concurrencia y multihilo.

 12
Author: mdomans,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-11-13 08:14:27

No estaría mal, si decimos que redis es una combinación de (caché + estructura de datos) mientras que memcached es solo una caché.

 9
Author: Atif Hussain,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-06-16 05:45:06

Una diferencia importante que no se ha señalado aquí es que Memcache tiene un límite de memoria superior en todo momento, mientras que Redis no lo tiene por defecto (pero se puede configurar para). Si siempre desea almacenar una clave/valor durante cierta cantidad de tiempo (y nunca desalojarla debido a la poca memoria), desea ir con Redis. Por supuesto, también corre el riesgo de quedarse sin memoria...

 7
Author: Ztyx,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-01 09:45:27

Una prueba muy simple para establecer y obtener claves y valores únicos de 100k contra redis-2.2.2 y memcached. Ambos se ejecutan en linux VM (CentOS) y mi código de cliente(pegado a continuación) se ejecuta en el escritorio de Windows.

Redis

  • El tiempo necesario para almacenar 100000 valores es = 18954ms

  • El tiempo necesario para cargar 100000 valores es = 18328ms

Memcached

  • El tiempo necesario para almacenar 100000 valores es = 797ms

  • Hora tomado para recuperar 100000 valores es = 38984ms


Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");
 6
Author: Prabhu Nandan Kumar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-11-04 06:57:41

Pensamos en Redis como un despegue de carga para nuestro proyecto en el trabajo. Pensamos que al usar un módulo en nginx llamado HttpRedis2Module o algo similar, tendríamos una velocidad increíble, pero cuando probamos con AB-test estamos equivocados.

Tal vez el módulo era malo o nuestro diseño, pero era una tarea muy simple y era aún más rápido tomar datos con php y luego rellenarlos en MongoDB. Estamos usando APC como sistema de caché y con eso php y MongoDB. Fue mucho más rápido que nginx Redis módulo.

Mi consejo es probarlo usted mismo, hacerlo le mostrará los resultados para su entorno. Decidimos que usar Redis era innecesario en nuestro proyecto, ya que no tendría ningún sentido.

 5
Author: Ms01,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-05 11:48:40

La mayor razón restante es la especialización.

Redis puede hacer muchas cosas diferentes y un efecto secundario de eso es que los desarrolladores pueden comenzar a usar muchos de esos diferentes conjuntos de características en la misma instancia. Si está utilizando la función LRU de Redis para una caché junto con el almacenamiento de datos duros que NO es LRU, es completamente posible quedarse sin memoria.

Si va a configurar una instancia de Redis dedicada para que se use SOLO como una instancia de LRU para evitar ese escenario en particular entonces no hay realmente ninguna razón convincente para usar Redis sobre Memcached.

Si necesita un caché LRU confiable "nunca se cae"...Memcached se ajustará a la factura, ya que es imposible que se quede sin memoria por diseño y la funcionalidad especializada evita que los desarrolladores intenten hacerlo algo que podría poner en peligro eso. Simple separación de preocupaciones.

 4
Author: brightball,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-11-20 21:32:31

Redis es mejor Los pros de Redis son ,

1.It has a lot of data storage options such  as  string  , sets , sorted sets ,  hashes ,  bitmaps
2.Disk Persistence of records 
3.Stored Procedure (LUA acripting)  support
4.Can act as a Message Broker using PUB/SUB

Mientras que Memcache es un sistema de tipo de caché de valor de clave en memoria.

  1. No hay soporte para varios almacenamientos de tipo de datos como listas, conjuntos como en redis.
  2. La principal estafa es que Memcache no tiene persistencia de disco .
 2
Author: athavan kanapuli,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-03-22 04:22:12

Memcached será más rápido si está interesado en el rendimiento, incluso porque Redis implica redes (llamadas TCP). También internamente Memcache es más rápido.

Redis tiene más características como se mencionó en otras respuestas.

 1
Author: Denys,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-06-19 20:55:47

Bueno, utilicé principalmente ambos con mis aplicaciones, Memcache para cache las sesiones y redis para objetos de consultas doctrine/doctrine. En términos de rendimiento, ambos son casi iguales.

 0
Author: Muhammad Taqi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-10-31 21:08:55