Til en høstløsning som denne vil jeg anbefale en flertrinstilgang. Redis er god til realtidskommunikation . Redis er designet som et nøgle-/værdilager i hukommelsen og arver nogle meget gode fordele ved at være en hukommelsesdatabase:O(1) listeoperationer. Så længe der er RAM at bruge på en server, vil Redis ikke sænke farten med at skubbe til slutningen af dine lister, hvilket er godt, når du skal indsætte elementer i så ekstrem en hastighed. Desværre kan Redis ikke arbejde med datasæt, der er større end den mængde RAM, du har (det skriver kun til disk, læsning er for at genstarte serveren eller i tilfælde af et systemnedbrud), og skalering skal udføres af dig og din ansøgning . (En almindelig måde er at sprede nøgler på tværs af adskillige servere, hvilket er implementeret af nogle Redis-drivere, især dem til Ruby on Rails.) Redis har også understøttelse af simpel publicerings-/subscribe-meddelelser, hvilket til tider også kan være nyttigt.
I dette scenarie er Redis "etape et." For hver specifik type begivenhed opretter du en liste i Redis med et unikt navn; for eksempel har vi "side vist" og "link klikket." For nemheds skyld ønsker vi at sikre, at dataene i hver liste er den samme struktur; linket, der klikkes på, kan have et brugertoken, linknavn og URL, mens den viste side kun har brugertoken og URL. Din første bekymring er bare at få det faktum, at det skete, og hvad der end er absolut nødvendigt data, du har brug for, bliver skubbet.
Dernæst har vi nogle simple bearbejdningsarbejdere, der fjerner denne febrilsk indsatte information fra Redis' hænder, ved at bede den om at tage en genstand fra slutningen af listen og aflevere den. Arbejderen kan foretage alle nødvendige justeringer/deduplikering/ID-opslag for at arkivere dataene korrekt og videregive dem til et mere permanent lagersted. Tænd så mange af disse arbejdere, som du har brug for, for at holde Redis' hukommelsesbelastning tålelig. Du kan skrive arbejderne i hvad som helst du ønsker (Node.js, C#, Java, ...), så længe den har en Redis-driver (det gør de fleste websprog nu) og en til din ønskede lagring (SQL, Mongo osv. )
MongoDB er god til dokumentlagring . I modsætning til Redis er den i stand til at håndtere databaser, der er større end RAM, og den understøtter sharding/replikering på egen hånd. En fordel ved MongoDB i forhold til SQL-baserede muligheder er, at du ikke behøver at have et forudbestemt skema, du kan til enhver tid ændre den måde, data gemmes på, som du vil.
Jeg vil dog foreslå Redis eller Mongo til "trin 1"-fasen med at opbevare data til behandling og bruge en traditionel SQL-opsætning (Postgres eller MSSQL, måske) til at gemme efterbehandlede data. Sporing af klientadfærd lyder som relationelle data for mig, da du måske ønsker at gå "Vis mig alle, der ser denne side" eller "Hvor mange sider har denne person set på denne givne dag" eller "Hvilken dag havde flest seere i alt? ". Der kan være endnu mere komplekse joinforbindelser eller forespørgsler til analytiske formål, du kommer med, og modne SQL-løsninger kan gøre meget af denne filtrering for dig; NoSQL (specifikt Mongo eller Redis) kan ikke lave joinforbindelser eller komplekse forespørgsler på tværs af forskellige datasæt.