За решение за прибиране на реколтата като това бих препоръчал многоетапен подход. Redis е добър в комуникацията в реално време . Redis е проектиран като хранилище за ключ/стойност в паметта и наследява някои много хубави предимства да бъде база данни с памет:O(1) операции със списък. Докато има RAM за използване на сървър, Redis няма да забави натискането до края на вашите списъци, което е добре, когато трябва да вмъквате елементи с такава екстремна скорост. За съжаление Redis не може да работи с набори от данни, по-големи от количеството RAM, което имате (само записва на диск, четенето е за рестартиране на сървъра или в случай на срив на системата) и мащабирането трябва да се извърши от вие и вашето приложение . (Честоразпространен начин е да се разпространяват ключове между множество сървъри, което се реализира от някои драйвери на Redis, особено тези за Ruby on Rails.) Redis също има поддръжка за прости съобщения за публикуване/абониране, което също може да бъде полезно понякога.
В този сценарий Redis е „етап първи“. За всеки конкретен тип събитие създавате списък в Redis с уникално име; например имаме „разгледана страница“ и „кликната връзка“. За простота искаме да се уверим, че данните във всеки списък са с една и съща структура; щракната връзка може да има потребителско означение, име на връзката и URL адрес, докато прегледаната страница може да има само потребителски маркер и URL. Първата ви грижа е просто да разберете факта, че се е случило и каквото е абсолютно необходимо данните, от които се нуждаете, се изпращат.
След това имаме някои прости работници по обработка, които отнемат тази трескаво вмъкната информация от ръцете на Redis, като го молят да извади елемент от края на списъка и да го предаде. Работникът може да направи всякакви корекции/дедупликация/търсене на идентификатор, необходими за правилното архивиране на данните и да ги предаде на по-постоянен сайт за съхранение. Задействайте толкова много от тези работници, колкото са ви необходими, за да поддържате натоварването на паметта на Redis поносимо. Можете да напишете работниците във всичко, което пожелаете (Node.js, C#, Java, ...), стига да има драйвер за Redis (повечето уеб езици го правят сега) и такъв за желаното от вас хранилище (SQL, Mongo и т.н. )
MongoDB е добър в съхранението на документи . За разлика от Redis, той може да се справя с бази данни, по-големи от RAM, и поддържа разделяне/репликация самостоятелно. Предимство на MongoDB пред базираните на SQL опции е, че не е нужно да имате предварително определена схема, вие сте свободни да променяте начина, по който се съхраняват данните, както пожелаете, по всяко време.
Бих предложил обаче Redis или Mongo за фазата на "първа стъпка" на съхраняване на данни за обработка и използване на традиционна настройка на SQL (Postgres или MSSQL, може би) за съхраняване на постобработени данни. Проследяването на поведението на клиента ми звучи като релационни данни, тъй като може да искате да отидете на „Покажи ми всички, които преглеждат тази страница“ или „Колко страници е прегледал този човек през този ден“ или „Кой ден е имал най-много зрители общо? ". Може да има още по-сложни обединявания или заявки за аналитични цели, които измислите, а зрелите SQL решения могат да направят голяма част от това филтриране вместо вас; NoSQL (Mongo или Redis специално) не може да прави обединения или сложни заявки в различни набори от данни.
