Entonces BuddyMedia está usando algo de esto. Gilt Groupe ha hecho algo genial con Hummingbird (nodo.js + MongoDB).
Habiendo trabajado para un gran anunciante en línea en el espacio de las redes sociales, puedo dar fe de que los informes en tiempo real son realmente molestos. Intentar "acumular" 500 millones de impresiones por día ya es un desafío, pero intentar hacerlo en tiempo real funcionó, pero tenía algunas limitaciones importantes. (como si en realidad se retrasara 5 minutos :)
Francamente, este tipo de problema es una de las razones por las que comencé a usar MongoDB. Y no soy el único. La gente usa MongoDB para todo tipo de análisis en tiempo real:supervisión de servidores , registro centralizado , así como informes del tablero.
La clave real al hacer este tipo de informes es comprender que la estructura de datos es completamente diferente con MongoDB, evitará consultas de "agregación", por lo que las consultas y los gráficos de salida serán diferentes. Hay algo de trabajo de codificación adicional en el lado del cliente.
Aquí está la clave que puede indicarle la dirección correcta para hacer esto con MongoDB. Eche un vistazo a la siguiente estructura de datos:
{
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, ... ],
...
}
Obviamente, hay algunos ajustes aquí, índices apropiados, tal vez combinando datos + género + edad en un _id . Pero esa es la estructura básica del análisis de clics con MongoDB. Es muy fácil actualizar impresiones y clics { $inc : { clicks_hour.0 : 1 } } . Tienes la oportunidad de actualizar todo el documento de forma atómica. Y en realidad es bastante natural informar sobre ello. Ya tiene una matriz que contiene sus puntos de datos por hora o por minuto.
Con suerte, eso te indica la dirección correcta.
