Voor een oogstoplossing als deze zou ik een meerfasenaanpak aanraden. Redis is goed in realtime communicatie . Redis is ontworpen als een sleutel/waarde-opslag in het geheugen en erft een aantal zeer mooie voordelen van een geheugendatabase:O(1) lijstbewerkingen. Zolang er RAM is om op een server te gebruiken, zal Redis niet vertragen om naar het einde van uw lijsten te gaan, wat goed is wanneer u items met zo'n extreme snelheid moet invoegen. Helaas kan Redis niet werken met datasets die groter zijn dan de hoeveelheid RAM die je hebt (het schrijft alleen naar schijf, lezen is voor het herstarten van de server of in geval van een systeemcrash) en het schalen moet worden gedaan door u en uw aanvraag . (Een veelgebruikte manier is om sleutels over meerdere servers te verspreiden, wat wordt geïmplementeerd door sommige Redis-stuurprogramma's, vooral die voor Ruby on Rails.) Redis biedt ook ondersteuning voor eenvoudige berichten over publiceren/abonneren, wat soms ook handig kan zijn.
In dit scenario is Redis 'fase één'. Voor elk specifiek type evenement maak je in Redis een lijst aan met een unieke naam; we hebben bijvoorbeeld "pagina bekeken" en "link geklikt". Voor de eenvoud willen we ervoor zorgen dat de gegevens in elke lijst dezelfde structuur hebben; geklikte link kan een gebruikerstoken, linknaam en URL hebben, terwijl de bekeken pagina mogelijk alleen de gebruikerstoken en URL heeft. Je eerste zorg is gewoon te weten dat het is gebeurd en wat dan ook absoluut noodzakelijk gegevens die u nodig hebt, worden gepusht.
Vervolgens hebben we enkele eenvoudige verwerkingswerkers die deze verwoed ingevoegde informatie uit de handen van Redis nemen, door hem te vragen een item van het einde van de lijst te nemen en te overhandigen. De werknemer kan alle benodigde aanpassingen/deduplicatie/ID-lookups maken om de gegevens correct te archiveren en over te dragen aan een meer permanente opslaglocatie. Start zoveel van deze werkers als je nodig hebt om de geheugenbelasting van Redis draaglijk te houden. U kunt de werkers in alles schrijven wat u maar wilt (Node.js, C#, Java, ...) zolang het een Redis-stuurprogramma heeft (de meeste webtalen doen dat nu) en een voor uw gewenste opslag (SQL, Mongo, enz. )
MongoDB is goed in documentopslag . In tegenstelling tot Redis kan het omgaan met databases die groter zijn dan RAM en ondersteunt het op zichzelf sharding/replicatie. Een voordeel van MongoDB ten opzichte van op SQL gebaseerde opties is dat u geen vooraf bepaald schema hoeft te hebben, u bent vrij om de manier waarop gegevens worden opgeslagen op elk gewenst moment te wijzigen zoals u dat wilt.
Ik zou echter Redis of Mongo aanraden voor de "stap één" fase van het bewaren van gegevens voor verwerking en een traditionele SQL-configuratie gebruiken (Postgres of MSSQL, misschien) om naverwerkte gegevens op te slaan. Het volgen van klantgedrag klinkt voor mij als relationele gegevens, omdat je misschien wilt gaan naar "Laat me iedereen zien die deze pagina bekijkt" of "Hoeveel pagina's heeft deze persoon op deze bepaalde dag bekeken" of "Welke dag had in totaal de meeste kijkers? ". Er kunnen zelfs nog complexere joins of queries voor analytische doeleinden zijn die je bedenkt, en volwassen SQL-oplossingen kunnen veel van deze filtering voor je doen; NoSQL (specifiek Mongo of Redis) kan geen joins of complexe query's uitvoeren op verschillende gegevenssets.