Para una solución de recolección como esta, recomendaría un enfoque de varias etapas. Redis es bueno en comunicación en tiempo real . Redis está diseñado como un almacén de clave/valor en memoria y hereda algunos beneficios muy buenos de ser una base de datos de memoria:operaciones de lista O(1). Mientras haya RAM para usar en un servidor, Redis no disminuirá la velocidad al llegar al final de sus listas, lo cual es bueno cuando necesita insertar elementos a una velocidad tan extrema. Desafortunadamente, Redis no puede operar con conjuntos de datos más grandes que la cantidad de RAM que tiene (solo escribe al disco, la lectura es para reiniciar el servidor o en caso de un bloqueo del sistema) y el escalado lo debe hacer usted y su solicitud . (Una forma común es repartir las claves entre numerosos servidores, lo cual es implementado por algunos controladores de Redis, especialmente aquellos para Ruby on Rails). Redis también tiene soporte para mensajes simples de publicación/suscripción, que también pueden ser útiles en ocasiones.
En este escenario, Redis es la "etapa uno". Para cada tipo específico de evento, crea una lista en Redis con un nombre único; por ejemplo, tenemos "página vista" y "enlace en el que se hizo clic". Para simplificar, queremos asegurarnos de que los datos en cada lista tengan la misma estructura; el enlace en el que se hace clic puede tener un token de usuario, un nombre de enlace y una URL, mientras que la página visitada solo puede tener el token de usuario y la URL. Su primera preocupación es saber el hecho de que sucedió y cualquier cosa absolutamente necesaria se envían los datos que necesita.
A continuación, tenemos algunos trabajadores de procesamiento simples que toman esta información insertada frenéticamente de las manos de Redis, pidiéndole que tome un elemento del final de la lista y se lo entregue. El trabajador puede realizar cualquier ajuste/deduplicación/búsqueda de ID necesarios para archivar correctamente los datos y transferirlos a un sitio de almacenamiento más permanente. Encienda tantos de estos trabajadores como necesite para mantener soportable la carga de memoria de Redis. Puede escribir los trabajadores en cualquier cosa que desee (Node.js, C #, Java, ...) siempre que tenga un controlador Redis (la mayoría de los lenguajes web lo tienen ahora) y uno para su almacenamiento deseado (SQL, Mongo, etc.). )
MongoDB es bueno en almacenamiento de documentos . A diferencia de Redis, es capaz de manejar bases de datos más grandes que la RAM y admite la fragmentación/replicación por sí mismo. Una ventaja de MongoDB sobre las opciones basadas en SQL es que no tiene que tener un esquema predeterminado, puede cambiar la forma en que se almacenan los datos como quiera en cualquier momento.
Sin embargo, sugeriría Redis o Mongo para la fase de "paso uno" de almacenamiento de datos para su procesamiento y uso de una configuración de SQL tradicional (Postgres o MSSQL, quizás) para almacenar datos posprocesados. El seguimiento del comportamiento del cliente me suena a datos relacionales, ya que es posible que desee ir a "Muéstrame a todos los que ven esta página" o "¿Cuántas páginas vio esta persona en este día determinado" o "¿Qué día tuvo la mayor cantidad de visitas en total? ". Puede haber uniones o consultas aún más complejas con fines analíticos que se le ocurran, y las soluciones SQL maduras pueden hacer mucho de este filtrado por usted; NoSQL (Mongo o Redis específicamente) no puede realizar uniones o consultas complejas en varios conjuntos de datos.
