MongoDB con redis

¿Alguien puede dar ejemplos de casos de uso en los que se beneficiaría de usar Redis y MongoDB en conjunto?

Redis y MongoDB se pueden usar juntos con buenos resultados. Una empresa conocida por ejecutar MongoDB y Redis (junto con MySQL y Sphinx) es Craiglist. Vea esta presentación de Jeremy Zawodny.

MongoDB es interesante para datos persistentes, orientados a documentos e indexados de varias formas. Redis es más interesante para datos volátiles o datos semipersistentes sensibles a la latencia.

A continuación, se muestran algunos ejemplos del uso concreto de Redis además de MongoDB.

• MongoDB anterior a 2.2 aún no tiene un mecanismo de vencimiento. Las colecciones limitadas no se pueden utilizar realmente para implementar un TTL real. Redis tiene un mecanismo de vencimiento basado en TTL, lo que hace que sea conveniente almacenar datos volátiles. Por ejemplo, las sesiones de usuario se almacenan comúnmente en Redis, mientras que los datos de usuario se almacenarán e indexarán en MongoDB. Tenga en cuenta que MongoDB 2.2 ha introducido un mecanismo de caducidad de baja precisión en el nivel de recopilación (para ser utilizado para purgar datos, por ejemplo).

• Redis proporciona un tipo de datos de conjunto conveniente y sus operaciones asociadas (unión, intersección, diferencia en varios conjuntos, etc.). Es bastante fácil implementar un motor básico de búsqueda o etiquetado por facetas además de esta característica, que es una adición interesante a las capacidades de indexación más tradicionales de MongoDB.

• Redis admite operaciones emergentes de bloqueo eficientes en listas. Esto se puede utilizar para implementar un sistema de cola distribuida ad-hoc. Es más flexible que los cursores adaptables de MongoDB, en mi opinión, ya que una aplicación de backend puede escuchar varias colas con un tiempo de espera, transferir elementos a otra cola de forma atómica, etc. Si la aplicación requiere algo de cola, tiene sentido almacenar la cola en Redis y mantenga los datos funcionales persistentes en MongoDB.

• Redis también ofrece un mecanismo pub / sub. En una aplicación distribuida, un sistema de propagación de eventos puede resultar útil. Este es nuevamente un excelente caso de uso para Redis, mientras que los datos persistentes se mantienen en MongoDB.

Debido a que es mucho más fácil diseñar un modelo de datos con MongoDB que con Redis (Redis es de nivel más bajo), es interesante beneficiarse de la flexibilidad de MongoDB para los datos persistentes principales y de las características adicionales proporcionadas por Redis (baja latencia , caducidad de elementos, colas, pub / sub, bloques atómicos, etc ...). De hecho, es una buena combinación.

Tenga en cuenta que nunca debe ejecutar un servidor Redis y MongoDB en la misma máquina. La memoria MongoDB está diseñada para intercambiarse, pero Redis no. Si MongoDB desencadena alguna actividad de intercambio, el rendimiento de Redis será catastrófico. Deben estar aislados en diferentes nodos.

Obviamente, hay muchas más diferencias que esto, pero para una descripción general extremadamente alta:

Para casos de uso:

• Redis se utiliza a menudo como una capa de almacenamiento en caché o una pizarra compartida para la computación distribuida.
• MongoDB se usa a menudo como un reemplazo de intercambio para las bases de datos SQL tradicionales.

Técnicamente:

• Redis es una base de datos en memoria con persistencia de disco (toda la base de datos debe caber en la RAM).
• MongoDB es una base de datos respaldada en disco que solo necesita suficiente RAM para los índices.

Existe cierta superposición, pero es muy común utilizar ambos. Este es el por qué:

• MongoDB puede almacenar más datos de forma más económica.
• Redis es más rápido para todo el conjunto de datos.
• La cultura de MongoDB es "almacenarlo todo, descubrir patrones de acceso más tarde"
• La cultura de Redis es "considerar cuidadosamente cómo accederá a los datos y luego los almacenará"
• Ambos tienen herramientas de código abierto que dependen de ellos, muchas de las cuales se utilizan juntas.

Redis se puede usar como reemplazo de un almacén de datos tradicional, pero se usa con mayor frecuencia con otro almacén de datos "largo" normal, como Mongo, Postgresql, MySQL, etc.

Redis funciona de manera excelente con MongoDB como servidor de almacenamiento en caché. Esto es lo que sucede.

Cada vez que la mangosta emite una consulta de caché, primero pasará al servidor de caché.

El servidor de caché comprobará si esa consulta exacta se ha emitido antes.

Si no es así, el servidor de caché tomará la consulta, la enviará a mongodb y Mongo ejecutará la consulta.

Luego tomaremos el resultado de esa consulta, luego regresa al servidor de caché, el servidor de caché almacenará el resultado de la consulta en sí mismo.

Dirá que cada vez que ejecuto esa consulta, obtengo esta respuesta y, por lo tanto, mantendrá un registro entre las consultas que se emiten y las respuestas que regresan de esas consultas.

El servidor de caché tomará la respuesta y la enviará de vuelta a mongoose, mongoose la dará a express y eventualmente terminará dentro de la aplicación.

Cada vez que se vuelve a emitir la misma consulta exacta, mongoose enviará la misma consulta al servidor de caché, pero si el servidor de caché ve que esta consulta se emitió antes, no enviará la consulta a mongodb, sino que llevará la respuesta a la consulta que recibió la última vez e inmediatamente se la envía a mangosta. Aquí no hay índices, no hay escaneo de tabla completo, nada.

Estamos haciendo una búsqueda simple para decir ¿se ha ejecutado esta consulta? ¿Si? De acuerdo, toma la solicitud y devuélvela de inmediato y no envíes nada a mongo.

Tenemos el servidor de mangosta, el servidor de caché (Redis) y Mongodb.

En el servidor de caché puede haber un almacén de datos con un tipo de almacén de datos de valor clave donde todas las claves son algún tipo de consulta emitida antes y el valor es el resultado de esa consulta.

Entonces, tal vez estemos buscando un montón de publicaciones de blog de _id.

Entonces, tal vez las claves aquí sean el _id de los registros que hemos buscado antes.

Así que imaginemos que Mongoose emite una nueva consulta en la que intenta encontrar una publicación de blog con _id de 123, la consulta fluye hacia el servidor de caché, el servidor de caché comprobará si tiene un resultado para cualquier consulta que buscaba un _id de 123.

Si no existe en el servidor de caché, esta consulta se toma y se envía a la instancia de mongodb. Mongodb ejecutará la consulta, obtendrá una respuesta y la devolverá.

Este resultado se envía de vuelta al servidor de caché, que toma ese resultado y lo envía inmediatamente a mangosta para que obtengamos una respuesta lo más rápida posible.

Inmediatamente después de eso, el servidor de caché también tomará la consulta emitida y la agregará a su colección de consultas que se han emitido y tomará el resultado de la consulta y lo almacenará junto con la consulta.

Entonces, podemos imaginar que en el futuro volvemos a emitir la misma consulta, llega al servidor de caché, mira todas las claves que tiene y dice oh, ya encontré esa publicación de blog, no llega a mongo, solo toma el resultado de la consulta y lo envía directamente a mangosta.

No estamos haciendo una lógica de consulta compleja, ni índices, nada de eso. Es lo más rápido posible. Es una simple búsqueda de valor clave.

Esa es una descripción general de cómo funciona el servidor de caché (Redis) con MongoDB.

Ahora hay otras preocupaciones. ¿Estamos almacenando datos en caché para siempre? ¿Cómo actualizamos los registros?

No queremos estar siempre almacenando datos en el caché y leer desde el caché.

El servidor de caché no se utiliza para acciones de escritura. La capa de caché solo se usa para leer datos. Si alguna vez escribimos datos, la escritura siempre irá a la instancia de mongodb y debemos asegurarnos de que cada vez que escribimos datos borremos los datos almacenados en el servidor de caché que estén relacionados con el registro que acabamos de actualizar en Mongo.