Architecture pour le cache Redis et Mongo pour la persistance
La mise en place:
Imaginez un service "semblable à Twitter" dans lequel un utilisateur soumet un message, qui est ensuite lu par de nombreux (centaines, milliers ou plus) utilisateurs.
Ma question concerne la meilleure façon d'architecturer le cache et la base de données pour optimiser un accès rapide et de nombreuses lectures, mais conserver les données historiques afin que les utilisateurs puissent (s'ils le souhaitent) voir les anciens messages. L'hypothèse ici est que 90% des utilisateurs ne seraient intéressés que par les nouveaux trucs et que les anciens trucs seront consultés occasionnellement. L'autre hypothèse ici est que nous voulons optimiser pour les 90%, et c'est ok si les 10% plus anciens mettent un peu plus de temps à récupérer.
Dans cet esprit, mes recherches semblent pointer fortement vers l'utilisation d'un cache pour les 90%, puis pour stocker également les messages dans un autre système persistant à plus long terme. Donc, mon idée jusqu'à présent est d'utiliser Redis pour le cache. Les avantages sont que Redis est très rapide, et il a également intégré un pub/sub qui serait parfait pour publier des articles pour de nombreuses personnes. Et puis, j'envisageais d'utiliser MongoDB comme un magasin de données plus permanent pour stocker les mêmes messages qui seront accessibles lorsqu'ils expireront de Redis.
Des questions:
1. Cette architecture tient-elle l'eau? Y a-t-il une meilleure manière de faire cela?
2. En ce qui concerne le mécanisme de stockage des publications dans Redis et MongoDB, je pensais que l'application ferait 2 écritures: 1ère - écrire à Redis, elle est ensuite immédiatement disponible pour les abonnés. 2e - après avoir enregistré avec succès sur Redis, écrivez immédiatement à MongoDB. Est-ce la meilleure façon de le faire? Dois-je plutôt demander à Redis de pousser les messages expirés vers MongoDB lui-même? J'y ai pensé, mais je n'ai pas pu trouver beaucoup d'informations sur la façon de pousser directement MongoDB depuis Redis.
Il est en fait judicieux d'associer Redis et MongoDB: ce sont de bons joueurs d'équipe. Vous trouverez plus d'informations ici:
Un point critique est le niveau de résilience dont vous avez besoin. Redis et MongoDB peuvent être configurés pour atteindre un niveau de résilience acceptable, et ces considérations doivent être discutées au moment de la conception. En outre, cela peut restreindre les options de déploiement: si vous souhaitez une réplication maître/esclave pour Redis et MongoDB, vous avez besoin d'au moins 4 boîtes (Redis et MongoDB ne doivent pas être déployés sur la même machine).
Maintenant, il peut être un peu plus simple de conserver Redis pour la mise en file d'attente, la publication/sub, etc ... et de stocker les données utilisateur dans MongoDB uniquement. La justification est que vous n'avez pas à concevoir des chemins d'accès aux données similaires (la partie difficile de ce travail) pour deux magasins présentant des paradigmes différents. De plus, MongoDB a une évolutivité horizontale intégrée (jeux de répliques, partage automatique, etc.) tandis que Redis n'a qu'une évolutivité à faire soi-même.
En ce qui concerne la deuxième question, écrire aux deux magasins serait le moyen le plus simple de le faire. Il n'y a pas de fonction intégrée pour répliquer l'activité de Redis sur MongoDB. Concevoir un démon écoutant une file d'attente Redis (où l'activité serait publiée) et écrire sur MongoDB n'est pas si difficile que cela.