Para uma solução de colheita como essa, eu recomendaria uma abordagem de vários estágios. O Redis é bom em comunicação em tempo real . O Redis foi projetado como um armazenamento de chave/valor na memória e herda alguns benefícios muito interessantes de ser um banco de dados de memória:operações de lista O(1). Enquanto houver RAM para usar em um servidor, o Redis não diminuirá a velocidade até o final de suas listas, o que é bom quando você precisa inserir itens em uma taxa tão extrema. Infelizmente, o Redis não pode operar com conjuntos de dados maiores que a quantidade de RAM que você tem (ele apenas grava para o disco, a leitura é para reiniciar o servidor ou em caso de falha do sistema) e o dimensionamento deve ser feito por você e sua inscrição . (Uma maneira comum é distribuir chaves em vários servidores, o que é implementado por alguns drivers Redis, especialmente aqueles para Ruby on Rails.) O Redis também tem suporte para mensagens simples de publicação/assinatura, que às vezes também podem ser úteis.
Nesse cenário, o Redis é o "estágio um". Para cada tipo específico de evento, você cria uma lista no Redis com um nome exclusivo; por exemplo, temos "página visualizada" e "link clicado". Para simplificar, queremos garantir que os dados em cada lista tenham a mesma estrutura; link clicado pode ter um token de usuário, nome de link e URL, enquanto a página visualizada pode ter apenas o token de usuário e URL. Sua primeira preocupação é apenas saber o que aconteceu e o que absolutamente necessário os dados que você precisa são enviados.
Em seguida, temos alguns trabalhadores de processamento simples que tiram essas informações inseridas freneticamente das mãos do Redis, pedindo que ele retire um item do final da lista e o entregue. O funcionário pode fazer quaisquer ajustes/desduplicação/pesquisas de ID necessários para arquivar os dados adequadamente e entregá-los a um local de armazenamento mais permanente. Ative quantos desses workers você precisar para manter a carga de memória do Redis suportável. Você pode escrever os workers em qualquer coisa que desejar (Node.js, C#, Java, ...), contanto que tenha um driver Redis (a maioria das linguagens da Web agora) e um para o armazenamento desejado (SQL, Mongo, etc.). )
MongoDB é bom em armazenamento de documentos . Ao contrário do Redis, ele é capaz de lidar com bancos de dados maiores que RAM e suporta fragmentação/replicação por conta própria. Uma vantagem do MongoDB sobre as opções baseadas em SQL é que você não precisa ter um esquema predeterminado, você é livre para alterar a maneira como os dados são armazenados da maneira que desejar a qualquer momento.
No entanto, eu sugeriria Redis ou Mongo para a fase "primeira etapa" de armazenar dados para processamento e usar uma configuração SQL tradicional (Postgres ou MSSQL, talvez) para armazenar dados pós-processados. Para mim, rastrear o comportamento do cliente soa como dados relacionais, pois você pode querer ir "Mostre-me todos que visualizam esta página" ou "Quantas páginas essa pessoa visualizou neste determinado dia" ou "Qual dia teve o maior número de espectadores no total? ". Pode haver junções ou consultas ainda mais complexas para fins analíticos que você criar, e soluções SQL maduras podem fazer muito dessa filtragem para você; NoSQL (Mongo ou Redis especificamente) não pode fazer junções ou consultas complexas em vários conjuntos de dados.
