De La Instalación:


Imaginar un ‘twitter como’ servicio donde un usuario envía un mensaje, la cual es leída por muchos (cientos, miles, o más) de los usuarios.

Mi pregunta es con respecto a la mejor manera de arquitecto de la caché & base de datos para optimizar el acceso rápido & muchas lecturas, pero aún así mantener el histórico de datos, de modo que los usuarios pueden (si quieren) ver las entradas más antiguas. La suposición aquí es que el 90% de los usuarios que sólo estaría interesado en las cosas nuevas, y que las cosas viejas se consigue acceder de vez en cuando. La otra suposición aquí es que queremos optimizar para el 90%, y su bien, si la edad de 10% tomar un poco más de tiempo para recuperar.

Con esto en mente, mi investigación me parece fuertemente en la dirección de uso de una memoria caché para el 90%, y luego también para almacenar los mensajes en otro de más largo plazo persistente del sistema. Así que mi idea es usar Redis para la memoria caché. Las ventajas es que Redis es muy rápido, y también se ha construido en el pub/sub que sería perfecto para la publicación de posts para muchas personas. Y entonces yo estaba considerando la posibilidad de usar MongoDB como una más permanente almacén de datos para almacenar la misma los puestos que se tendrá acceso en la medida que expiren de Redis.

Preguntas:

1. ¿Esta arquitectura de retención de agua? Hay una manera mejor de hacer esto?

2. En cuanto al mecanismo para el almacenamiento de entradas tanto en la Redis & MongoDB, yo estaba pensando en tener la aplicación hace 2 escribe: 1º – escribir a Redis, entonces es inmediatamente disponible para los suscriptores. 2º – después de guardar correctamente a Redis, escribir a MongoDB inmediatamente. Es esta la mejor manera de hacerlo? Debo lugar de tener Redis empuje la expirado puestos a MongoDB sí mismo? Pensé acerca de esto, pero no pude encontrar mucha información acerca de empujar a MongoDB desde Redis directamente.

  • Redis no presionan a MongoDb. Tienes que hacerlo tú mismo. O simplemente escribir en ambos lugares al mismo tiempo (como usted sugiere).
  • Siempre me empuje a la más robusta de la primera tienda (MongoDB en este caso), o como Sergio sugerido, async al mismo tiempo. Nunca al revés.
  • Mi pregunta es, ¿puede almacenar sólo los identificadores de los mensajes en la memoria caché o la totalidad de las listas de correos de los objetos en la memoria caché ?
InformationsquelleAutor Ryan Ogle | 2012-06-27

1 Comentario

  1. 36

    Es realmente sensible a asociar Redis y MongoDB: son buenos jugadores de equipo. Encontrará más información aquí:

    MongoDB con redis

    Un punto crítico es la resistencia de nivel que usted necesita. Ambos Redis y MongoDB puede ser configurado para alcanzar un nivel aceptable de resistencia, y estas consideraciones deben ser discutidos en tiempo de diseño. También, se puede poner restricciones en la implementación de opciones: si desea maestro/esclavo de replicación para ambos Redis y MongoDB necesita al menos 4 cajas (Redis y MongoDB no debe ser implementado en la misma máquina).

    Ahora, puede ser un poco más simple para mantener Redis de la cola, pub/sub, etc … y almacenar los datos de usuario en MongoDB sólo. La justificación es que no tienes el diseño de datos similares caminos de acceso (la parte más difícil de este trabajo) para dos tiendas con diferentes paradigmas. También, MongoDB se ha incorporado en la escalabilidad horizontal (conjuntos de réplica, auto-fragmentación, etc …), mientras que Redis sólo ha do-it-yourself escalabilidad.

    Respecto a la segunda cuestión, escrito a ambas tiendas sería la forma más fácil de hacerlo. No hay ninguna característica integrada de replicar Redis actividad de MongoDB. El diseño de un demonio escuchando una Redis cola (en las que la actividad iba a ser publicado) y la escritura de MongoDB no es tan difícil, aunque.

    • Tengo curiosidad, alguno de los enlaces/fondo sobre por qué Redis y Mongo no debería ser implementado en la misma máquina?
    • Esto es debido al hecho de MongoDB mapas de los archivos de datos en la memoria. Para que se utiliza el mecanismo de memoria virtual para acceder a los datos cuya estructura está diseñada para favorecer la localidad (btrees se utilizan para los índices, por ejemplo). Con MongoDB, cuando los datos no caben en la memoria, la máquina de intercambio, y está diseñado para esto.
    • Por el contrario, Redis es una pura memoria principal almacén de datos, basado en la memoria de datos orientado a estructuras (tablas hash, listas, saltar listas, etc …) que no aplican ningún tipo de localidad. Porque es un solo hilo, el rendimiento es dramáticamente afectada cuando Redis memoria se intercambia.
    • Así que si usted pone MongoDB y Redis en el mismo cuadro y MongoDB datos no caben en la memoria, MongoDB va a «robar» la memoria a Redis a través de la OS mecanismo de paginación. La consecuencia es una mayor disminución del rendimiento de Redis.
    • Gracias, es bueno saberlo. En cajas donde ambos Mongo y Redis datos caben en la memoria Ram completamente puedo tomar este no es un problema?
    • Correcto. Si todo cabe en la memoria, no hay ningún problema.
    • No podemos limitar el mongo con cgroups para que redis tiene al menos max-memory-limit disponible en todo momento?
    • Nunca he probado con cgroups con mongo, pero debería funcionar. Por favor nota Redis requiere más memoria de la que max-memory-limit (comunicación buffers, etc …). Usted probablemente tendrá que medir el tamaño de la cgroups config.
    • Así que al final no se hacen más sentido escribir a redis y mongodb al mismo tiempo? También, para hacer una lectura, debe redis ser consultado primero y si no existe consulta mongo?

Dejar respuesta

Please enter your comment!
Please enter your name here