Für eine Erntelösung wie diese würde ich einen mehrstufigen Ansatz empfehlen. Redis ist gut in Echtzeitkommunikation . Redis ist als speicherinterner Schlüssel/Wert-Speicher konzipiert und erbt einige sehr nette Vorteile einer Speicherdatenbank:O(1)-Listenoperationen. Solange auf einem Server RAM zur Verfügung steht, wird Redis das Pushen an das Ende Ihrer Listen nicht verlangsamen, was gut ist, wenn Sie Elemente mit einer so extremen Geschwindigkeit einfügen müssen. Leider kann Redis nicht mit Datensätzen arbeiten, die größer sind als die Menge an RAM, die Sie haben (es schreibt nur auf die Festplatte, das Lesen dient zum Neustart des Servers oder im Falle eines Systemabsturzes) und die Skalierung muss von Sie durchgeführt werden und Ihre Bewerbung . (Ein üblicher Weg ist, Schlüssel auf mehrere Server zu verteilen, was von einigen Redis-Treibern implementiert wird, insbesondere von denen für Ruby on Rails.) Redis unterstützt auch einfaches Publish/Subscribe-Messenging, was manchmal ebenfalls nützlich sein kann.
In diesem Szenario ist Redis „Stufe eins“. Für jeden spezifischen Ereignistyp erstellen Sie in Redis eine Liste mit einem eindeutigen Namen; zum Beispiel haben wir „Seite angesehen“ und „Link angeklickt“. Der Einfachheit halber möchten wir sicherstellen, dass die Daten in jeder Liste die gleiche Struktur haben; Der angeklickte Link kann ein Benutzertoken, einen Linknamen und eine URL haben, während die angezeigte Seite möglicherweise nur das Benutzertoken und die URL hat. Ihre erste Sorge ist nur, die Tatsache zu erfahren, dass es passiert ist, und alles, was absolut notwendig ist Daten, die Sie benötigen, werden gepusht.
Als nächstes haben wir einige einfache Verarbeitungsarbeiter, die diese hektisch eingefügten Informationen aus den Händen von Redis nehmen, indem sie es bitten, ein Element vom Ende der Liste zu nehmen und zu übergeben. Der Mitarbeiter kann alle Anpassungen/Deduplizierung/ID-Suchen vornehmen, die erforderlich sind, um die Daten ordnungsgemäß zu archivieren und sie an einen dauerhafteren Speicherort zu übergeben. Schalten Sie so viele dieser Worker ein, wie Sie benötigen, um die Speicherlast von Redis erträglich zu halten. Sie können die Worker in allem schreiben, was Sie möchten (Node.js, C#, Java, ...), solange es einen Redis-Treiber (die meisten Websprachen tun dies jetzt) und einen für Ihren gewünschten Speicher (SQL, Mongo usw.) )
MongoDB ist gut in der Dokumentenspeicherung . Im Gegensatz zu Redis ist es in der Lage, mit Datenbanken umzugehen, die größer als der Arbeitsspeicher sind, und es unterstützt eigenständig Sharding/Replikation. Ein Vorteil von MongoDB gegenüber SQL-basierten Optionen besteht darin, dass Sie kein vorgegebenes Schema haben müssen, sondern die Art und Weise, wie Daten gespeichert werden, jederzeit nach Belieben ändern können.
Ich würde jedoch Redis oder Mongo für die "erste" Phase des Speicherns von Daten zur Verarbeitung vorschlagen und ein herkömmliches SQL-Setup (Postgres oder MSSQL, vielleicht) verwenden, um nachbearbeitete Daten zu speichern. Das Verfolgen des Kundenverhaltens klingt für mich nach Beziehungsdaten, da Sie vielleicht „Zeige mir alle, die diese Seite ansehen“ oder „Wie viele Seiten hat diese Person an diesem bestimmten Tag angesehen“ oder „An welchem Tag hatte die meisten Besucher insgesamt?“ gehen möchten. ". Möglicherweise gibt es noch komplexere Verknüpfungen oder Abfragen für Analysezwecke, die Sie sich einfallen lassen, und ausgereifte SQL-Lösungen können einen Großteil dieser Filterung für Sie übernehmen. NoSQL (insbesondere Mongo oder Redis) kann keine Verknüpfungen oder komplexen Abfragen über verschiedene Datensätze hinweg durchführen.
