Donc, BuddyMedia utilise une partie de cela. Le Gilt Groupe a fait quelque chose de plutôt cool avec Hummingbird (node.js + MongoDB).
Ayant travaillé pour un grand annonceur en ligne dans le domaine des médias sociaux, je peux attester que les rapports en temps réel sont vraiment pénibles. Essayer de "rouler" 500 millions d'impressions par jour est déjà un défi, mais essayer de le faire en temps réel a fonctionné, mais cela comportait des limitations importantes. (comme s'il avait en fait été retardé de 5 minutes :)
Franchement, ce type de problème est l'une des raisons pour lesquelles j'ai commencé à utiliser MongoDB. Et je ne suis pas le seul. Les gens utilisent MongoDB pour toutes sortes d'analyses en temps réel :surveillance de serveur , journalisation centralisée , ainsi que des rapports sur le tableau de bord.
La vraie clé lorsque vous faites ce type de rapport est de comprendre que la structure des données est complètement différente avec MongoDB, vous allez éviter les requêtes "d'agrégation", donc les requêtes et les graphiques de sortie vont être différents. Il y a du travail de codage supplémentaire côté client.
Voici la clé qui peut vous orienter dans la bonne direction pour faire cela avec MongoDB. Examinez la structure de données suivante :
{
date: "20110430",
gender: "M",
age: 1, // 1 is probably a bucket
impression_hour: [ 100, 50, ...], // 24 of these
impression_minute: [ 2, 5, 19, 8, ... ], // 1440 of these
clicks_hour: [ 10, 2, ... ],
...
}
Il y a évidemment quelques ajustements ici, des index appropriés, peut-être mélanger data+gender+age dans un _id . Mais c'est un peu la structure de base de l'analyse des clics avec MongoDB. Il est très facile de mettre à jour les impressions et les clics { $inc : { clicks_hour.0 : 1 } } . Vous pouvez mettre à jour l'ensemble du document de manière atomique. Et c'est en fait assez naturel de rendre compte. Vous disposez déjà d'un tableau contenant vos points de données horaires ou minute.
J'espère que cela vous indique la bonne direction.
