Pour une solution de récolte comme celle-ci, je recommanderais une approche en plusieurs étapes. Redis est doué pour la communication en temps réel . Redis est conçu comme un magasin de clés/valeurs en mémoire et hérite de certains avantages très intéressants d'être une base de données en mémoire :opérations de liste O(1). Tant qu'il y a de la RAM à utiliser sur un serveur, Redis ne ralentira pas la poussée jusqu'à la fin de vos listes, ce qui est bien lorsque vous devez insérer des éléments à un rythme aussi extrême. Malheureusement, Redis ne peut pas fonctionner avec des ensembles de données plus grands que la quantité de RAM dont vous disposez (il ne fait que écrire sur le disque, la lecture sert à redémarrer le serveur ou en cas de plantage du système) et la mise à l'échelle doit être effectuée par vous et votre candidature . (Une méthode courante consiste à répartir les clés sur de nombreux serveurs, ce qui est implémenté par certains pilotes Redis, en particulier ceux pour Ruby on Rails.) Redis prend également en charge la simple messagerie de publication/abonnement, qui peut également être utile à certains moments.
Dans ce scénario, Redis est la "première étape". Pour chaque type d'événement spécifique, vous créez une liste dans Redis avec un nom unique ; par exemple, nous avons "page consultée" et "lien cliqué". Pour plus de simplicité, nous voulons nous assurer que les données de chaque liste ont la même structure ; le lien cliqué peut avoir un jeton d'utilisateur, un nom de lien et une URL, tandis que la page consultée ne peut avoir que le jeton d'utilisateur et l'URL. Votre première préoccupation est simplement d'obtenir le fait que cela s'est produit et tout ce qui est absolument nécessaire les données dont vous avez besoin sont poussées.
Ensuite, nous avons de simples travailleurs de traitement qui retirent ces informations frénétiquement insérées des mains de Redis, en lui demandant de retirer un élément de la fin de la liste et de le remettre. Le travailleur peut effectuer tous les ajustements/déduplications/recherches d'ID nécessaires pour classer correctement les données et les transférer vers un site de stockage plus permanent. Lancez autant de ces travailleurs que nécessaire pour que la charge de la mémoire de Redis reste supportable. Vous pouvez écrire les travailleurs dans tout ce que vous souhaitez (Node.js, C #, Java, ...) tant qu'il a un pilote Redis (la plupart des langages Web le font maintenant) et un pour le stockage souhaité (SQL, Mongo, etc. )
MongoDB est bon pour le stockage de documents . Contrairement à Redis, il est capable de gérer des bases de données plus grandes que la RAM et il prend en charge le partitionnement/la réplication par lui-même. Un avantage de MongoDB par rapport aux options basées sur SQL est que vous n'avez pas besoin d'avoir un schéma prédéterminé, vous êtes libre de modifier la façon dont les données sont stockées comme vous le souhaitez à tout moment.
Je suggérerais cependant Redis ou Mongo pour la phase "première étape" de la conservation des données pour le traitement et utiliser une configuration SQL traditionnelle (Postgres ou MSSQL, peut-être) pour stocker les données post-traitées. Pour moi, le suivi du comportement des clients ressemble à des données relationnelles, car vous voudrez peut-être choisir "Montrez-moi tous ceux qui consultent cette page" ou "Combien de pages cette personne a-t-elle vues ce jour-là" ou "Quel jour a eu le plus de visiteurs au total ? ". Il peut y avoir des jointures ou des requêtes encore plus complexes à des fins d'analyse que vous proposez, et les solutions SQL matures peuvent faire une grande partie de ce filtrage pour vous; NoSQL (Mongo ou Redis en particulier) ne peut pas effectuer de jointures ou de requêtes complexes sur des ensembles de données variés.
