Arquitectura para Redis caché y Mongo para persistencia

Question

Configuración:
Imagina un servicio 'twitter like' donde un usuario envía una publicación, que luego es leída por muchos (cientos, miles o más) usuarios.

Mi pregunta es con respecto a la mejor manera de arquitecto la base de datos de caché para optimizar & para un acceso rápido & muchas lecturas, pero aún así mantener los datos históricos para que los usuarios pueden (si quieren) ver las entradas más antiguas. La suposición aquí es que el 90% de los usuarios solo estaría interesado en las cosas nuevas, y que a las cosas viejas se accederá ocasionalmente. La otra suposición aquí es que queremos optimizar el 90%, y está bien si el 10% anterior tarda un poco más en recuperarse.

Teniendo esto en cuenta, mi investigación parece apuntar fuertemente en la dirección de usar un caché para el 90%, y luego también almacenar las publicaciones en otro sistema persistente a largo plazo. Entonces mi idea hasta ahora es usar Redis para el caché. Las ventajas son que Redis es muy rápido, y también se ha incorporado en pub/sub, que sería perfecto para publicar publicaciones a mucha gente. Y luego estaba considerando usar MongoDB como una tienda de datos más permanente para almacenar las mismas publicaciones a las que se accederá a medida que vencen fuera de Redis.

Preguntas:
1. ¿Esta arquitectura contiene agua? ¿Hay una mejor manera de hacer esto?
2. En cuanto al mecanismo para almacenar publicaciones tanto en el Redis & MongoDB, estaba pensando en hacer que la aplicación haga 2 escrituras: Primero: escriba a Redis, entonces está inmediatamente disponible para los suscriptores. 2º - después de almacenar con éxito en Redis, escriba a MongoDB inmediatamente. ¿Es esta la mejor manera de hacerlo? ¿Debo hacer que Redis presione los mensajes caducados para MongoDB? Pensé en esto, pero no pude encontrar mucha información sobre cómo empujar directamente a MongoDB desde Redis.

Answer 1

En realidad, es sensato asociar a Redis y MongoDB: son buenos jugadores de equipo. Va a encontrar más información aquí:

MongoDB with redis

Un punto crítico es el nivel de capacidad de recuperación que necesita. Tanto Redis como MongoDB se pueden configurar para lograr un nivel aceptable de flexibilidad, y estas consideraciones se deben analizar en el momento del diseño. Además, puede poner restricciones a las opciones de implementación: si desea la replicación maestro/esclavo para Redis y MongoDB necesita al menos 4 cuadros (Redis y MongoDB no deben desplegarse en la misma máquina).

Ahora, puede ser un poco más simple mantener Redis para hacer cola, pub/sub, etc. ... y almacenar los datos del usuario en MongoDB solamente. La razón fundamental es que no tiene que diseñar rutas de acceso a datos similares (la parte más difícil de este trabajo) para dos tiendas con diferentes paradigmas. Además, MongoDB tiene escalabilidad horizontal incorporada (conjuntos de réplicas, fragmentación automática, etc.) mientras que Redis solo tiene escalabilidad de bricolaje.

En cuanto a la segunda pregunta, escribir en ambas tiendas sería la forma más fácil de hacerlo. No hay una función incorporada para replicar la actividad de Redis a MongoDB. Sin embargo, diseñar un daemon escuchando una cola de Redis (donde se publicaría la actividad) y escribir en MongoDB no es tan difícil.