En fonction de la structure de votre clé, je recommanderais de canaliser les commandes zincr. Vous avez un déclencheur "commit" facile - la requête. Si vous deviez itérer sur vos paramètres et zincr chaque clé, alors à la fin de la requête, passez la commande d'exécution, ce sera très rapide. J'ai implémenté un système comme vous le décrivez à la fois comme cgi et comme application Django. J'ai mis en place une structure de clé dans le sens de ceci :
AAAA-MM-JJ:HH:MM -> ensemble trié
Et a été capable de traiter quelque chose comme 150 000 à 200 000 incréments par seconde du côté redis avec un seul processus, ce qui devrait suffire à votre scénario décrit. Cette structure clé me permet de saisir des données basées sur des fenêtres de temps. J'ai également ajouté une expiration aux clés pour éviter d'écrire un processus de nettoyage de la base de données. J'ai ensuite eu un cronjob qui définirait des opérations pour "cumuler" des statistiques horaires, quotidiennes et hebdomadaires en utilisant des variantes du modèle de clé susmentionné. J'évoque ces idées car ce sont des moyens de tirer parti des capacités intégrées de Redis pour simplifier le côté rapports. Il existe d'autres façons de le faire, mais ce modèle semble bien fonctionner.
Comme l'a noté eyossi, le verrou global peut être un réel problème avec les systèmes qui effectuent des écritures et des lectures simultanées. Si vous écrivez ceci comme un système en temps réel, la simultanéité pourrait bien être un problème. S'il s'agit d'un système d'analyse de journal "end if day", il ne déclenchera probablement pas le conflit à moins que vous n'exécutiez plusieurs instances de l'analyseur ou des rapports au moment de la saisie. En ce qui concerne la rapidité des lectures dans Redis, j'envisagerais de configurer une instance redis en lecture seule asservie à la principale. Si vous le placez sur le serveur exécutant le rapport et dirigez le processus de rapport vers celui-ci, la génération des rapports devrait être très rapide.
Selon la mémoire disponible, la taille de l'ensemble de données et si vous stockez d'autres types de données dans l'instance Redis, vous pouvez envisager d'exécuter un serveur Redis 32 bits pour réduire l'utilisation de la mémoire. Une instance 32b devrait pouvoir conserver une grande partie de ce type de données dans une petite partie de la mémoire, mais si l'exécution de Redis 64 bits normal ne prend pas trop de mémoire, n'hésitez pas à l'utiliser. Comme toujours, testez vos propres habitudes d'utilisation pour valider
