Afhængigt af hvordan din nøglestruktur er lagt ud, vil jeg anbefale at pipeline zincr kommandoerne. Du har en let "commit" trigger - anmodningen. Hvis du skulle iterere over dine parametre og zincr hver tast, så vil det være meget hurtigt ved afslutningen af anmodningen. Jeg har implementeret et system, som du beskriver som både en cgi- og en Django-app. Jeg opretter en nøglestruktur i stil med denne:
ÅÅÅÅ-MM-DD:TT:MM -> sorteret sæt
Og var i stand til at behandle noget i retning af 150.000-200.000 trin i sekundet på redis-siden med en enkelt proces, som burde være rigeligt til dit beskrevne scenarie. Denne nøglestruktur giver mig mulighed for at få fat i data baseret på tidsvinduer. Jeg har også tilføjet et udløb til nøglerne for at undgå at skrive en db-oprydningsproces. Jeg havde så en cronjob, der ville sætte operationer til at "rulle op" statistik til time, daglig og ugentlig ved hjælp af varianter af det førnævnte nøglemønster. Jeg bringer disse ideer frem, da de er måder, hvorpå du kan drage fordel af Redis' indbyggede muligheder for at gøre rapporteringssiden enklere. Der er andre måder at gøre det på, men dette mønster ser ud til at fungere godt.
Som bemærket af eyossi kan den globale lås være et reelt problem med systemer, der skriver og læser samtidig. Hvis du skriver dette som et realtidssystem, kan samtidighed meget vel være et problem. Hvis det er et "end if day" log-parsing-system, vil det sandsynligvis ikke udløse striden, medmindre du kører flere forekomster af parseren eller rapporterne på tidspunktet for input. Med hensyn til at holde læsninger hurtige i Redis, ville jeg overveje at oprette en read only redis-instans, der er slave af den primære. Hvis du sætter den på serveren, der kører rapporten, og peger rapporteringsprocessen på den, burde det være meget hurtigt at generere rapporterne.
Afhængigt af din tilgængelige hukommelse, datasætstørrelse og om du gemmer andre typer data i redis-forekomsten, kan du overveje at køre en 32bit redis-server for at holde hukommelsesforbruget nede. En 32b-instans burde være i stand til at opbevare en masse af denne type data i en lille del af hukommelsen, men hvis det at køre den normale 64 bit Redis ikke tager for meget hukommelse, er du velkommen til at bruge den. Som altid test dine egne brugsmønstre for at validere